What a QUIC Initial flood does
QUIC runs over UDP and begins with an Initial packet the server must remove header protection from, decrypt, and process to start a handshake. A flood of valid Initial packets, each carrying a new connection ID, makes the server treat every packet as a brand-new connection — decrypting it and allocating handshake state per packet. It probes how your HTTP/3 stack holds up under connection-initiation pressure.
How ddos-sim.com simulates it safely
ddos-sim.com emits well-formed QUIC v1 Initial packets over a single connected UDP socket to a verified domain pinned to a public address, at the domain’s rate limits, using the real source address. The packet contents are fixed and non-configurable and nothing is spoofed.
Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.
This is a handshake-initiation flood: the packets carry opaque handshake bytes rather than a complete TLS ClientHello, and QUIC’s own address-validation Retry and anti-amplification limits blunt reflection and state growth. It measures Initial-processing and connection-setup pressure, not completed handshakes.
What the test exercises
- QUIC Initial header-protection removal and AEAD decryption cost
- Per-connection handshake-state allocation on the first packet
- Address-validation and Retry behavior
- Anti-amplification (3× limit) enforcement
- UDP ingress filtering, rate limits, and HTTP/3 stack resilience
When to run a QUIC Initial flood test
Run a QUIC Initial flood test when you serve HTTP/3 and need to know how the handshake and its crypto cost hold up under a burst of new connections.
- You've enabled HTTP/3 (QUIC) and want to measure how many Initial packets the server can set up and decrypt.
- You want to confirm QUIC retry / address validation and rate limits engage under a flood of fresh connection attempts.
- A CDN or edge terminates QUIC and you need to confirm it absorbs the handshake pressure.
How to run a QUIC / HTTP3 Initial flood test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
quic_initial_floodcommand to a timeline in the portal and set the rate, duration, and any concurrency limit. - Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
- Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
- Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.
Reading the results
Resilient: Address validation and rate limits shed excess Initials, handshake CPU stays bounded, and established HTTP/3 sessions are unaffected.
Under strain: Handshake CPU saturates, new HTTP/3 connections stall, or the server struggles under the volume of Initial packets.
Availability & limits
The QUIC Initial flood is a network-layer method: it is priced per engagement, and your domain must be verified and reviewed before it can run.
Frequently asked questions
Does the target need HTTP/3?
The target must terminate QUIC / HTTP/3 on the tested UDP port for the flood to reach a QUIC stack; otherwise the packets are just UDP traffic.
Are the packets spoofed?
No. The real source address is used, so this is not a reflection attack — it exercises your own endpoint’s Initial-handling.
Rehearse a QUIC / HTTP3 Initial flood test against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan