During a burst of new connections, clients of a Linux TCP server wait several seconds before their first request gets any response, while the server's own application logs show nothing wrong. Explain the two kernel queues behind listen() and what happens when the accept queue fills.

## Two queues, not one The word "backlog" hides the fact that a listening socket owns two distinct kernel structures, and knowing which one is under pressure is the whole diagnosis. **The SYN queue (incomplete connections).** When a SYN arrives for a listening socket, the kernel does not yet have a connection — it has a half-open request. It replies with a SYN-ACK and records the pending request. `net.ipv4.tcp_max_syn_backlog` bounds how many such half-open requests may exist. This queue is where a SYN flood lands: an attacker sends SYNs and never completes them. Linux's defence is SYN cookies (`net.ipv4.tcp_syncookies`, enabled by default on current distributions), which encode the needed state into the sequence number so the kernel can stop storing pending requests altogether when the queue is under pressure. **The accept queue (established connections).** When the client's final ACK arrives, the handshake is complete. The connection is now fully established from TCP's point of view and moves onto the accept queue, where it waits for the application to call `accept()`. Its ceiling is `min(backlog, net.core.somaxconn)`, where `backlog` is the integer the application passed to `listen()`. Since Linux 2.2 that argument has meant the accept queue, not the sum of both queues — older documentation that says otherwise predates the split. ``` sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog ``` On kernels before 5.4 the default `net.core.somaxconn` was 128; from Linux 5.4 it is 4096. That change alone silently fixed a great many overload incidents. ## What overflow actually looks like Here is the behaviour that produces the confusing symptom. When the accept queue is full and a handshake completes, the default Linux behaviour is to **drop the packet silently** and leave the request in the SYN queue as if the ACK never arrived. The server therefore retransmits its SYN-ACK on the usual exponential schedule — roughly one second, then two, then four. Meanwhile the *client* already received the original SYN-ACK, so its `connect()` returned successfully. It believes it is connected, writes its request, and waits. From the client's seat the connection succeeded and the server is inexplicably slow. From the server application's seat nothing happened at all: `accept()` never returned this connection, so no log line, no metric, no trace span exists for it. That mismatch is the signature of accept-queue overflow, and it is why the interviewer asks the question this way. If space frees up before the retransmissions run out, the retransmitted SYN-ACK is answered and the connection quietly completes seconds late. If not, the client eventually sees a reset or a timeout. The kernel does count these events. Overflow increments `TcpExtListenOverflows` and `TcpExtListenDrops` in the network SNMP counters, and the kernel logs "possible SYN flooding" style warnings when SYN cookies engage. Rising overflow counters are the unambiguous confirmation. ## The fail-fast alternative `net.ipv4.tcp_abort_on_overflow=1` changes the policy: instead of silently dropping, the kernel sends a RST. Clients then fail immediately with "connection reset by peer" rather than hanging. That is often the better behaviour behind a load balancer that can retry another backend, because a fast, visible failure beats an invisible multi-second stall. It is worse when the overload is a brief spike that would have cleared on its own, since the default drop-and-retransmit behaviour absorbs short bursts gracefully. It is a deliberate tradeoff, not a tuning default. ## Fixing it properly Three things must line up, and fixing only one is the classic incomplete answer: 1. **Raise `net.core.somaxconn`** — it is only a ceiling. 2. **Raise the application's `listen()` backlog** — the effective queue is the *minimum* of the two, so an app that hardcodes 128 stays at 128 no matter what the sysctl says. nginx takes `backlog=` on its `listen` directive; most language runtimes expose a backlog parameter on their listen call. 3. **Make the application accept faster** — the queue is a shock absorber, not capacity. If the accept loop is blocked on slow work, on a saturated thread pool, or on a lock, a deeper queue only means more clients waiting longer before the same failure. A permanently full accept queue is a capacity problem wearing a tuning problem's clothes. ## The judgement an interviewer wants A large backlog trades visible rejection for invisible latency. Queueing connections you cannot serve within a client's timeout accomplishes nothing except making the failure slower and harder to see, and it inflates tail latency for everyone. The right size is roughly what you can drain within the burst, paired with real admission control — shedding load or returning a fast error — for the rest. Say that, and the mechanism answer becomes a design answer.