In `ss -tln` output on Linux, the Recv-Q and Send-Q columns mean something different for a row in LISTEN state than for one in ESTAB. Explain both readings, and what a persistently non-zero Recv-Q on a listening socket tells you about the service.

## Two columns, two meanings `ss` prints Recv-Q and Send-Q for every socket, and the units change with the socket's state. This is the single most misread pair of numbers in Linux network triage. **On an established socket (`ESTAB`)** they are byte counts: - **Recv-Q** — bytes that have arrived in the receive buffer and the application has not yet read. A large, growing value means the reader is slower than the sender. - **Send-Q** — bytes the application has written that have not yet been acknowledged by the peer. A large, growing value means the data is not getting out: a stalled peer, a congested or lossy path, or a receiver advertising a zero window. **On a listening socket (`LISTEN`)** they are connection counts: - **Recv-Q** — how many fully established connections are sitting in the accept queue right now, waiting for the application to take them. - **Send-Q** — the maximum depth of that queue for this socket, fixed when the service called `listen()` (and capped by a kernel-wide limit). ```bash ss -tln # State Recv-Q Send-Q Local Address:Port # LISTEN 129 128 0.0.0.0:8080 # LISTEN 0 511 0.0.0.0:80 ``` The first row is the interesting one. The second is a healthy listener: nothing queued, a generous ceiling. ## What a non-zero listening Recv-Q actually means It means the kernel has already done its half of the work. The three-way handshake completed, the connection is real and the client believes it is connected — it is simply waiting in a queue because the server process has not called `accept()` to pick it up. Whatever is wrong is therefore **above the socket layer, inside the application**: - Every worker thread is blocked on something slow — a database call, a lock, a downstream HTTP request with no timeout. - The thread or connection pool is sized too small for the arrival rate. - The process is paused: a long garbage-collection pause, heavy swapping, or CPU starvation from a noisy neighbour. - A single-threaded accept loop is doing work per connection that belongs on a worker. A brief non-zero value under a burst is normal and healthy — the queue exists precisely to absorb bursts. What matters is whether it is *persistent* or repeatedly climbing, which you see by sampling: ```bash watch -n1 "ss -tln 'sport = :8080'" ``` The client-visible symptom is distinctive and worth naming: connections that succeed instantly but then sit silent for seconds before the first byte of response, while the application's own logs show fast request handling. The application never sees the waiting time, because its clock starts at `accept()`. ## When the queue is full Once the accept queue is at its limit, new completed connections cannot be added and the kernel drops them; depending on configuration the client sees either a stall and a retry or an outright failure. Because the drop happens below the application, nothing appears in the service log — which is exactly why a candidate who only reads application logs concludes "the app is fine" while users are timing out. The kernel does count these events, and that counter is the corroboration you want: ```bash nstat -az TcpExtListenOverflows TcpExtListenDrops ``` A `TcpExtListenOverflows` value that climbs while you watch confirms that the accept queue overflowed rather than that you caught one unlucky sample. `nstat -az` prints absolute values; running `nstat` without `-a` shows the delta since the last run, which is often more useful. ## Reading the established rows in the same breath While you are there, the `ESTAB` rows tell a complementary story. Many connections with a large Recv-Q against your own service means your process is not reading fast enough. A large Send-Q on connections to a downstream service means your data is not being acknowledged — that is a path or peer problem, not a local one. `ss -tim` adds the TCP internals and socket memory to these rows if you need to go deeper. ## The fixes, and their order The reflex fix is to raise the backlog. That is worth doing when the limit is plainly too small for the arrival rate, but it should be second: a bigger queue only buys more time before the same wall, and it *increases* the latency clients suffer while queued. The primary fix is to make the application accept and serve faster — unblock the workers, add capacity, put timeouts on downstream calls so threads return, or scale out. Raise the queue when you need headroom for legitimate bursts, not as a way to hide a service that cannot keep up. The interview-grade summary: a non-zero Recv-Q on a `LISTEN` row redirects the whole investigation from the network to the process, which is a large saving on a live incident.