ddos-sim.com All simulations Build a test plan

Layer 3–4 · Transport · quic_initial_flood

QUIC / HTTP3 Initial flood test

The quic_initial_flood simulation emits cryptographically valid QUIC (HTTP/3) Initial packets over UDP at a fixed rate, each with a fresh connection ID so the server must decrypt and try to set up a new connection — against a host you own.

Layer L3/L4 Protocol QUIC / HTTP3 (UDP) Command quic_initial_flood Access Quote on request

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.

Authorized targets only

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.

Honest scope

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

How to run a QUIC / HTTP3 Initial flood test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the quic_initial_flood command to a timeline in the portal and set the rate, duration, and any concurrency limit.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.

Configure a QUIC / HTTP3 Initial flood test in the portal →

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
← All DDoS simulations