QUIC 0-RTT Resumption
QUIC 0-RTT lets a returning client send encrypted application data in its very first flight using resumption secrets, removing the handshake round trip while remaining replayable and constrained.
Definition
Zero-RTT is the resumption mode where a client that holds a prior session ticket sends application data immediately with flight zero, encrypted under keys derived from the ticket. The server may accept, reject, or ignore early data; anti-replay windows bound duplication attacks, and non-idempotent handling is the application contract.
Context and scope
Used by browsers and mobile apps revisiting familiar endpoints, where shaving one round trip visibly improves perceived latency on high-RTT networks.
Common misconceptions
- 0-RTT is fully encrypted so it is safe — encrypted data can still be replayed by an attacker
- The server must always accept early data — it can reject 0-RTT and force a full 1-RTT handshake at any time
- 0-RTT helps first-time visitors — it requires a cached resumption secret from a previous connection
Anti-patterns
- Accepting 0-RTT requests that mutate state without replay windows or idempotency keys
- Treating 0-RTT rejection as an error path instead of the normal fallback it is designed to be
- Logging early-data requests as fully authenticated before the handshake completes
Related concepts
Related examples
Authoritative source
What it is
A fresh QUIC or TLS 1.3 handshake costs one round trip before the client can send request bytes. 0-RTT spends a previously issued ticket to derive keys instantly, so the first packet already carries encrypted request data. The server processes it only if its anti-replay state and policy allow.
How it works
The ticket from an earlier connection carries resumption secrets; the client derives early keys and sends data plus the rest of the handshake. The server validates the ticket, consults its replay cache, and either processes early data or rejects it with a full handshake. Later flights always use fresh keys.
When to use it
Returning-visitor latency on high-RTT paths: repeat API calls from mobile apps, browser navigations to known origins, service mesh reconnections. Gains are one RTT, which on a 150-millisecond path is a visible fraction of time-to-first-byte.
Pitfalls
Early data is the classic replay vector: an attacker can duplicate the flight zero verbatim. Restrict 0-RTT to idempotent reads or add per-endpoint anti-replay and idempotency keys. Load balancers must share replay state or route consistently, or they silently widen the window.