Мониторинг TCP-соединений. Retransmits, resets, SYN backlog и что они говорят о проблемах

Когда приложение работает медленно, пользователи часто первым делом смотрят на CPU, память или состояние базы данных. Однако причиной деградации может быть не само приложение, а сетевой уровень.

TCP — это основа большинства современных сервисов: HTTP, HTTPS, базы данных, очереди сообщений и различные API работают поверх TCP-соединений.

Проблемы на этом уровне редко выглядят как очевидная ошибка. Чаще они проявляются через рост задержек, случайные таймауты, медленное открытие соединений или периодические ошибки.

Именно поэтому при мониторинге серверов важно отслеживать не только нагрузку системы, но и состояние TCP-стека.

Почему TCP-метрики важны

TCP отвечает не просто за передачу данных, а за надёжную доставку.

Он контролирует:

• установку соединения;
• подтверждение получения пакетов;
• повторную отправку потерянных данных;
• закрытие соединений;
• управление перегрузкой сети.

Если на этом уровне возникают проблемы, приложение может выглядеть исправным, но пользователи всё равно будут сталкиваться с задержками.

Например:

• веб-сервер принимает запросы, но ответы приходят медленно;
• база данных работает нормально, но подключения к ней устанавливаются несколько секунд;
• API периодически возвращает ошибки из-за сетевых таймаутов.

Поэтому TCP-метрики являются важным источником информации при поиске причин деградации.

TCP retransmits: повторная отправка потерянных пакетов

Retransmit (повторная передача) — это ситуация, когда отправитель не получил подтверждение доставки пакета и отправляет его повторно.

В нормальной сети небольшое количество retransmits является допустимым. Полное отсутствие потерь практически невозможно.

Однако резкий рост повторных передач часто указывает на проблемы.

Основные причины:

• потеря пакетов в сети;
• перегрузка канала;
• проблемы с маршрутизацией;
• ошибки сетевого оборудования;
• слишком высокая нагрузка на узел.

Например, приложение отправляет клиенту ответ:

Server → Client: DATA

Но подтверждение не приходит:

Client → Server: ACK (нет)

Через некоторое время сервер повторяет отправку:

Server → Client: DATA (retransmit)

Если таких ситуаций становится много, растёт задержка ответа.

Пользователь может видеть это как:

• медленную загрузку страниц;
• увеличение latency API;
• таймауты соединений.

При анализе важно смотреть не только абсолютное число retransmits, а именно динамику.

Например:

100 retransmits/min → нормально для сервера с большим количеством трафика

10000 retransmits/min → вероятная проблема

TCP resets: неожиданные закрытия соединений

TCP reset (RST) — это принудительное завершение соединения.

В отличие от обычного закрытия TCP через FIN, reset означает, что соединение было прекращено аварийно.

Рост TCP resets может говорить о разных проблемах.

Например:

Приложение закрывает соединения

Если сервис перегружен или не может обработать запрос, он может принудительно закрывать подключения.

Симптомы:

• ошибки подключения у клиентов;
• рост HTTP 502/503;
• нестабильная работа API.

Клиент закрывает соединение слишком быстро

Например, пользователь закрыл страницу или балансировщик прекратил ожидание ответа.

В этом случае resets могут быть следствием проблем выше уровнем.

Проблемы с firewall или балансировщиком

Некоторые сетевые устройства могут самостоятельно сбрасывать соединения при:

• превышении таймаутов;
• превышении лимитов;
• подозрительном трафике.

Поэтому рост RST нужно анализировать вместе с логами приложений и сетевых компонентов.

SYN backlog: очередь новых подключений

Перед тем как TCP-соединение становится рабочим, проходит процесс установки соединения — TCP handshake.

Он выглядит так:

Client → Server: SYN
Server → Client: SYN + ACK
Client → Server: ACK

После этого соединение считается установленным.

Но сервер не может принимать бесконечное количество новых подключений одновременно. Для этого существует очередь ожидания — SYN backlog.

Если входящих соединений слишком много, очередь может заполниться.

Тогда возможны:

• задержки установки соединений;
• потеря SYN-пакетов;
• ошибки подключения;
• рост времени ответа.

Причины могут быть разными:

• резкий рост нагрузки;
• слишком маленькие системные лимиты;
• медленное приложение, которое не успевает принимать соединения;
• SYN flood-атаки.

Как выглядит проблема с SYN backlog

Типичный сценарий:

1. Клиенты начинают открывать много соединений.
2. Сервер получает SYN-запросы.
3. Очередь заполняется.
4. Новые подключения начинают ждать или теряться.

При этом:

• CPU может быть нормальным;
• память может быть свободной;
• приложение может не показывать ошибок.

Но пользователи будут видеть:

• долгий первый ответ;
• ошибки подключения;
• периодические таймауты.

Это хороший пример ситуации, когда обычный мониторинг ресурсов не показывает реальную проблему.

Какие TCP-метрики стоит мониторить

Минимальный набор для серверов с сетевыми сервисами:

Количество активных соединений

Позволяет понять текущую нагрузку на TCP-стек.

Важно отслеживать:

• established connections;
• количество новых соединений;
• количество закрытий.

Резкие изменения могут указывать на проблемы с клиентами или приложением.

Retransmits

Показывает качество сетевого взаимодействия.

Рост может говорить о:

• потерях пакетов;
• перегрузке сети;
• проблемах маршрута.

TCP resets

Помогает обнаружить аварийные разрывы соединений.

Особенно важно смотреть рост RST вместе с:

• ошибками приложения;
• HTTP 5xx;
• ростом latency.

SYN backlog и dropped connections

Показывает проблемы на этапе установления соединений.

Рост таких показателей часто объясняет ситуации:

«сервер работает, но подключиться к нему сложно».

Инструменты для диагностики TCP

В Linux есть несколько стандартных инструментов. Мы их уже описывали в предыдущих статьях.

• ss

• netstat

• tcpdump

Почему TCP-проблемы часто сложно найти

Сетевые проблемы редко выглядят как явная ошибка.

Например:

CPU: 40%
RAM: 50%
Disk: нормально
Application logs: ошибок нет

Но пользователи жалуются на медленный сайт.

Причина может быть:

↑ TCP retransmits
↑ SYN queue usage
↑ connection latency

Именно поэтому полноценный мониторинг должен учитывать не только состояние приложения, но и сетевой уровень.

Итоги

TCP-метрики помогают увидеть проблемы, которые невозможно обнаружить только по загрузке сервера или логам приложения.

Рост retransmits может указывать на потери пакетов или проблемы сети. Увеличение TCP resets — на аварийное завершение соединений. Заполнение SYN backlog — на проблемы с обработкой новых подключений или сетевую перегрузку.

Мониторинг TCP особенно важен для сервисов с большим количеством соединений: веб-серверов, API, баз данных и распределённых систем.

Понимание состояния TCP позволяет быстрее находить причины задержек и ошибок, потому что многие проблемы пользователей начинаются не внутри приложения, а ещё на уровне сетевого взаимодействия.