Send-Q растёт, Recv-Q пустая: как читать очереди сокетов и что они говорят о канале

MAATRIX

Две колонки в выводе ss или netstat — Send-Q и Recv-Q — почти всегда пролистывают взглядом в поисках столбца с адресом или состоянием соединения. А зря: эти два числа прямо говорят, где именно застряли данные и на чьей они стороне — у вашего приложения, у собеседника на другом конце или у сети между вами. Разбираем, что означают эти колонки в разных состояниях сокета и по какому алгоритму читать их изменение, а не разовое значение.

Одни и те же колонки, разный смысл в зависимости от состояния

Первое, что стоит держать в голове: Send-Q и Recv-Q — это не два фиксированных счётчика с одним и тем же значением независимо от контекста. Их смысл меняется в зависимости от состояния сокета — LISTEN это или ESTABLISHED. Именно поэтому чтение этих колонок «на глаз», без привязки к состоянию строки, — источник половины неверных выводов.

Типичный вызов для TCP-соединений:

ss -tn
# или, если нужны ещё и слушающие сокеты
ss -tan

и эквивалент через netstat:

netstat -tn
netstat -tan

Формат столбцов в ss и в netstat практически идентичен по смыслу (хотя визуально порядок и заголовки чуть отличаются между утилитами и версиями) — Recv-Q идёт первой колонкой, Send-Q второй, дальше локальный и удалённый адрес, и состояние соединения. Вот на это состояние — LISTEN или ESTABLISHED — и нужно смотреть в первую очередь, прежде чем интерпретировать цифры рядом.

LISTEN: Recv-Q — это очередь на accept(), а не данные

Для строки в состоянии LISTEN обе колонки говорят не про переданные байты, а про очередь входящих соединений, ожидающих, пока процесс заберёт их системным вызовом accept():

• Recv-Q — текущая длина этой очереди: сколько уже установленных TCP-соединений сейчас стоят и ждут, пока приложение до них доберётся.
• Send-Q — здесь это не объём данных на отправку, а верхний предел этой очереди: то самое число backlog, которое приложение передало в вызов listen(), ограниченное сверху системным net.core.somaxconn.

Если Recv-Q для LISTEN-сокета стабильно растёт и приближается к Send-Q (то есть к лимиту) — это прямой признак того, что приложение не успевает вызывать accept() так же быстро, как приходят новые соединения. Причины разные: однопоточная обработка без асинхронности, исчерпанный пул воркеров, процесс упёрся в CPU или завис на медленном даунстриме — но общий диагноз один: узкое место не в сети, а в том, с какой скоростью код приложения освобождает эту очередь.

Пример вывода:

State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port
LISTEN  0       511     0.0.0.0:80           0.0.0.0:*
LISTEN  498     512     0.0.0.0:8080         0.0.0.0:*

Вторая строка — тревожный сигнал: очередь почти забита (498 из 512), и при следующем всплеске нагрузки новые клиенты либо получат явный отказ, либо застрянут в молчаливом ожидании — зависит от настройки net.ipv4.tcp_abort_on_overflow. Механику самой этой очереди, разницу между SYN-очередью и accept-очередью, поведение при переполнении и настройку backlog на уровне ядра и веб-сервера подробно разбирали в статье про backlog соединений и отказ на живом сервере — здесь важно унести одну мысль: для LISTEN растущий Recv-Q относительно своего Send-Q — это про приложение, а не про сеть.

ESTABLISHED, Send-Q: отправлено, но ещё не подтверждено ACK

Для установленного соединения смысл колонок меняется на противоположный привычной интуиции про «отправку» и «приём»:

Send-Q для ESTABLISHED-сокета — это объём данных в байтах, которые ядро уже приняло от приложения (через send()/write()) и попыталось передать по сети, но которые ещё не подтверждены ACK-пакетом от удалённой стороны. Проще говоря — данные, которые физически ушли (или готовятся уйти) из буфера отправки, но собеседник ещё не сказал «получил».

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

watch -n1 "ss -tn dst 203.0.113.10"

Устойчивый и не убывающий рост Send-Q на ESTABLISHED-соединении означает одно из двух (а чаще — комбинацию обоих):

• Удалённая сторона не читает данные достаточно быстро. Получатель занят чем-то другим, не успевает вычитывать свой сокет, и его объявленное окно приёма (receive window) сжимается — отправитель физически не может протолкнуть больше данных, пока получатель не заберёт уже доставленные и не расширит окно снова.
• Сеть между вами не пропускает данные с нужной скоростью. Узкий канал, потери пакетов, из-за которых включается пересчёт cwnd в congestion control, или просто длинный маршрут с большим RTT, где окно физически не успевает раскрыться до нужного размера — механика этого разобрана в статье про TCP-окно и длинные толстые каналы.

С точки зрения отправителя оба сценария выглядят одинаково — растущий Send-Q. Разница только в том, что происходит на другом конце и по дороге, а различать эти два случая приходится уже дополнительными инструментами, а не одним ss.

ESTABLISHED, Recv-Q: получено, но ещё не прочитано вами

Recv-Q для ESTABLISHED-сокета — зеркальная история, но уже про вашу собственную сторону: это объём данных, которые уже пришли по сети, подтверждены на уровне TCP и лежат в буфере приёма ядра, но приложение ещё не забрало их вызовом recv()/read().

Если это число стабильно растёт — сеть и удалённая сторона тут ни при чём, проблема локальная: ваш собственный процесс не успевает обрабатывать входящий поток данных. Типичные причины совпадают с теми, что вызывают переполнение accept-очереди у LISTEN-сокета, только уже применительно к чтению данных, а не к приёму новых соединений: перегруженный event loop, медленный обработчик на пути данных, блокировка на диске или на внешнем вызове внутри цикла обработки, нехватка CPU у процесса.

Внутреннюю механику двух независимых буферов — отправки и приёма, — что на самом деле гарантирует успешный send() и почему растущий Recv-Q получателя не видно из кода отправителя, подробно разбирали в статье про буферы сокета и куда деваются данные. Здесь же фиксируем практический вывод: если видите растущий Recv-Q на своей стороне ESTABLISHED-соединения — не тратьте время на диагностику сети, идите смотреть на скорость обработки внутри собственного процесса.

Диагностический алгоритм: куда смотреть по тому, что растёт

Свести оба состояния и обе колонки в одну таблицу удобнее, чем держать в голове:

Практический порядок действий:

1. Не полагайтесь на один снимок. Разовое ненулевое значение почти ничего не говорит — в моменте на живом соединении почти всегда что-то в полёте. Смотрите на несколько последовательных срезов с интервалом в секунды: watch -n1 ss -tn или простой цикл с sleep. Важен тренд — растёт ли число монотонно или колеблется около небольшой базовой величины.

1. Определите состояние строки прежде, чем читать цифры. LISTEN и ESTABLISHED — это, по сути, две разные таблицы с одинаковыми заголовками колонок. Спутать их — самая частая ошибка при быстром просмотре вывода ss -tan целиком, где строки обоих состояний идут вперемешку.

1. Растущий Send-Q на ESTABLISHED → смотрите наружу. Проверьте, не упирается ли получатель в собственный медленный Recv-Q (если у вас есть доступ к обеим сторонам), прогоните iperf3 между теми же узлами, чтобы отличить проблему канала от проблемы конкретного приложения-получателя, посмотрите ss -tin на то же соединение — поля rtt, cwnd, rcv_space дадут больше контекста, чем одни только очереди.

1. Растущий Recv-Q на ESTABLISHED → смотрите внутрь. Профилируйте собственный процесс: задержку event loop, время в обработчиках, блокирующие вызовы на пути от сокета до бизнес-логики. Сеть здесь почти наверняка ни при чём — данные уже долетели и лежат в буфере ядра, дело за вашим кодом.

1. Растущий Recv-Q на LISTEN → смотрите на приёмную способность приложения принимать новые соединения, а не на то, что происходит внутри уже установленных — это разные узкие места, и лечатся они по-разному.

Практический сценарий: медленный мобильный клиент раздувает Send-Q на сервере

Один из самых частых практических случаев растущего Send-Q — сервер отдаёт клиенту относительно большой ответ (файл, видеофрагмент, объёмный JSON из API), а клиент сидит на нестабильной мобильной сети с ограниченной и переменной полосой.

Механика простая: сервер honestly копирует данные в буфер отправки и начинает передавать их сегментами. Клиент физически не успевает вычитывать их с той же скоростью, с какой сервер готов отдавать, — либо из-за узкого канала, либо из-за высокой и рваной задержки на мобильной сети. Клиентский стек TCP реагирует штатно: объявляемое окно приёма сужается, ограничивая, сколько неподтверждённых данных сервер вообще может держать «в полёте». Сервер упирается в это окно — и его собственный буфер отправки, куда приложение продолжает класть новые данные (например, следующие чанки того же файла), начинает заполняться неотправленными и неподтверждёнными байтами.

На сервере в этот момент ss -tn покажет примерно такую картину для соединения с этим конкретным клиентом:

State       Recv-Q  Send-Q   Local Address:Port      Peer Address:Port
ESTAB       0       184320   198.51.100.20:443       203.0.113.77:51422

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

Важная оговорка: это не единственная возможная причина растущего Send-Q у одного конкретного соединения — тот же эффект даёт и потеря пакетов именно на маршруте до этого клиента, из-за которой congestion control снижает cwnd и придерживает отправку независимо от готовности получателя читать. Различить «получатель медленный» и «маршрут теряет пакеты» по одному Send-Q нельзя — нужен ss -tin на то же соединение и взгляд на счётчики ретрансмиссий, либо mtr/traceroute до конкретного клиентского IP.

На что не стоит полагаться при чтении этих колонок

Несколько практических оговорок, которые снимают типичные ложные тревоги:

• Единичный снимок с ненулевым значением — это норма, а не авария. На loaded-сервере с активным трафиком почти всегда найдётся десяток соединений с небольшим Send-Q или Recv-Q в моменте — это данные в полёте, а не проблема. Тревожный сигнал — устойчивый рост без опустошения на протяжении нескольких проверок подряд.
• Не путайте Send-Q LISTEN-сокета (лимит) с Send-Q ESTABLISHED-соединения (данные в полёте). Это разные по смыслу числа с одинаковым именем колонки — источник половины путаницы при быстром просмотре смешанного вывода ss -tan.
• Не выдумывайте универсальный порог «нормального» значения в байтах. Приемлемая величина зависит от размера буферов (net.ipv4.tcp_wmem/tcp_rmem), от типичного размера полезной нагрузки конкретного приложения и от RTT до клиентов. Число, которое для одного сервиса — тревожный сигнал, для другого (например, с крупными файлами и BDP на мегабайты) — совершенно рабочая величина. Ориентируйтесь на тренд у себя, а не на абсолютную цифру из чужой статьи.
• ss -tn даёт только эти два числа — для более глубокой картины нужен ss -tin с полями rtt, cwnd, rcv_space, retrans на том же соединении. Колонки Send-Q/Recv-Q — это отправная точка диагностики, точка «куда смотреть дальше», а не полный диагноз сама по себе.

Похожий по духу разбор — реальный инцидент, где растущий Send-Q на вебсокет-соединении несколько недель маскировался под «соединение живое, просто пинги работают», пока не завели отдельный мониторинг буфера, — можно посмотреть в статье про буфер отправки, который переполнялся молча. Там же — рабочий пример backpressure-контроля поверх такой же диагностики через ss.

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