The low and slow attack entered common use in 2009, when the Slowloris tool showed that a single laptop could hold a web server's entire worker pool open by trickling out partial requests. It still matters because the mechanism needs almost no bandwidth, which is exactly the blind spot a DDoS test built around volume will walk straight past. Instead of overwhelming a server with traffic, it opens a handful of connections and keeps each one barely alive, so the resource that runs out is concurrency rather than bytes on the wire.
How a low and slow attack works
A server allocates something for every connection it is handling: a thread, a process, or at minimum a socket and its buffers. That pool is finite. The attack opens connections and then feeds each one request data at a crawl, one header line or a few body bytes at a time, timing each dribble to land just before the receive timeout would fire. The connection never finishes and never errors out, so the server keeps the slot reserved, waiting.
The variants differ only in where they place the stall. Slowloris holds the request headers open and never sends the blank line that would end them. A RUDY attack moves the stall into the body of a POST. A slow read attack turns the idea around entirely, throttling how quickly it accepts the answer so the server cannot let go of the connection from its end. All three are Layer 7 application-layer attacks defined by duration rather than rate, which is what separates them from a request flood sharing the same tier.
Why it matters under attack
By design the volume is negligible, sometimes a lone host consuming a fraction of a megabit, which keeps the attack under every threshold a rate limiter or a volumetric detector is set to watch. The server quietly stops accepting new connections while its throughput graphs read normal, the same silent failure a state-exhaustion attack produces but reached through the application's own connection accounting rather than a kernel table.
That quietness is why a stack tuned only for floods is the classic victim. It sails through every bandwidth test and then falls to a laptop, because the two attacks stress completely different resources and passing one says nothing about the other. The concurrency ceiling is invisible on the dashboards a network team watches.
The server's architecture decides how exposed it is. A thread-per-connection or process-per-connection model has a hard, low ceiling that a few hundred stalled connections fill outright, while an event-driven server that multiplexes thousands of connections per worker pays only a file descriptor per stall and resists the classic form. The attack does not vanish there; it looks for a different finite resource, which is why the same slow-hold idea reappears in newer clothing on HTTP/2, where cheaply opened and abandoned streams pin state on the server without ever completing work.
What a DDoS test measures
A low and slow test exercises the controls that actually govern this class: the timeouts that cap how long a half-sent request may stall, a floor on acceptable data rate that closes a connection dribbling below it, a ceiling on simultaneous connections from one source, and the speed at which a freed worker returns to the pool. The output is not a bandwidth figure; it is the number of held connections at which new visitors start being turned away, and how fast capacity recovers once the stall ends.
It also checks where the defense sits. An event-driven server or a buffering reverse proxy that absorbs the stall at the edge, where an idle connection is cheap, protects a worker pool that a thread-per-connection origin would expose directly. How this vector is exercised alongside the rest of the application-layer surface is described in Application-Layer (L7) DDoS Testing.