01 / Fundamentals

5 Resources to Exhaust

A DDoS attack exhausts a finite resource. There are exactly 5 resources to exhaust. Every attack in existence targets one of them. Lower levels need more volume. Higher levels need less, but hit harder.

Hover a layer
Select a resource level to see what gets exhausted, example attacks, and server effect.
02 / Concurrency

The HTTP Version Multiplier

The same 10,000 requests per second looks like 10,000 connections on HTTP/1.0 but only 10 on HTTP/2. Firewalls that count connections are blind to the 100 streams multiplexed inside each one.

03 / Mechanisms

23 Core Mechanisms

Every attack in the 233-entry taxonomy reduces to one of 23 fundamental server-side effects. The industry groups them into 3 marketing categories. We decompose them into 23 because each needs different detection and different mitigation.

04 / Blind Spots

Where Defenses Are Blind

Combining target level with HTTP version reveals exactly where standard defenses cannot see. Red cells are blind spots that most vendors cannot detect.

05 / The Model

The Complete DDoS Formula

Every DDoS attack in history decomposes into these 5 components. Hover each term to understand its contribution to deadliness.

--
Detection Difficulty
--
Deadliness
--
Asymmetry
06 / Paradox

The Protocol Paradox

Better protocols are simultaneously harder to overwhelm AND introduce new attack surfaces. Empirical testing (IIS on GCP) showed HTTP/1.1 dies at 2,500 RPS while HTTP/2 survives to 10,000 RPS - a 4x resilience boost. But HTTP/2 enables Rapid Reset, which no vendor in our test detected.

HTTP/1.1 KILL THRESHOLD
2,500
RPS to DoS
HTTP/2 KILL THRESHOLD
10,000
RPS to DoS (4x more resilient)
WHY H/2 IS MORE RESILIENT: HPACK compresses 400-byte headers to ~30 bytes. Binary framing parses faster than text scanning. Multiplexing on 1 connection = fewer sockets and TLS sessions.
WHY H/2 IS MORE DANGEROUS: Stream-level attacks (Rapid Reset, CONTINUATION, Stream Exhaustion) don't exist on H/1.1. They're invisible to L4 firewalls. 0 of 10 vendors detected our 75 RST_STREAM probe.
NET RESULT: Script kiddie with GET flood? H/2 saves you. Advanced attacker with Rapid Reset? H/2 kills you. The correct posture: use H/2 for efficiency, deploy H2-aware L7 inspection to cover the new blind spots.
07 / Reality Check

The Industry-Wide Blind Spot

We tested 10 major CDN/WAF vendors with gentle H2 control-frame and stream-lifecycle probes. The aggregate picture, not per-vendor grades, is what matters for defenders.

RST_STREAM DETECTION
0 / 10
vendors reacted to 75 rapid cycles
IDLE STREAM HOLD <5s
2 / 10
killed idle POST streams quickly
H3 / QUIC COVERAGE
4 / 10
advertised H3 at edge
H2->H1.1 DOWNGRADE
3 / 10
lose H2 semantics to origin
KEY FINDING: No vendor in the sample reacted to 75 rapid RST_STREAM cycles. This doesn't mean they can't, our probe volume is deliberately below real attack thresholds (1000+ RSTs/sec). It means detection requires sustained attack-level traffic that small recon tests don't trigger.
DIFFERENTIATOR: Idle stream handling is the test that separates the field. Most holders keep unfinished POST streams open 15+ seconds; a minority tear them down inside 5. Both behaviors are defensible design choices, but they produce very different exposure profiles.
CAVEAT: These are point-in-time aggregates from semi-active probing. Per-vendor scoring is not published here because low-volume recon cannot fairly characterise behavioural ML, premium-tier features, or thresholds tuned for real attack traffic. Per-engagement results are shared privately under NDA.