HTTP/3 and QUIC: What Changed and Why It Matters

HTTP/2 (2015) introduced multiplexing — many requests sharing a single TCP connection — to fix HTTP/1.1's problem of needing a separate connection (or a queue) per concurrent request. HTTP/3 keeps that multiplexing model but replaces TCP itself with QUIC, a new transport protocol built on UDP.

The problem HTTP/3 fixes: TCP head-of-line blocking

Under HTTP/2, if a single TCP packet is lost, every multiplexed stream on that connection stalls until the packet is retransmitted — TCP guarantees in-order delivery of the whole byte stream, so it has no way to let unaffected streams continue. This is "head-of-line blocking" at the transport layer, and it's especially costly on lossy networks like mobile connections.

How QUIC solves it

QUIC implements multiplexed streams as a native transport-layer concept: each stream has independent delivery ordering, so a lost packet only stalls the one stream it belonged to — every other stream on the same connection keeps flowing. QUIC runs over UDP rather than TCP specifically because UDP doesn't enforce a single ordered byte stream, giving QUIC the freedom to implement its own, smarter multi-stream delivery model.

Faster connection setup

QUIC also combines the transport handshake and the TLS 1.3 handshake into a single round trip (and supports 0-RTT resumption for repeat connections to a known server), versus TCP+TLS needing separate sequential handshakes. On a high-latency connection this alone can save a meaningful chunk of the time before the first byte of a page arrives.

Adoption

All major browsers and CDNs now support HTTP/3, and it's negotiated transparently — a browser that supports it will upgrade automatically when a server advertises support, falling back to HTTP/2 over TCP otherwise. Most sites don't need to change any application code to benefit; it's a server/CDN configuration change.