Unlike the SYN backlog, which holds half-open connections the kernel manages entirely on its own, the TCP accept queue holds fully established connections that are waiting for the application to take them. That second queue is a distinct failure surface, and stressing it is one of the tuning checks a thorough DDoS test is built to run. It is where a connection sits after the handshake succeeds but before any code has touched it.
Two queues, not one
A listening socket has two queues behind it. A SYN arrives and the half-open connection waits in the SYN backlog until the final ACK completes the handshake. At that instant the connection is fully established, and the kernel moves it into the accept queue, where it waits for the application to call accept() and start serving it.
The accept queue is bounded, by the smaller of the backlog argument the program passed to listen() and the system limit somaxconn. Once it is full, the kernel has an established connection it cannot hand anywhere. By default it drops the connection silently; with tcp_abort_on_overflow set it sends a RST instead, which at least tells the client rather than leaving it to time out.
The important consequence is that no packet flood is required to fill this queue. If the application is slow to call accept(), because a worker is blocked on a database call, stalled in a garbage-collection pause, or simply out of threads, connections pile up behind it and are dropped even under ordinary traffic. The bottleneck is the application's own pace, not the network's.
Why it matters under attack
This is the queue that turns a connection flood into dropped requests. An attack that opens established connections faster than the application drains them fills the accept queue regardless of how well the SYN backlog and SYN cookies are tuned, because those defenses only govern the handshake, not what happens after it.
The failure is quiet in the worst way. Every handshake completed, so packet captures and connection counters look healthy, while the application never sees the connections the kernel already threw away. Teams watching the SYN layer see nothing wrong, and the drop is invisible unless something is measuring the accept queue's depth directly.
What a DDoS test measures
A test characterizes the rate at which accept() falls behind arriving connections, and the point at which somaxconn, the listen backlog, and worker concurrency stop holding under sustained load. It watches for the silent drop specifically: established connections discarded at the queue while every upstream metric still reads green.
What a filled accept queue costs in dropped requests, and how to separate it from a bandwidth-bound failure, is worked through in DDoS resilience testing.