How HTTP/3 and QUIC work

The Problem Statement

Interviewer: "Your mobile app makes dozens of API calls on every screen load. Users on cellular connections report sluggish performance, and your metrics show that HTTP/2 is actually performing worse than HTTP/1.1 under 2% packet loss. What is going on, and how does HTTP/3 fix it?"

This question tests three things: whether you understand TCP-layer head-of-line (HOL) blocking that HTTP/2 cannot solve, whether you can explain how QUIC's independent stream multiplexing eliminates it, and whether you know the practical deployment tradeoffs (0-RTT security, UDP firewalls, middlebox ossification).

Candidates often get stuck on this one because they think HTTP/2 "solved" HOL blocking. It did not. HTTP/2 solved application-layer HOL blocking but introduced a worse version at the transport layer. The interviewer wants to hear you articulate why TCP itself is the bottleneck, and why building a new transport protocol on UDP was the only way forward.

HTTP/3 was standardized as RFC 9114 in June 2022, building on top of QUIC (RFC 9000). It represents the most significant change to web transport in decades. Unlike the HTTP/1.1 to HTTP/2 transition (which kept TCP and only changed the application framing), HTTP/3 replaces the entire transport layer. That is a much bigger architectural shift, and the interviewer is testing whether you grasp why it was necessary.

Clarifying the Scenario

You: "Before I dive in, let me clarify a couple things."

You: "When you say HTTP/2 performs worse under packet loss, I assume we are seeing TCP-layer head-of-line blocking. HTTP/2 multiplexes all streams over a single TCP connection, so a single lost packet stalls every stream until retransmission completes. With HTTP/1.1's six parallel connections, only one connection stalls per lost packet."

Interviewer: "Exactly. That is the root cause."

You: "Got it. Should I focus on the QUIC protocol mechanics, or also cover deployment challenges like UDP firewalls and CPU overhead?"

Interviewer: "Both. Start with the protocol, then cover what makes deployment hard in practice."

You: "OK, I will structure my answer in four parts: why TCP creates the HOL blocking problem that HTTP/2 cannot escape, how QUIC solves it with independent streams over UDP, how the integrated TLS 1.3 handshake enables 0-RTT resumption, and finally the deployment challenges including connection migration and middlebox ossification."

My Approach

I break this into five parts:

1. TCP's HOL blocking problem: Why multiplexing over a single TCP connection makes packet loss catastrophic for all streams simultaneously.
2. QUIC as a UDP-based transport: How QUIC implements reliability, flow control, and congestion control per-stream instead of per-connection.
3. Integrated TLS 1.3 and 0-RTT: How combining the transport and crypto handshakes reduces connection setup from 2-3 RTTs to 1 RTT (or 0 RTT for returning connections).
4. Connection migration via Connection IDs: Why connections survive IP address changes, and how this transforms the mobile experience.
5. Deployment challenges: UDP firewalls, middlebox ossification, encryption of everything, and CPU cost.

The core insight is that HTTP/3 is not just "HTTP/2 but faster." It is a fundamentally different transport architecture. TCP has been the universal transport protocol for 40+ years, and its design assumptions (single ordered byte stream, kernel-space implementation, IP:port tuples as connection identifiers) are the exact things QUIC replaces. Understanding why those assumptions break on modern mobile networks is the key to this question.

Here is a comparison of the three HTTP versions to frame the discussion:

The Architecture

Here is the full picture of the HTTP/3 and QUIC protocol stack compared to the traditional HTTP/2 over TCP approach. The key difference is that QUIC merges the transport and TLS layers into a single protocol running over UDP.

The critical architectural difference is where reliability lives. In the TCP world, the kernel manages one ordered byte stream. If byte 5000 is lost, bytes 5001-10000 cannot be delivered to the application even if they arrived fine, because TCP guarantees in-order delivery of the entire stream.

In QUIC, each stream has its own independent sequence space. Stream 1 can deliver data while stream 3 waits for a retransmission. The application sees no cross-stream interference. This is the entire reason HTTP/3 exists.

Let me walk through what happens when a client connects to a server using HTTP/3:

1. The client sends a UDP datagram containing a QUIC Initial packet with a ClientHello (TLS 1.3) and proposed transport parameters.
2. The server responds with its own Initial packet containing ServerHello, certificate, and finished message, all in one RTT.
3. The client can now open streams immediately. Each stream gets independent flow control and loss recovery.
4. If the client has connected to this server before, it can send application data in the very first packet (0-RTT), reducing latency to zero round-trips for connection setup.

For your interview: the one sentence that demonstrates you understand HTTP/3 is "QUIC provides per-stream reliability over UDP, so a lost packet for one stream does not block delivery of other streams."

Independent Stream Multiplexing and Loss Recovery

This is the heart of why HTTP/3 exists. Let me show you exactly what goes wrong with TCP and how QUIC fixes it.

The difference is dramatic under real conditions. With 2% packet loss on a connection carrying 10 concurrent HTTP/2 streams, a single lost TCP segment stalls all 10 streams for one RTT (50-300ms on cellular). Over the course of a page load with 80 resources, you hit this scenario multiple times, adding hundreds of milliseconds of delay.

QUIC's per-stream loss recovery means that same 2% loss only affects 1 out of 10 streams at a time. The other 9 continue delivering data uninterrupted. Google's measurements show a 3-8% improvement in mean page load time and a 15-20% improvement at the tail (P95/P99) when switching from HTTP/2 to HTTP/3 on mobile networks.

The improvement at the tail matters more than the improvement at the mean. A 3% mean improvement sounds modest, but a 15-20% improvement at P99 means the slowest page loads get dramatically faster. These are exactly the users on congested cellular networks who are most likely to abandon the page. This is why Google, Cloudflare, and Meta invested years of engineering effort into QUIC: the tail latency improvement on mobile networks is substantial.

I always mention specific numbers in interviews. "3-8% mean improvement, 15-20% tail improvement under 2% loss" is the kind of concrete detail that separates informed candidates from those reciting Wikipedia.