Предел очереди на прослушивание: backlog, SYN и тихо потерянные подключения

MAATRIX

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

Две очереди одного сокета: SYN-queue и accept-queue

Когда сервер вызывает listen() на сокете, ядро заводит под него не одну очередь, а две, и путаница между ними — источник большинства неверных настроек.

SYN-очередь (SYN backlog, она же request queue) хранит подключения, которые ещё не завершили трёхстороннее рукопожатие: клиент прислал SYN, сервер ответил SYN-ACK и ждёт финальный ACK. Пока ACK не пришёл, запись сидит именно здесь. Размер очереди регулируется net.ipv4.tcp_max_syn_backlog.

Accept-очередь (accept queue, она же completed connection queue) хранит уже полностью установленные соединения (рукопожатие завершено, статус ESTABLISHED), которые ждут, пока приложение вызовет accept() и заберёт их себе. Размер этой очереди задаётся минимумом из двух чисел: системного net.core.somaxconn и параметра backlog, который приложение передало в вызов listen(fd, backlog).

Ключевой момент: очередей две, они независимы, и переполниться может любая из них по своей причине. SYN-очередь растёт, когда много клиентов одновременно открывают соединения (всплеск нагрузки или SYN-флуд). Accept-очередь растёт, когда клиенты уже достучались, но приложение не успевает забирать готовые соединения — event loop занят, воркер завис в блокирующей операции или процесс придавлен GC-паузой.

Клиент                    Ядро сервера                    Приложение
  |  SYN            ->    [SYN-очередь]                        |
  |  <- SYN-ACK           tcp_max_syn_backlog                  |
  |  ACK            ->    [перенос в accept-очередь]            |
  |                       somaxconn / backlog в listen()        |
  |                             |------------ accept() -------->|

net.ipv4.tcp_max_syn_backlog и SYN cookies

tcp_max_syn_backlog ограничивает число полуоткрытых соединений (SYN_RECV), которые сервер готов держать одновременно, пока не получит подтверждающий ACK. Посмотреть текущее значение и поднять его:

sysctl net.ipv4.tcp_max_syn_backlog
# net.ipv4.tcp_max_syn_backlog = 1024

sysctl -w net.ipv4.tcp_max_syn_backlog=4096

На практике SYN-очередь редко переполняется от честного трафика — на это способен разве что резкий одновременный всплеск (тысячи клиентов реконнектятся после сбоя балансировщика) или направленный SYN-флуд. От переполнения спасают SYN cookies: если net.ipv4.tcp_syncookies=1 (в большинстве дистрибутивов — значение по умолчанию), ядро при заполненной очереди перестаёт хранить состояние подключения и кодирует нужную информацию прямо в номер последовательности SYN-ACK. Когда приходит финальный ACK, сервер восстанавливает состояние из самого пакета, а не из таблицы в памяти.

Цена cookies — часть TCP-опций (в первую очередь некоторые расширенные опции масштабирования окна) теряется, потому что закодировать всё в 32-битном поле невозможно. Это осознанный компромисс: принять соединение с чуть худшими характеристиками лучше, чем отбросить его совсем. Отключать tcp_syncookies ради «чистоты» смысла нет — включённые cookies не мешают нормальной работе и включаются в дело только при реальном переполнении.

net.core.somaxconn и backlog в коде приложения

Это вторая очередь и вторая по частоте причина «внезапных» обрывов под нагрузкой — и именно здесь чаще всего рассинхронизируются системная настройка и настройка самого приложения.

net.core.somaxconn — системный потолок для accept-очереди, общий для всех слушающих сокетов на машине:

sysctl net.core.somaxconn
sysctl -w net.core.somaxconn=4096

На многих современных дистрибутивах дефолт уже поднят с исторических 128 до нескольких тысяч, но полагаться на это не стоит — образы систем и контейнерные слои нередко тянут за собой старое значение. Проверяйте фактическое число на конкретном сервере, а не то, что «должно быть по идее».

Важный факт, который решает половину проблем с настройкой backlog: значение, которое приложение передаёт в listen(fd, backlog), — это лишь пожелание. Ядро Linux, согласно man 2 listen, молча урезает его до значения somaxconn, если запрошенный backlog больше:

> If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it is silently truncated to that value.

Отсюда практическое следствие: поднять backlog в конфиге приложения до 8192, оставив somaxconn на 128, — бессмысленно, реальный размер очереди всё равно останется 128. И наоборот: поднять somaxconn до 8192, но оставить в приложении listen(fd, 128) — тоже бессмысленно, только уже с другой стороны. Оба значения нужно поднимать вместе и согласованно, причём системное — не ниже, чем то, что просит приложение.

Как это выглядит в конкретных стеках:

# nginx: backlog указывается прямо в listen
server {
    listen 443 ssl backlog=4096;
}

// Node.js: второй аргумент listen() — это backlog
server.listen({ port: 8080, host: '0.0.0.0', backlog: 4096 });

# «сырой» socket в Python
sock.listen(4096)

# systemd socket unit
[Socket]
ListenStream=8080
Backlog=4096

Для процессов, живущих под systemd с socket activation, есть отдельная тонкость: если сервис поднят через .socket-юнит, backlog настраивается директивой Backlog= в юните, а не в конфиге самого приложения — приложение в этом случае просто наследует уже созданный сокет.

Что видит клиент: тихий drop против RST

Поведение при переполнении accept-очереди зависит от одного параметра — net.ipv4.tcp_abort_on_overflow:

• tcp_abort_on_overflow = 0 (по умолчанию). Когда финальный ACK рукопожатия приходит, а места в accept-очереди нет, ядро просто отбрасывает пакет — ответа клиенту не идёт. Клиент SYN-ACK уже получил и формально считает соединение установленным, может успеть отправить данные, которые останутся без ответа. Дальше вступают таймауты клиентской стороны — подключение не отклоняется явно, а «подвисает» на несколько секунд и лишь потом обрывается. Это и выглядит как случайные необъяснимые зависания: ошибки нет, есть только тишина.
• tcp_abort_on_overflow = 1. Сервер вместо молчания сразу шлёт RST. Клиент получает явный отказ (Connection reset by peer) — некрасиво, зато быстро и однозначно.

Держать tcp_abort_on_overflow=1 постоянно — спорно: это лечит симптом (зависание вместо быстрого отказа), но не причину. Разумнее включать его временно — на период нагрузочного теста или инцидента, чтобы быстрее увидеть проблему в логах, а после найти и устранить саму причину переполнения: тесный backlog, недостаточно воркеров или медленный accept().

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

Диагностика переполнения: netstat -s, ss и счётчики ядра

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

Общая статистика переполнений — netstat -s (пакет net-tools) выводит агрегированные счётчики TCP-подсистемы:

netstat -s | grep -iE 'overflow|SYN|listen'

Ищите строки вида:

1023 times the listen queue of a socket overflowed
1023 SYNs to LISTEN sockets dropped

Первая строка — переполнение accept-очереди (ListenOverflows), вторая — отбрасывание на этапе SYN (TcpExtListenDrops). Оба счётчика накопительные с момента загрузки ядра, поэтому важна не абсолютная цифра, а её рост во времени.

Более прицельно, через nstat (снимает и умеет обнулять счётчики между замерами):

nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPSynBacklogDrops

Запустите два раза подряд с интервалом в минуту нагрузки — разница покажет, растут ли счётчики прямо сейчас, а не когда-то в прошлом.

Прямой доступ к тем же цифрам — файл /proc/net/netstat, вторая строка блока TcpExt:

cat /proc/net/netstat | grep TcpExt

Текущее состояние очереди конкретного сокета — ss -ltn показывает колонки Recv-Q и Send-Q для слушающих сокетов, и для LISTEN-сокета их смысл особый: Recv-Q — это текущее число соединений в accept-очереди, а Send-Q — тот самый настроенный backlog (эффективный, то есть уже урезанный до somaxconn, если урезание было):

ss -ltn
State    Recv-Q  Send-Q  Local Address:Port
LISTEN   0       511     0.0.0.0:443
LISTEN   487     511     0.0.0.0:8080

Во второй строке видно: приложение слушает с эффективным backlog 511, а в очереди уже 487 соединений — почти под завязку, любой всплеск трафика её переполнит. Это самый быстрый способ поймать проблему до того, как она проявится в счётчиках отбрасываний: Recv-Q, устойчиво близкий к Send-Q, — сигнал, что приложение не успевает вызывать accept(), а не что мал размер очереди. Снимайте оба показателя мониторингом с интервалом в несколько секунд во время нагрузочного теста — разовый снимок покажет один кадр, а нужна динамика накопления.

Как настроить backlog в связке с приложением

Настройка backlog — это не один параметр, а согласованная цепочка из трёх звеньев, и слабое звено определяет реальный предел независимо от того, что выставлено в остальных двух:

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

1. Определите ожидаемый пик одновременных новых подключений, а не средний RPS. Backlog переполняется всплеском, а не средней нагрузкой: тысяча клиентов, реконнектящихся разом после рестарта апстрима, создают всплеск куда острее, чем тот же трафик, растянутый на минуту.
2. Поднимите somaxconn и tcp_max_syn_backlog до сопоставимых значений, с запасом на всплеск:

# /etc/sysctl.d/99-backlog.conf
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syncookies = 1

# применить без перезагрузки
sysctl --system

1. Явно пропишите backlog в самом приложении — не полагайтесь на дефолт (у многих серверов по умолчанию это скромное значение в несколько сотен, а не то, что вы выставили в sysctl). Значение не должно превышать somaxconn — превышение просто обрежется, но лучше держать числа в осознанном согласии.
2. Убедитесь, что приложение действительно успевает вызывать accept(). Большая очередь — буфер на случай всплеска, а не решение проблемы медленного потребления. Если accept() вызывается в одном потоке с обработкой тяжёлых запросов, очередь копится независимо от размера — расширять её бессмысленно, нужно разносить приём соединений и обработку запросов по разным потокам или процессам.
3. Перепроверьте после изменений через ss -ltn — значение Send-Q должно совпадать с ожидаемым эффективным backlog, а не с тем числом, что вы написали в конфиге приложения, если оно было выше somaxconn.

Отдельно стоит увязать backlog с лимитом файловых дескрипторов: даже идеально настроенная очередь не спасёт, если у процесса не хватает ulimit -n на реальное число параллельных соединений — узкое место просто переместится на шаг дальше. Этому и разбору того, где реально проходит предел одного процесса, посвящены отдельные материалы — настройка лимитов открытых файлов через ulimit и предел одного nginx worker.

Backlog регулирует только очередь ожидания, а не итоговую пропускную способность сервера — сколько соединений он реально держит после accept(), зависит уже от других ресурсов. Смежный разбор — сколько соединений реально держит nginx до отказа.

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