HTTP/3 (QUIC)

What is HTTP/3 and QUIC?

HTTP/3 is the third major version of the HTTP protocol, and its defining change is the transport it runs on: instead of TCP, HTTP/3 runs over QUIC, a newer transport protocol built on top of UDP. QUIC (originally developed by Google, now an IETF standard) reimplements the reliability, ordering, and congestion control that TCP provided — but does it in user space over UDP, with TLS 1.3 encryption built directly in, and fixes long-standing performance problems that were baked into the TCP-based design of earlier HTTP versions. It’s already widely deployed — major browsers, Cloudflare, Google, and large sites support it — so it’s not experimental, it’s the current cutting edge of web transport.

The problem it solves: head-of-line blocking

To understand why HTTP/3 exists, you need the history. HTTP/1.1 could only handle one request at a time per connection (or clumsy pipelining), so browsers opened many parallel connections. HTTP/2 introduced multiplexing — many requests/responses interleaved over a single connection — a big improvement, but it had a subtle flaw: because it ran over TCP, and TCP guarantees in-order delivery of its single byte stream, a single lost packet stalled all the multiplexed streams on that connection until the lost packet was retransmitted. This is TCP head-of-line blocking: one dropped packet holds up everything behind it, even requests that were otherwise complete. It’s especially painful on lossy networks (mobile, congested Wi-Fi) where packet loss is common. QUIC solves this by implementing independent streams within the transport itself — each stream is delivered independently, so a lost packet affecting one stream doesn’t block the others. That’s the headline win: true multiplexing without the cross-stream stalling that TCP imposed on HTTP/2.

QUIC’s other advantages — and the practical realities

Beyond eliminating head-of-line blocking, QUIC brings several improvements that matter especially for mobile and high-latency scenarios. Faster connection setup: QUIC combines the transport and TLS handshakes, establishing a secure connection in fewer round trips than TCP+TLS (and supporting 0-RTT resumption for returning clients), which noticeably speeds up initial page loads. Connection migration: because QUIC identifies connections by an ID rather than the IP-address/port four-tuple TCP uses, a connection can survive a network change — when your phone switches from Wi-Fi to cellular, the QUIC connection persists instead of breaking and reconnecting, a real benefit for mobile users. Encryption by default: TLS 1.3 is integral, not optional. The practical realities to weigh: HTTP/3 runs over UDP, and some corporate firewalls, middleboxes, and networks historically throttle, mishandle, or block UDP (having been tuned for TCP), so clients need to fall back to HTTP/2/TCP when QUIC is blocked — robust deployments support both. QUIC’s user-space implementation and per-packet encryption can also carry higher CPU cost than mature, hardware-offloaded TCP at very high scale, something large operators tune for. And the benefits are most pronounced on lossy/high-latency networks — on a clean, fast wired connection the difference over HTTP/2 is smaller, so it’s an improvement rather than a revolution for every user. For engineers, enabling HTTP/3 is largely a matter of turning it on at your CDN/edge/load balancer (which handle the complexity), with graceful fallback ensuring nothing breaks for clients that can’t use it.

What people get wrong

• Assuming TCP fallback is unnecessary — UDP is blocked or throttled on some networks, so HTTP/3 deployments must fall back to HTTP/2 over TCP or those clients fail.
• Expecting huge gains everywhere: the biggest wins (no head-of-line blocking, connection migration) show up on lossy/mobile networks — on clean wired links the improvement over HTTP/2 is modest.
• Overlooking CPU cost at scale — QUIC’s user-space, per-packet-encrypted design can cost more CPU than hardware-offloaded TCP, which large operators must plan for.

Primary source: RFC 9114: HTTP/3