Ретрансмиты в статистике сервера: какие цифры норма, а после каких пора звонить хостеру

MAATRIX

Открываете netstat -s или ss -ti на сервере и видите шестизначное число ретрансмитов — и не понимаете, это норма или уже пора писать в поддержку хостинга. Само по себе число ничего не говорит: сервер с большим трафиком естественно ретрансмитит больше в абсолютных цифрах, и это не значит, что у него хуже сеть. Разберём, где смотреть эти счётчики, почему важна доля ретрансмитов от общего трафика, а не абсолютное число, и как отличить фоновый шум от сигнала, требующего разбирательства.

Где смотреть счётчики ретрансмиссий на сервере

На Linux-сервере есть несколько мест со статистикой TCP-ретрансмиссий, у каждого свой уровень детализации. Ни один способ ниже не единственно верный — на практике удобно комбинировать их в зависимости от того, нужен общий обзор или разбор конкретного соединения.

netstat -s (пакет net-tools, во многих современных дистрибутивах уже не входит в базовую установку) даёт агрегированную статистику по всему TCP-стеку с момента загрузки ядра:

netstat -s -t | egrep -i "segments (sent out|retransmitted)"

    15987421 segments sent out
    124932 segments retransmitted

ss (пакет iproute2, стандартен практически везде, где есть современное ядро) — актуальная замена netstat, и у неё есть режим с расширенной информацией по каждому TCP-сокету:

ss -ti state established

ESTAB 0 0 10.20.0.5:443 203.0.113.44:51422
     cubic wscale:7,7 rto:212 rtt:11.2/3.4 mss:1418 cwnd:24
     bytes_sent:88213045 bytes_retrans:412032 segs_out:64110 segs_in:41208
     retrans:0/318 send 2.4Mbps

Флаг -i без -t покажет info по всем типам сокетов, не только TCP — -ti сужает вывод до TCP с расширенной информацией. segs_out и retrans:0/318 — готовая пара чисел для доли ретрансмитов именно этого соединения, что удобно, когда жалоба привязана к одному клиенту или сервису на конкретном порту.

/proc/net/snmp — сырые счётчики ядра, ровно то, из чего netstat -s и берёт свои цифры, но в машиночитаемом виде, удобном для скриптов и экспортёров метрик (Zabbix, Prometheus node_exporter и подобные):

grep '^Tcp:' /proc/net/snmp

Строка отдаётся в двух экземплярах — заголовок с именами полей и строка со значениями в том же порядке. Проще всего не запоминать номер колонки (он может отличаться между версиями ядра), а транспонировать обе строки и найти нужные поля глазами:

paste <(grep '^Tcp:' /proc/net/snmp | head -1 | tr ' ' '\n') \
      <(grep '^Tcp:' /proc/net/snmp | tail -1 | tr ' ' '\n') | column -t

В выводе ищите строки OutSegs и RetransSegs — те же числа, что и в netstat -s, но без парсинга текста. Для более тонкой диагностики есть ещё /proc/net/netstat (раздел TcpExt) с детализацией по конкретным механизмам ретрансмита, но для базового мониторинга доли достаточно Tcp: из /proc/net/snmp.

Ретрансмиссии — это норма TCP, а не сама по себе авария

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

Вопрос, который стоит задавать себе, глядя на статистику, — не «есть ли ретрансмиты», а «какая их доля от общего трафика и насколько она изменилась». Сервис, который стабильно ретранслирует малую часть от общего числа отправленных сегментов месяцами подряд, скорее всего работает штатно. А сервис, у которого доля резко подскочила относительно своего же обычного уровня — уже даёт повод разбираться, даже если абсолютное число ретрансмитов при этом не выглядит пугающе большим.

Почему абсолютное число ретрансмитов ничего не говорит без контекста

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

Единственная осмысленная величина — это отношение ретрансмитов к общему числу отправленных сегментов за один и тот же период:

доля_ретрансмитов = RetransSegs / OutSegs

Оба счётчика в /proc/net/snmp (как и в netstat -s) — кумулятивные, они копятся с момента загрузки ядра и никогда не обнуляются сами. Если взять их «как есть» через год работы сервера, разовая деталь вроде одного плохого часа сегодня утонет в общей истории и её не будет видно. Поэтому для мониторинга и алертинга интересен не абсолютный кумулятивный счётчик, а дельта за интервал: снять значения OutSegs/RetransSegs, подождать минуту (или пять, или пятнадцать — в зависимости от того, насколько быстро вы хотите реагировать), снять снова и посчитать долю уже по разнице между двумя снимками, а не по накопленной с загрузки сумме.

В проде эту логику обычно берёт на себя система мониторинга — Zabbix-агент с собственным счётчиком типа "delta", node_exporter для Prometheus с правилом rate() по метрике node_netstat_Tcp_RetransSegs и аналогичной для OutSegs. Вручную дельты считать неудобно, но принцип тот же: интересна не сумма с начала времён, а изменение за конкретное окно.

Методология: снимаем свой baseline и следим за отклонением

Здесь стоит остановиться на соблазне найти «правильный процент» — условные 1% или 5%, выше которых якобы всегда плохо. Такого универсального порога нет, и любая статья, которая называет одну цифру как истину для всех серверов, скорее всего вводит в заблуждение. Профиль трафика слишком разный: сервер с преимущественно локальными клиентами и коротким RTT будет иметь один фоновый уровень, сервер, который обслуживает клиентов через межконтинентальные каналы или мобильные сети с изначально более шумной средой передачи — совсем другой, естественно более высокий. Разница в фоновом уровне между двумя абсолютно здоровыми серверами может быть кратной просто из-за разной географии клиентов.

Рабочая методология выглядит иначе:

1. Снимите baseline в спокойном, штатном состоянии. Дайте сервису пару-тройку суток проработать без известных инцидентов, снимая долю ретрансмитов с постоянным интервалом (например, раз в 1-5 минут). Захватите будни, выходные, пиковые часы и ночное затишье — фоновый уровень у большинства сервисов заметно отличается по времени суток.
2. Зафиксируйте типичный диапазон, а не одно число. Получится не константа, а диапазон с суточной и недельной цикличностью — именно он и есть ваша норма, специфичная для конкретного сервера и трафика.
3. Мониторьте отклонение от собственного baseline, а не от чужого порога. Алерт должен срабатывать не на «доля выше 2%», а на «доля заметно и устойчиво выше типичного значения для этого часа/дня на этом же сервере» — кратное превышение диапазона, устойчивое несколько минут подряд, а не разовый пик на один замер.
4. Разовый всплеск — не то же самое, что устойчивый рост. Единичный скачок часто означает короткий микровсплеск трафика и сам по себе не повод для тревоги. Рост, который держится 10-15 минут и дольше и не возвращается к норме, — уже сигнал разбираться.

Практический вывод: показатель доли ретрансмитов стоит выставить на тот же дашборд, где уже есть CPU, память и диск, и следить за ним так же регулярно — не открывать netstat -s вручную только когда пользователи написали жалобу. К моменту явных жалоб проблема обычно уже длится какое-то время.

Сигнал из сети: потери на маршруте

Устойчивый рост доли ретрансмитов, не связанный с изменением характера самого трафика, чаще всего указывает на потери где-то на пути пакетов — на вашей стороне, на транзитном участке или уже на стороне хостера. TCP просто маскирует эти потери повторной отправкой, и без мониторинга ретрансмитов проблема выглядит как расплывчатое «всё как будто иногда тормозит», а не как конкретная сетевая ошибка.

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

Стоит держать в голове и то, насколько чувствителен TCP к небольшой доле потерь: congestion control резко режет окно передачи при каждой обнаруженной потере и восстанавливает его гораздо медленнее, поэтому даже некрупный рост ретрансмитов может ощутимо просаживать пропускную способность, особенно при высоком RTT. Механика разобрана в статье о том, как малая доля потерь режет скорость TCP вдвое.

Отдельно стоит проверить не только логическую сетевую статистику, но и физический уровень интерфейса — счётчики ошибок на самой сетевой карте:

ip -s link show eth0
ethtool -S eth0 | grep -iE 'crc|error|align|drop'

Растущие CRC-ошибки или ошибки выравнивания кадра — признак проблемы не в сети, а на конкретном физическом линке (кабель, коннектор, порт коммутатора). Разбор такого случая, где двузначный рост доли ретрансмитов объяснялся одним повреждённым патч-кордом в стойке, — в статье про восемь процентов ретрансмитов и виноватый патч-корд.

Сигнал с самого сервера: не успевает обрабатывать пакеты

Второй источник роста ретрансмитов — не сеть между сервером и клиентом, а сам сервер, который физически не успевает обработать входящий и исходящий трафик вовремя. Если процессор перегружен или сетевая подсистема ядра не успевает разгребать очередь пакетов, ACK-подтверждения формируются и отправляются с опозданием, у клиента срабатывает таймаут ретрансмита раньше, чем сервер вообще успел ответить — и получаем рост ретрансмитов, который по факту не сетевая проблема, а проблема производительности сервера.

Что стоит проверить в первую очередь:

• Общая загрузка CPU и очередь процессов. Растущий load average относительно числа ядер — сигнал, что процессы, включая обработчики сетевых прерываний, стоят в очереди дольше обычного.
• Steal time на виртуальных серверах. На VPS с шумным соседом по гипервизору можно недополучать реальные такты CPU даже при формально невысокой собственной загрузке — сетевой стек обслуживается с задержкой, которая внешне выглядит как рост ретрансмитов. Как отличить это от собственной перегрузки — в статье про steal time и соседа, который ест ваш CPU.
• Переполнение приёмных буферов сетевой карты. Счётчики dropped/overrun в ip -s link и расширенная статистика драйвера через ethtool -S (поля вроде rx_missed, rx_no_buffer, названия зависят от драйвера) показывают, не теряет ли карта пакеты из-за нехватки места в очереди приёма.
• Очередь softirq и распределение прерываний по ядрам. Если весь сетевой трафик обслуживается прерываниями на одном ядре (нет RSS/RPS или он неправильно настроен), это ядро упирается в потолок при росте трафика, пока остальные простаивают.

Практический критерий: дело в сервере, а не в сети, если рост доли ретрансмитов совпадает по времени с ростом load average, steal time или dropped на интерфейсе, а параллельный mtr с обеих сторон соединения при этом чист. Решение здесь не «звонить в поддержку хостера», а разбираться с нагрузкой сервиса или пересматривать конфигурацию сервера.

Сигнал с клиентской стороны: не вся сеть, а конкретный сегмент

Третий вариант — рост ретрансмитов, не связанный ни с вашей сетью, ни с сервером, а проявляющийся только у определённой группы клиентов. Если доля выросла в целом, но при разбивке по подключениям видно, что проблема сосредоточена у клиентов одного мобильного оператора, одной географии или подсети — это почти наверняка проблема на последней миле именно этого сегмента, а не в вашей инфраструктуре.

Как это проверить практически:

ss -ti state established | grep -B1 'retrans:[1-9]'

Команда покажет строки с адресами соединений, у которых счётчик retrans в текущей сессии ненулевой — дальше остаётся сгруппировать эти IP по подсетям или ASN (через whois адреса или GeoIP/ASN-базу) и посмотреть, не концентрируются ли проблемные соединения в одном провайдере или регионе. Если рост распределён равномерно по всем клиентам — вероятнее проблема на вашей стороне. Если сконцентрирован в одном сегменте — велика вероятность, что дело в мобильной сети конкретного оператора или локальной проблеме именно у этой группы, и на это со стороны сервера повлиять нельзя, разве что зафиксировать и сообщить провайдеру при повторяемости.

Если объём трафика позволяет, эту разбивку полезно логировать на уровне приложения: связка клиентского IP или ASN с фактом ретрансмита даёт возможность не гадать, а сразу видеть, растёт ли доля у всех одинаково или только у части аудитории.

Частые вопросы