HTTP/3 & QUIC — UDP, Migration, 0-RTT & HOL Fixes
HTTP/3 runs on QUIC over UDP, with TLS 1.3 inside the transport. Loss stays on one stream, a connection can survive an IP change, and 0-RTT early data can be replayed.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Question ladder
L1
Does HTTP/3 use TCP?
Answer
No. QUIC runs on UDP and implements its own reliability, congestion control, and streams.
L2
How does HTTP/3 fix head-of-line blocking?
Answer
A lost packet is recovered for the streams it carried. Sibling streams whose packets arrived can still be delivered.
L3
What is connection migration?
Answer
The peers keep the QUIC connection when the client IP or port changes, using connection ids. A PATH_CHALLENGE checks the new path.
L4
Why is 0-RTT unsafe for a charging POST?
Answer
Early data is encrypted with keys from a previous session and can be replayed by anyone who captured that flight.
L5
What if UDP is blocked?
Answer
The client falls back to HTTP/2 on TCP. The origin must keep that path correct.
L6
How is QPACK different from HPACK?
Answer
HPACK assumes a total order on one connection. QPACK allows header blocks on streams that arrive out of order.
L7
Where should an enterprise terminate HTTP/3?
Answer
Usually at the CDN or edge that understands connection ids. Inner hops can stay on HTTP/2. Anycast and VPC design stay on their own pages.
Failure modes
UDP/443 dropped
A hotel or enterprise firewall blocks QUIC. Clients that have no HTTP/2 fallback fail even though TCP would have worked.
0-RTT replay
A captured early flight is sent again. A non-idempotent request runs twice.
Load balancer pinned to the 4-tuple
After migration the packets arrive from a new address and a QUIC-unaware balancer sends them to the wrong server.
Amplification on a spoofed path
The server must path-validate before it sends a large response to a new client address.
Misconceptions
QUIC is TLS over UDP.
TLS 1.3 supplies the keys. Streams, loss recovery, congestion control, and migration are QUIC.
HTTP/3 replaces HTTP/2 everywhere.
It is an edge optimization with a required fallback. Datacenter RPC can stay on HTTP/2.
0-RTT means the request is free of replay risk if it is small.
Size is irrelevant. Idempotence and an anti-replay design are the gate.
Interviewer traps
Redesigning anycast or the CDN cache to explain Alt-Svc.
Alt-Svc and HTTPS records advertise support. Cache hierarchy and anycast edge stay on their pages.
Explaining TCP congestion control in detail as if QUIC had none.
QUIC has congestion control. The interview point is independent stream recovery, not the absence of a window.
Design scenario
Same prompt for every reader.
Requirements
In-flight reads survive the network change when QUIC is available. Card charges never use early data. UDP failure falls back to HTTP/2 within one attempt.
Traffic / scale
Short GETs dominate. Charges are rare and must not be replayed.
Latency
A lost packet delays one stream, not the whole session. A repeat visit may use 0-RTT for GET only.
Consistency
A replayed 0-RTT payload cannot create a second charge.
Availability
HTTP/2 on TCP remains deployed and monitored.
Failure assumptions
- The client address changes mid-session.
- A middlebox drops UDP/443.
- An attacker replays a captured 0-RTT flight.
Constraints
- Do not require HTTP/3 for correctness.
- Do not send the charge in early data.
Prompt
A mobile client walks from Wi-Fi to cellular in the middle of a session. Some networks block UDP. One endpoint charges a card.
API
Which methods are allowed in 0-RTT?
Data
What identifies a connection after the 4-tuple changes?
Architecture
Which hop terminates QUIC, and what protocol do inner services speak?
Same streams, different loss domain
Prefer
HTTP/3 when the last mile loses packets
QUIC recovers the stream that lost data. Other streams keep going. A phone can change networks without tearing the session down.
- First contact is typically one QUIC round trip, because crypto and transport share the handshake.
- A later visit can send idempotent reads in 0-RTT.
- The price is UDP reachability and replay-safe request design.
Alternative
HTTP/2 only, or HTTP/3 with no fallback
HTTP/2 is the right inner protocol and the right fallback. It is a weak bet as the only mobile transport. HTTP/3 with no TCP path fails where UDP is filtered.
- One TCP loss stalls every HTTP/2 stream.
- A new client IP kills a TCP connection.
- A UDP-only launch fails closed on some corporate networks.
Offer HTTP/3 without depending on it
Discovery, a safe early flight, and a TCP fallback. Handshake bytes are the next lesson.
- 1
Serve HTTP/2 well
The fallback has to be correct on its own. A broken HTTP/2 origin plus a flaky UDP path is two outages. - 2
Advertise HTTP/3
Alt-Svc or an HTTPS DNS record tells the client that QUIC exists. The first connection is often still TCP. - 3
Migrate with a connection id
The 4-tuple can change. PATH_CHALLENGE proves the new path before you send a large response there. - 4
Gate 0-RTT on idempotence
Early data can be replayed. GET can be designed for that. A charge cannot.
Overview
HTTP/2 multiplexes streams and still couples them to one ordered TCP byte stream. On a lossy mobile link a single lost packet stalls all of those streams. QUIC was built to break that coupling, to encrypt the transport so middleboxes cannot ossify it, and to name a connection by an id instead of by IP and port.
HTTP/3 is the mapping of HTTP onto those QUIC streams. It is not a new set of methods. Semantics stay in RFC 9110. The mapping is RFC 9114. The transport is RFC 9000.
The stack
Decisions
- 1
HTTP/3 request
- nextQUIC streams
- 2
QUIC streams
- nextQPACK headers
- 3
QPACK headers
- nextTLS 1.3 keys
- 4
TLS 1.3 keys
- nextUDP datagrams
- 5
UDP datagrams
- nextPacket lost?
- ?
Packet lost?
- YesOne stream recovers
- NoSiblings keep flowing
- 7
One stream recovers
- 8
Siblings keep flowing
Lesson map
HTTP/3 & QUIC — UDP, Migration, 0-RTT & HOL Fixes
HTTP/3 runs on QUIC over UDP, with TLS 1.3 inside the transport. Loss stays on one stream, a connection can survive an IP change, and 0-RTT early data can be replayed.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["HTTP/3 request"] b["QUIC streams"] c["QPACK headers"] d["TLS 1.3 keys"] a -->|HTTP/3 request to QUIC streams| b b -->|QUIC streams to QPACK headers| c c -->|QPACK headers to TLS 1.3 keys| d
- Reliable streams sit in QUIC, not in TCP.
- Almost every QUIC packet is encrypted. Middleboxes cannot rewrite sequence numbers the way they rewrote TCP.
- The cryptographic handshake and the transport handshake are one exchange. A first visit is typically one RTT. TLS 1.2-style two-round-trip setups do not apply.
- Connection ids let the client move from Wi-Fi to cellular without a new HTTP connection, as long as the server accepts the new path.
| Scenario | HTTP/2 on TCP | HTTP/3 on QUIC |
|---|---|---|
| Packet lost on stream A | Every stream waits for TCP | Stream A recovers; others continue |
| Client IP changes | Connection dies | Migrate if path validation succeeds |
| First visit | TCP handshake plus TLS | Usually one QUIC round trip |
| Repeat visit | TLS resumption | 0-RTT possible, with replay risk |
Connection migration
The peers can keep a logical connection when the client's address changes. That is the phone case. Servers must not trust the new path blindly. QUIC sends a PATH_CHALLENGE and waits for a PATH_RESPONSE so an off-path attacker cannot point a large response at a victim. That check also limits amplification.
Pros: the session survives a network change.
Cons: the thing in front of the server must route on connection ids, not only on the 4-tuple. CDNs and QUIC-aware edge proxies do this. A TCP-only load balancer will black-hole the migrated flow. How anycast and edge termination are operated is TLS at the anycast edge. This page only requires that the hop which owns the QUIC connection can see the connection id.
0-RTT
If the client still holds a session ticket, it may send application data in the first flight, before the handshake finishes.
Decisions
- 1
Have a session ticket?
- NoFull 1-RTT handshake
- YesRequest idempotent?
- 2
Full 1-RTT handshake
- nextThen send the request
- ?
Request idempotent?
- Yes0-RTT early data
- NoWait for 1-RTT keys
- 4
0-RTT early data
- nextReplay is still possible
- 5
Wait for 1-RTT keys
- nextThen send the request
- 6
Replay is still possible
- 7
Then send the request
Safe enough to discuss: idempotent reads, with a server that can reject early data and force a retry at 1-RTT.
Unsafe: a POST or RPC that charges money, creates a row, or otherwise changes state, unless you have a real anti-replay design. "We use HTTPS" is not that design. Captured early data replays.
The same early-data idea exists in TLS 1.3 without QUIC. The TLS lesson owns the handshake rounds. Here the point is the HTTP method you are willing to put in that first flight.
Discovery and fallback
Browsers learn that HTTP/3 exists from an Alt-Svc response header (RFC 7838) or from an HTTPS DNS record. They often finish the current navigation on HTTP/2, then race QUIC for the next one. If UDP is blocked they stay on HTTP/2.
That fallback is a design requirement. Hotel networks, some enterprise firewalls, and some middleboxes drop or rate-limit UDP/443. Packet inspectors that only understand TCP TLS will not see a QUIC session. A common split is HTTP/3 at the CDN and HTTP/2 on the inner hop. Inner topology belongs to private networking. Do not redraw the VPC to answer a QUIC question.
QPACK in one sentence
HPACK's dynamic table assumes header blocks are applied in order on one connection. QUIC streams are not delivered in one total order. QPACK (RFC 9204) splits that table so a stream can make progress without waiting for another stream's header block. If the interviewer wants more, cite the RFC. Do not rebuild the encoder.
What you operate
- Expect some networks to fail UDP. Alert on the HTTP version mix, not only on status codes.
- Export QUIC loss and RTT from the edge. The application often sees only that the request was HTTP/3.
- Load-test with induced loss before you claim the mobile tail moved. One percent loss is enough to separate HTTP/2 from HTTP/3.
- Connection-id routing is a property of the edge, not of the application thread pool.
- Debugging is worse than text HTTP/1.1. That is a reason to keep curl-friendly HTTP/2, not a reason to skip QUIC where loss dominates.
Pros: tail latency under loss, migration, TLS 1.3 by construction.
Cons: UDP uncertainty, sharper tooling requirements, ACK and crypto CPU, and a load-balancer support matrix.
Sandbox: the decision, not a UDP socket
Press Run. Snippets must be self-contained — no network, files, or native modules.
Press Run. Snippets must be self-contained — no network, files, or native modules.
On a machine with a new enough curl, curl --http3 -I https://cloudflare.com shows the UDP path. The sandbox does not open one.
A client sends a POST in 0-RTT that creates an order. An on-path attacker replays the same UDP datagrams. What does a correct server do, and which method would you have allowed in that first flight instead?
Interview Q&A
Does HTTP/3 use TCP?
Answer
No. QUIC runs over UDP. Reliability, congestion control, and streams are QUIC features. TLS 1.3 is how the packets are keyed, not a separate TCP-style record layer you configure on the side.
How does HTTP/3 fix head-of-line blocking?
Answer
HTTP/2 already let streams interleave, then TCP ordered delivery froze them together on loss. QUIC recovers the lost data for the affected streams. A stream whose packets arrived can still be read.
What is connection migration?
Answer
The connection is identified by connection ids. When the client address changes, packets with that id still belong to the session. The server validates the new path with PATH_CHALLENGE before trusting it with a large response.
Why is 0-RTT dangerous for POST?
Answer
The early data is encrypted with resumed keys and can be replayed by someone who captured the first flight. The server cannot tell the replay from the original until the handshake finishes, and by then a naive handler may have committed the write.
What if UDP is blocked?
Answer
Clients that followed Alt-Svc or an HTTPS record fall back to HTTP/2. Your origin has to keep that path healthy. Correctness must not depend on UDP.
Is QUIC just TLS over UDP?
Answer
No. TLS 1.3 provides the handshake and the packet keys. QUIC provides streams, loss recovery, congestion control, connection ids, and migration. Saying "TLS over UDP" skips the reason HTTP/3 exists.
Where should an enterprise terminate HTTP/3?
Answer
Usually at a CDN or edge that can route on connection ids and speak UDP. Inner hops often stay on HTTP/2, with or without mTLS, depending on the trust boundary. Anycast operations and VPC layout are already documented on the edge and private-networking pages.