Accept и парсинг: от очереди ядра до типизированного запроса

Сервис проходит все нагрузочные тесты, а потом в проде при всплеске трафика отклоняет соединения — не с 500, а TCP-сбросом ещё до запуска вашего кода. Логи пусты, потому что запрос не дошёл до приложения. Узким местом была очередь ядра с глубиной по умолчанию 128, заданной в 1999 году и ни разу не изменённой.

Две очереди, а не одна

У сокета с listen() есть две очереди со стороны ядра, и их путаница порождает большинство загадок «соединения отклоняются под нагрузкой»:

• SYN-очередь (неполные) — соединения в середине рукопожатия: сервер получил SYN, отправил SYN-ACK и ждёт финальный ACK. Размер задаётся net.ipv4.tcp_max_syn_backlog (обычно ~1024–2048).
• Очередь accept (полные) — полностью установленные соединения, ждущие вызова accept() приложением. Размер — min(listen(backlog), net.core.somaxconn).

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

Ловушка 128

net.core.somaxconn два десятилетия по умолчанию был 128 в Linux (поднят до 4096 в ядре 5.4). Даже сегодня многие базовые образы контейнеров и управляемые платформы всё ещё ставят 128. Фреймворк, вызывающий listen(511) (бэклог по умолчанию в Node), молча обрезается до 128 через somaxconn. При всплеске 129 одновременно ожидающих соединений уже достаточно, чтобы начать терять.

Парсинг: байты в запрос

Как только accept() вернул сокет, сервер читает байты и запускает HTTP-парсер — конечный автомат, который распознаёт строку запроса (GET /path HTTP/1.1), затем строки заголовков, затем тело. Парсинг не свободен от лимитов:

• Лимит размера заголовков. Node.js ограничивает суммарные заголовки 16 КБ (--max-http-header-size, поднято с 8 КБ в Node 12). nginx использует large_client_header_buffers (по умолчанию 4 8k). Превышение даёт 431 Request Header Fields Too Large или 400 — чаще всего из-за раздутого Cookie или большого JWT.
• Длина строки запроса. URL длиннее буфера (по умолчанию 8k в nginx) отклоняется ещё до маршрутизации.

Откуда берётся тело

Парсер узнаёт длину тела одним из двух способов, и они падают по-разному:

• Content-Length: N — прочитать ровно N байт. Ложная или обрезанная длина даёт зависание или ошибку парсинга.
• Transfer-Encoding: chunked — читать чанки с указанием размера до чанка нулевой длины. Удобно для стриминга, но это классический вектор request smuggling, когда прокси и сервер расходятся в том, какой заголовок главнее.

Безопасный парсер отклоняет запрос, несущий одновременно Content-Length и Transfer-Encoding (RFC 9112 §6.1) — расхождение здесь и есть способ спрятать второй запрос внутри первого.