What control frame floods test
HTTP/2 allows clients to send control frames (such as PING, SETTINGS, PRIORITY, and WINDOW_UPDATE) asynchronously outside of active request/response data streams. Because RFC 7540 / 9113 mandates immediate server acknowledgment for PING frames and state tracking for WINDOW_UPDATEs, an adversary can burn high server CPU without sending any real request payload or triggering standard URL rate limiters.
HTTP/2 PING & SETTINGS flood (http2_ping_flood)
Sends continuous 8-byte PING frames expecting immediate PING-ACK responses, accompanied by empty SETTINGS frames. This tests whether your web server or proxy enforces control-frame rate limits (e.g. NGINX http2_max_concurrent_pushes, Envoy max_consecutive_inbound_frames_with_empty_payload) and prevents event-loop starvation.
HTTP/2 WINDOW_UPDATE stream churn (http2_window_update_flood)
Generates high-frequency 1-byte increment WINDOW_UPDATE frames on active streams. This exercises the server's flow-control state tracking and locks to confirm that stream state mutation does not cause thread lock contention or algorithmic degradation.
Safe execution
All simulations run against your verified domain with real TLS handshakes and rate-governed frame streams. Live health probes verify service availability throughout the test.
Reading the results
Resilient: The server caps control frame throughput per session or issues GOAWAY (ENHANCE_YOUR_CALM) if limits are exceeded, keeping CPU usage minimal.
Under strain: Worker process CPU saturates at 100% processing control-frame event queues, degrading legitimate HTTP/2 request processing.
← All DDoS simulations