All DDoS Definitions
DDoS Testing Definition

Slowloris

Where most attacks work by sending more, Slowloris works by sending less. It opens connections and then feeds them a trickle of data, holding each one open without ever completing a request, until the server has no free workers left for anyone else. A DDoS test that measures only bandwidth will not see it coming. It is the canonical instance of the low and slow attack class: instead of flooding a server with volume, it opens many connections and keeps each one alive with a trickle of data, holding a worker or socket hostage at almost no bandwidth cost.

Slowloris: partial requests hold the connection pool open Attacker one host tiny bandwidth partial headers, sent slowly, never completing Connection pool (workers) held open held open held open held open held open held open held open held open Legitimate user wants a connection Connection refused every worker is occupied Test validates connection and header timeouts, the max concurrent-connection limit, and whether workers are reclaimed when a connection stalls. BlackNeuron™
Slowloris: partial HTTP requests held open occupy every worker in the connection pool, so a legitimate user is refused

How Slowloris works

What is specific to Slowloris is the header trick. It opens an HTTP connection and starts sending request headers, but never sends the blank line (the terminating CRLFCRLF) that tells the server the request is complete. Every so often, before the receive timeout fires, it sends one more partial header line: X-a: b, then another, then another. The server keeps waiting for a request that never finishes.

That single detail is what separates it from its siblings. A RUDY attack stalls on the request body instead, dribbling out a POST one byte at a time under a large declared Content-Length. A slow read attack inverts the direction, advertising a tiny TCP receive window so the server cannot flush its response and the connection stays pinned from the other end. All three drain the same resource; Slowloris does it on the request headers.

The vector lives or dies on the server's concurrency model. A server that dedicates a thread or process to each connection, the classic Apache prefork model, has a hard ceiling (MaxRequestWorkers, historically defaulting to 256) and Slowloris fills it directly: a few hundred stalled connections and there is no worker left for a real visitor. An event-driven server that multiplexes thousands of connections per worker, such as nginx or Apache's event MPM, is far more resistant because a stalled connection costs a file descriptor rather than a whole worker. The attack does not go away there, it just needs a different bottleneck.

Why it matters under attack

Slow attacks are dangerous precisely because they are quiet. The traffic rate is trivial, often a single host and well under a megabit, so rate limits keyed on requests or packets per second never fire, and volumetric detection sees nothing worth alarming on. The origin simply stops accepting new connections while every graph reads normal.

Slowloris made this concrete. Released in 2009 by the researcher Robert Hansen (RSnake), it was reported in use against government websites during that year's Iranian election protests, one of the first times a low-bandwidth application-layer tool visibly took down real targets. It remains a standard test case because so many stacks are still tuned only for volume.

Slowloris: partial HTTP headers hold every worker open One host, partial headers Worker connection pool each stalled request pins one worker until MaxClients is full legitimate request, no free worker Web server thread-per-connection held open, never completes Bandwidth stays trivial; a header receive timeout, not a rate limit, is the control that catches it BlackNeuron™
Animated Slowloris: one low-bandwidth host drip-feeds partial headers that hold every worker in the pool open, so a legitimate request finds no free slot

The controls that actually catch it are timeouts and connection accounting, not throughput limits. Apache's mod_reqtimeout sets a deadline and a minimum data rate for receiving the request headers and body, so a connection that dribbles gets closed instead of parked. A reverse proxy or load balancer that buffers the full request before forwarding it to the origin absorbs the stall at the edge, where a stalled connection is cheap, rather than at the worker pool it is meant to protect.

What a DDoS test measures

A Slowloris test validates the controls that govern this class specifically: the header and body receive timeouts, the minimum acceptable data rate, the concurrent-connection ceiling per source, and how promptly the server reclaims a worker once a connection stalls. The result is not a bandwidth number; it is the count of held connections at which new visitors start being refused, and how quickly capacity returns after the attack stops.

It also tests where the defense sits. If an edge proxy is supposed to buffer slow requests, the test confirms it actually does before the origin sees them, and that a rate limit keyed on request count is not being mistaken for protection against a vector that sends almost no requests at all. A stack that passes every volumetric test can still fall to a laptop running one of these, which is exactly why the slow class is tested on its own terms.

For where slow attacks sit among the application-layer vectors, see Understanding DDoS Attack Vectors.