Запрос тормозит при установленном TCP: что покажут retrans и rtt в ss

Соединение с API успешно установлено, но передача периодически замирает. Проверка открытого порта отвечает на вопрос о возможности соединиться, а проблема возникает позже. На Linux можно посмотреть статистику конкретного TCP-сокета и увидеть, появляются ли повторные передачи в момент задержки.

Найдите соединение своего запроса

ss -tnp dst 192.0.2.80
ss -tin dst 192.0.2.80

Первый вызов показывает адреса, состояния и, при достаточных правах, процесс. Второй добавляет внутренние TCP-показатели. Уточните порт и локальный адрес, если к одному серверу открыто много соединений. Статистика соседнего соединения не объяснит запрос, который сейчас ждёт ответа.

Смотрите несколько снимков во время одной операции. Отдельное значение rtt характеризует оценку времени прохождения туда и обратно на транспортном уровне. Оно не равно времени выполнения SQL, обработки HTTP или ожидания свободного обработчика. Сервер может долго молчать при низком RTT и полностью исправной сети.

Ищите изменение, а не пугающее число

Счётчики и поля зависят от версии ядра и iproute2. Зафиксируйте весь вывод, затем сравните значения retrans, bytes_retrans, если они доступны, и параметры таймера. Рост повторных передач одновременно с остановкой полезной передачи поддерживает сетевую гипотезу. Ненулевой исторический счётчик без дальнейшего роста может относиться к давно прошедшему эпизоду.

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

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

Разделите ожидание транспорта и сервера

Сопоставьте момент запроса с журналом приложения. Если запрос принят сразу, а ответ сформирован через десять секунд при стабильной статистике TCP, исследуйте обработку. Если приложение сформировало ответ, но счётчики повторов растут и клиент получает данные рывками, продолжайте проверять передачу.

Send-Q и Recv-Q тоже требуют контекста. Очередь отправки сама по себе не указывает на потерю: получатель может медленно читать или ограничивать окно. Очередь приёма на стороне сервера может означать, что данные уже дошли, но приложение ещё не забрало их из сокета. Поэтому полезно собрать снимки с обеих сторон одного соединения.

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

Научитесь выбирать проверку по этапу сбоя. В курсе Linux и Bash для DevOps-инженеров есть диагностика процессов, портов и сетевой доступности учебного сервиса. Откройте программу и продолжите от чтения одного сокета к разбору цепочки работы приложения.

Ещё по теме

• DNS отвечает на короткие запросы, но ломается на больших: проверьте TCP 53
• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения