Articles
HTTP/2 vs HTTP/3 Interview Questions: Stream Blocking, QUIC, and Connection Migration
Compare HTTP/2 and HTTP/3 through a packet-loss timeline, QUIC stream independence, connection migration, UDP fallback, and 0-RTT replay.
“If HTTP/2 already multiplexes requests, why does HTTP/3 matter?” The best interview answer identifies which layer can still block. HTTP/2 gives multiple logical request streams over one TCP connection, but TCP exposes one ordered byte stream. A lost TCP segment can delay later bytes needed by unrelated HTTP/2 streams. HTTP/3 carries HTTP semantics over QUIC, whose reliable streams are independent; loss on one stream need not stop delivery on another. Neither protocol removes loss, congestion, or a slow application.
This guide uses an original packet-loss timeline, a migration trace, and a fallback decision. Evidence boundary: RFC 9113, RFC 9114, RFC 9000, and RFC 8470 support protocol behavior. The timeline, troubleshooting choices, and examples are editorial inferences, not measurements from a real connection or candidate reports.
Two different meanings of head-of-line blocking
HTTP/1.1 often motivated multiple connections because a single ordered response sequence could delay later requests. HTTP/2's stream frames multiplex requests and responses on a connection, so the application protocol can interleave work. That resolves a request-serialization problem at the HTTP layer. However, HTTP/2 normally rides one TCP connection. TCP delivers bytes in order: if a segment is missing, later bytes in that connection cannot be handed up as a continuous ordered sequence, even if they contain data for a different HTTP/2 stream.
HTTP/3 uses QUIC transport over UDP. RFC 9114 says QUIC provides reliable, in-order delivery per stream and that streams are independent, so a blocked or lost stream does not prevent progress on other streams. This is a transport-level distinction, not “HTTP/3 is unordered.” Each individual stream still has ordered bytes. A missing part of stream A delays later bytes of A; stream B can advance if its own bytes arrived. The interviewer may ask you to correct either of two oversimplifications: HTTP/2 has no blocking at all, or HTTP/3 never blocks.
QUIC still has connection-level congestion control and flow-control limits. Loss can reduce the sending rate for the connection, and CPU, server work, or an intermediary can delay all responses. The independent-stream property removes a particular cross-stream delivery dependency; it does not guarantee faster page load under every workload. State the workload and network condition before promising a latency win.
Worked timeline: three response streams and one missing packet
Imagine a page fetching HTML stream A, CSS stream B, and a small icon stream C over one connection. Assume the server has encoded bytes for all three, and one network packet carrying a piece of A is lost. This is a conceptual trace, not a packet capture; real framing and coalescing vary.
| Time | HTTP/2 over TCP | HTTP/3 over QUIC |
|---|---|---|
t0 | A, B, C bytes are multiplexed into one TCP byte sequence. | A, B, C have separate QUIC stream offsets. |
t1 | A segment containing an early A byte is lost; later TCP bytes for B/C arrive. | A packet carrying an A range is lost; B/C ranges arrive. |
t2 | TCP waits for the missing segment before delivering later ordered bytes to HTTP/2. | B/C stream bytes can be delivered while A awaits recovery. |
t3 | Retransmission fills the gap and all later bytes become deliverable. | A's missing range is recovered; A resumes in order. |
The useful observation is where the dependency appears. In HTTP/2, B and C may be blocked from application delivery by an earlier hole in TCP's one byte stream. In HTTP/3, B and C can progress if the lost packet carried only A data and their own stream data is complete. If the lost QUIC packet also carried frames from B, B can be affected too; one UDP datagram can contain more than one stream frame. This caveat keeps the example accurate rather than magical.
For a live diagnosis, capture connection protocol, RTT, loss/retransmission signals, per-resource timing, and server processing time. A waterfall showing one slow CSS response does not by itself prove TCP head-of-line blocking. If the server produced CSS late, changing transports will not make it early. If many unrelated resources stall together after a loss event on one HTTP/2 connection but not under a comparable HTTP/3 path, transport blocking becomes a plausible explanation. That is a hypothesis to test, not a claim derived from the waterfall alone.
Why QUIC changes connection setup
QUIC integrates transport and cryptographic handshakes. HTTP/3 relies on QUIC's security and peer authentication rather than layering TLS over TCP in the HTTP/2 fashion. A candidate should be able to identify the transport stack and explain that connection establishment can differ in round trips. Do not recite one universal handshake-time number without saying whether the client has a prior session, whether early data is allowed, what the RTT is, and whether a proxy or network blocks UDP.
The common 0-RTT follow-up is about replay, not merely speed. HTTP early-data guidance in RFC 8470 treats early requests as potentially replayable. A read-only fetch may be suitable under a server's policy; an unsafe state-changing operation must not be blindly accepted as early data. The server can reject unsafe early requests, including with 425 Too Early in the documented flow. An idempotency key or business-level duplicate guard may be important for a retrying API, but it is not a substitute for understanding replay risk at the protocol boundary.
If an interviewer says “HTTP/3 is always available because browsers support it,” ask how the client discovers and reaches it, and what happens when UDP is blocked. RFC 9114 says connectivity problems such as UDP blocking can prevent a QUIC connection and clients should attempt TCP-based HTTP versions. A robust service supports fallback and measures which protocol users actually negotiated. A server enabling HTTP/3 does not mean every request used it.
Migration: same connection, new path, conditions apply
Suppose a phone starts a request on Wi-Fi and switches to cellular. A TCP connection is tied to its endpoint address/port tuple and generally needs a new connection when that path changes. QUIC's connection IDs can let a connection survive a change of local address or port. RFC 9000 describes path validation and connection-ID handling for migration. The client can probe a new path; after validation, traffic can move without treating the new address as an entirely new logical connection.
That does not mean “HTTP/3 seamlessly survives any network change.” RFC 9000 says an endpoint must not initiate migration before the handshake is confirmed. A peer can disable active migration under specified conditions. The new path may fail validation or be unusable. Server infrastructure needs to route the connection ID to the right state, and NAT rebinding can look like a path change. If validation fails but an old path remains usable, the endpoint can continue on the old path; if neither works, the request may still fail. Treat migration as a capability with preconditions, not a guarantee.
The exercise's migration trace is: at t0, handshake completes on Wi-Fi; at t1, the client gets a cellular address; at t2, it sends probing traffic with an available connection ID; at t3, peer reachability is validated; at t4, non-probing traffic uses the new path. At each step, ask what log or packet signal would distinguish a failed migration from a server timeout. If failure happens before handshake confirmation, a migration explanation is premature. If path validation never succeeds, look at firewall, NAT, routing, and connection-ID availability.
Connection migration also has privacy and security constraints. Connection IDs should not make a user unnecessarily trackable across paths, and path validation limits amplification to an unverified address. The detailed protocol rules live in RFC 9000. In an interview, it is enough to say “the connection ID separates logical identity from the current IP/port, but changing paths requires validation and can fail.” That is more precise than equating QUIC to “UDP has no connection.”
Diagnose a complaint without choosing a winner first
Consider a mobile app whose API latency got worse after HTTP/3 rollout. Split the population by negotiated protocol and network, rather than comparing all before/after requests. Ask whether the app fell back to HTTP/2 on blocked UDP, whether connection establishment is repeated, whether migration actually occurred, and whether packet loss or server processing changed. A protocol rollout may alter load balancer routing or edge configuration too; correlation with HTTP/3 is not proof that QUIC is the root cause.
Build a small matrix: stable Wi-Fi, lossy Wi-Fi, and Wi-Fi-to-cellular handoff; repeat with HTTP/2 and HTTP/3 where the client can force them safely. Measure connection setup, time to first byte, full response, failure rate, and actual protocol. Keep server region, cache state, request mix, and authentication comparable. For large downloads, throughput and congestion behavior may matter more than a tiny-resource waterfall. For a page with many independent resources under loss, cross-stream blocking may be more visible.
When measuring, distinguish head-of-line symptoms from flow control and QPACK dependencies. HTTP/3 uses QPACK for header compression because HPACK's ordering assumptions do not fit independent QUIC streams; QPACK can still have blocked header decoding in certain circumstances. The broad statement that HTTP/3 eliminates transport cross-stream head-of-line blocking is accurate; claiming that no higher-layer dependency or application stall exists is not.
Fast interview answers to likely follow-ups
Does HTTP/2 multiplex? Yes. It interleaves HTTP streams, but a single TCP byte stream can still hold back all of them after a missing segment.
Does HTTP/3 guarantee lower latency? No. QUIC removes a specific transport delivery bottleneck and offers connection-setup/migration capabilities, but loss, congestion, CPU, proxies, and workload determine measured outcomes.
Is QUIC unreliable because it uses UDP? No. QUIC implements reliable, ordered delivery per stream above UDP. UDP is its packet substrate, not the application's reliability contract.
What happens if UDP is blocked? QUIC establishment can fail; the client should try a TCP-based HTTP version according to RFC 9114. Verify actual negotiation rather than assuming the advertised capability was used.
Can a POST use 0-RTT safely? Do not assume so. Early data can be replayed; check the server's policy and the operation's semantics, and follow the HTTP early-data guidance.
Does migration preserve every request? A connection ID and validated path can preserve a logical QUIC connection after an address change, but handshake state, peer policy, path validation, and network reachability can prevent it.