DDoS Attack Visualizer: When a Queue Overflows

One server, an M/M/1 queue

A web server handling requests behaves, to a good first approximation, like the textbook M/M/1 queue: requests arrive at some average rate lambda (a Poisson process), get served at some average rate mu, and wait in a single first-in-first-out line if the server is busy. The whole behaviour of the queue collapses onto one dimensionless number, the utilisation rho = lambda / mu:

rho = lambda / mu                    // utilisation, must stay < 1

L = rho / (1 - rho)                  // average number of requests in the system
W = L / lambda                       // average time a request waits (Little's law)

// as rho -> 1, both L and W diverge -- not linearly, but explosively

That divergence is the whole story of a denial-of-service attack: response time doesn't degrade gracefully as load approaches capacity, it blows up. A server sitting comfortably at 70% utilisation with a snappy average wait can be pushed to 99% by a modest-looking traffic increase and suddenly have a queue that's effectively infinite — every legitimate request now waits behind an ever-growing backlog of attack traffic.

Why 'distributed' matters

A single attacking machine is easy to block by IP address, and its own upstream bandwidth caps how much lambda it can generate. A botnet of thousands of compromised or rented machines multiplies lambda by the number of sources and defeats IP-based blocking, since there is no single address to drop. Attackers also use amplification: send a small spoofed-source query to an open DNS or NTP server and the server replies with a much larger response directly to the victim, turning a modest outbound stream into a flood tens of times its size for free.

Mitigations map directly onto the queueing model

rate limiting     cap lambda per source before it reaches the server
                  -- keeps any single source from monopolising mu

traffic scrubbing route suspicious traffic through a filtering layer
                  that drops malformed/spoofed requests before they
                  reach the real service -- reduces effective lambda

load balancing /  spread lambda across many servers (many mu's) so
anycast           no single queue sees the full attack volume; anycast
                  additionally lets nearby routers absorb load locally

Every one of those techniques is, mathematically, an attempt to either lower the effective lambda hitting any one queue or raise the effective mu serving it — because rho = lambda/mu is the only knob that matters, and keeping it under 1 is the only way to keep response times bounded.

The economics of the attack

The defender's cost problem is the mirror of the queueing problem: keeping rho comfortably below 1 against a peak attack means provisioning capacity that sits idle almost all the time, which is expensive, while renting botnet capacity to attack is comparatively cheap. That asymmetry is exactly why cloud-scale scrubbing services and anycast networks exist — they let many defenders share a huge pool of mu across the internet rather than each over-provisioning their own server for a worst case that might never come.

Frequently asked questions

Try it live

Everything above runs in your browser — open DDoS Attack Visualizer and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.