What Is HTTP/3 and How Does QUIC Change Things?
Learn how HTTP/3 and QUIC solve transport-layer head-of-line blocking, speed up handshakes, and survive network changes.
Expected Interview Answer
HTTP/3 runs over QUIC, a transport protocol built on UDP instead of TCP, which gives each multiplexed stream its own independent loss-recovery so packet loss on one stream no longer stalls the others — solving the transport-layer head-of-line blocking that HTTP/2 still suffered even after fixing it at the HTTP layer.
HTTP/2 multiplexes streams at the HTTP layer, but they all still ride on a single TCP connection, and TCP guarantees strictly ordered, in-sequence delivery of bytes; if one packet is lost, TCP holds back every later packet — including ones belonging to unrelated streams — until the missing packet is retransmitted and arrives. QUIC replaces TCP with a UDP-based transport that natively understands the concept of independent streams, so packet loss on one stream only stalls that stream, while the others keep flowing. QUIC also bakes in TLS 1.3 as part of the transport handshake itself, so a new connection typically completes the transport and encryption handshake in a single round trip (1-RTT), or even zero round trips for a resumed session (0-RTT), rather than needing separate sequential TCP and TLS handshakes. QUIC connections are also identified by a connection ID instead of the traditional IP/port tuple, which lets a connection survive a network change, like a phone switching from WiFi to cellular, without dropping and re-establishing.
- Independent per-stream loss recovery removes transport-layer head-of-line blocking
- Combined transport and TLS 1.3 handshake reduces connection setup to 1-RTT or 0-RTT
- Connection IDs let a session survive a network change without reconnecting
- Built-in encryption means QUIC traffic is always encrypted, unlike plain TCP
AI Mentor Explanation
TCP is like a single strict queue of overs where if one ball goes missing from the scoring feed, every later ball’s score is held back until that one is resent, even for a completely different match. QUIC is like tracking each match on its own independent scoring lane, so a lost ball in match three never delays the live score of match one. QUIC also lets a scorer’s device swap from stadium WiFi to mobile data mid-match without losing the live feed, because the feed is tied to the scorer’s ID, not the network path. That independent-lane, portable-identity design is exactly what QUIC brings over TCP.
Step-by-Step Explanation
Step 1
Client initiates QUIC over UDP
Instead of a TCP three-way handshake, the client sends UDP packets that combine transport setup with a TLS 1.3 handshake.
Step 2
Handshake completes in 1-RTT (or 0-RTT)
A new connection typically needs one round trip; a resumed session can send data immediately with 0-RTT.
Step 3
Streams are multiplexed with independent loss recovery
Each HTTP/3 stream is tracked separately inside QUIC, so lost packets only affect their own stream.
Step 4
Connection ID tracks the session, not the network path
If the client’s IP or network changes, the connection ID lets QUIC continue without a full reconnect.
What Interviewer Expects
- Clear distinction between HTTP-layer (solved by HTTP/2) and transport-layer (solved by QUIC) head-of-line blocking
- Understanding that QUIC runs over UDP, not TCP
- Mention of the combined transport+TLS 1.3 handshake and 0-RTT resumption
- Awareness of connection migration via connection IDs
Common Mistakes
- Confusing HTTP/3’s stream multiplexing with HTTP/2’s, without noting the transport difference
- Assuming UDP-based QUIC is unencrypted (it mandates TLS 1.3 by design)
- Not knowing 0-RTT has replay-attack tradeoffs for non-idempotent requests
- Thinking QUIC is a browser feature rather than an IETF-standardized transport protocol
Best Answer (HR Friendly)
“HTTP/3 uses a new transport called QUIC that runs over UDP instead of TCP. The big win is that if one small stream of data hits a hiccup, it does not hold up everything else the way it could before, and connections set up faster and can survive switching networks, like going from WiFi to mobile data, without dropping.”
Code Example
const entries = performance.getEntriesByType('resource')
for (const entry of entries) {
// 'h3' indicates HTTP/3 over QUIC was negotiated
if (entry.nextHopProtocol === 'h3') {
console.log('Served over HTTP/3:', entry.name)
}
}
// Server hint: advertise HTTP/3 support via Alt-Svc header
// Alt-Svc: h3=":443"; ma=86400Follow-up Questions
- Why can transport-layer head-of-line blocking still occur under HTTP/2 even though HTTP-layer blocking is fixed?
- What security risk does 0-RTT resumption introduce, and how is it mitigated?
- How does the Alt-Svc header help a browser discover HTTP/3 support?
- Why might some corporate networks or middleboxes block or throttle QUIC traffic?
MCQ Practice
1. What transport protocol does QUIC (and therefore HTTP/3) build on?
QUIC is implemented on top of UDP, allowing it to define its own independent, per-stream loss recovery.
2. What problem does QUIC solve that persisted even after HTTP/2?
HTTP/2 fixed HTTP-layer blocking, but all streams still shared one ordered TCP connection; QUIC gives each stream independent recovery.
3. What lets a QUIC connection survive a client switching from WiFi to cellular data?
QUIC tracks connections via a connection ID rather than the IP/port tuple, enabling seamless migration across networks.
Flash Cards
What does HTTP/3 run on? — QUIC, a transport protocol built on UDP instead of TCP.
What blocking issue does QUIC solve beyond HTTP/2? — Transport-layer head-of-line blocking from TCP’s strict ordered delivery.
How fast is a QUIC handshake? — Typically 1-RTT for a new connection, 0-RTT for a resumed session.
What enables QUIC connection migration? — A connection ID tracked independently of the client’s IP address or network path.