Accept and parse: from kernel queue to a typed request

A service passes every load test, then refuses connections in production during a traffic spike — not with a 500, but with a TCP reset before any of your code runs. The logs are empty because the request never reached the application. The bottleneck was a kernel queue with a default depth of 128, set in 1999 and never changed.

Two queues, not one

A listen() socket has two kernel-side queues, and confusing them causes most “connections refused under load” mysteries:

• SYN queue (incomplete) — connections mid-handshake: the server got a SYN, sent SYN-ACK, and is waiting for the final ACK. Sized by net.ipv4.tcp_max_syn_backlog (commonly ~1024–2048).
• Accept queue (complete) — fully established connections waiting for the application to call accept(). Sized by min(listen(backlog), net.core.somaxconn).

When your handler is slow or your process is busy, it stops calling accept() fast enough. The accept queue fills. Once full, the kernel drops new completed connections — the client sees a timeout or reset, and your application logs nothing because the connection was never handed up.

The 128 trap

net.core.somaxconn defaulted to 128 on Linux for two decades (raised to 4096 in kernel 5.4). Even today many container base images and managed platforms still ship 128. A framework that calls listen(511) (Node’s default backlog) is silently capped to 128 by somaxconn. Under a burst, 129 simultaneous pending connections is enough to start dropping.

Parsing: bytes to a request

Once accept() returns a socket, the server reads bytes and runs an HTTP parser — a state machine that recognizes the request line (GET /path HTTP/1.1), then header lines, then the body. Parsing is not free of limits:

• Header size cap. Node.js limits total headers to 16 KB (--max-http-header-size, raised from 8 KB in Node 12). nginx uses large_client_header_buffers (default 4 8k). Exceed it and you get 431 Request Header Fields Too Large or a 400 — most often caused by a bloated Cookie header or a large JWT.
• Request line length. A URL longer than the buffer (nginx 8k by default) is rejected before routing.

Where the body comes from

The parser learns the body length one of two ways, and they fail differently:

• Content-Length: N — read exactly N bytes. A lying or truncated length causes a hang or a parse error.
• Transfer-Encoding: chunked — read sized chunks until a zero-length chunk. Streaming-friendly, but the classic vector for request smuggling when a proxy and an app server disagree about which header wins.

A safe parser rejects a request that carries both Content-Length and Transfer-Encoding (RFC 9112 §6.1) — disagreement here is exactly how a smuggled request hides a second request inside the first.