All DDoS Definitions
DDoS Testing Definition

Slow Read Attack

Unlike Slowloris and the RUDY attack, which stall the request on the way in, a slow read attack stalls the response on the way out. The request is complete and valid; the abuse is that the client refuses to accept the answer, which is the kind of asymmetry a thorough DDoS test has to probe, because nothing about the request itself looks wrong.

It is a low and slow attack like the other two: hold connections open at negligible bandwidth until the worker pool is full. What is specific to slow read is that the stall lives at the TCP layer, in the receive window, not anywhere in the HTTP request.

Slow read: tiny receive window, buffer can't drain Attacker sends a full, valid request, then reads the reply very slowly TCP window = 1 byte near-zero bandwidth complete request reads 1 byte at a time Server worker full response ready but client won't accept it send buffer fills, cannot flush socket blocked on write worker pinned open, never freed Legitimate user needs a free worker from the same pool tries to connect ✕ no worker left Test drives the send-timeout, minimum client receive-rate, and per-source connection cap that decide whether a stalled reader ever releases its worker. BlackNeuron™
Slow read attack: the client advertises a near-zero TCP receive window so the server cannot drain its response buffer, pinning each worker open at near-zero attacker bandwidth

Throttling the read side

The client sends a complete, valid request, ideally for a large resource so the response is big, then advertises a tiny TCP receive window, sometimes a single byte and sometimes zero. That window tells the server it can only accept data in minuscule increments. The server has a full response ready but TCP flow control forbids sending more than the window allows, so the connection and its send buffer stay pinned. The stack enters zero-window probing and honors the persist timer, dutifully waiting for a window that never opens.

Because the trick is at the transport layer, the HTTP request is entirely legitimate. That is the property that separates slow read from its siblings: Slowloris and RUDY both feed the server an incomplete request, while a slow reader has already sent a perfect one and simply will not drain the reply. Requesting a large object makes it worse, because a bigger response takes longer to force through a pinhole window.

Why it evades request-based controls

Any control keyed on request rate or request size sees a normal, complete request and nothing more, because the abuse lives entirely on the read side. A few hundred slow readers, each costing the attacker almost no bandwidth, can hold every worker and socket the server has. As with the whole low and slow family, an event-driven server that multiplexes connections is more resistant than a thread-per-connection one, but the send buffer and socket still cost something per stalled reader.

In a test the vector is usually reproduced with slowhttptest in its slow-read mode, pointed at a large static asset so there is a substantial response to hold hostage.

Slow read attack: the client will not drain the response slow readers, tiny TCP receive window worker pool each unflushed response keeps its worker pinned new visitor turned away app server response ready, cannot send send buffer stuck behind a pinhole window A send-timeout and a receive-rate floor free the worker; a request-rate limit sees nothing wrong BlackNeuron™
Animated slow read attack: a few clients advertise a near-zero TCP receive window, so each ready response cannot be flushed and its worker stays pinned while a legitimate request finds no free slot.

What a DDoS test measures

The controls that apply here are the mirror image of the request-side ones. A slow read test measures the send-timeout, a cap on how long the server will spend transmitting one response; the minimum client receive-rate the server tolerates before it closes a stalled reader; and the per-source connection cap that decides whether a slow reader ever releases its worker. A buffering reverse proxy helps less than it does against slow requests, because the slow side is now the downstream client, so the test also checks whether the edge itself enforces a send-timeout rather than assuming the origin will.

The output is the number of stalled readers at which new visitors start being refused, and how fast capacity recovers once the readers let go. What that means for the defender's actual decision, which timeout to set and how low a receive rate to tolerate, is worked through in DDoS resilience testing.