HTTP/3 and QUIC

For thirty years, HTTP traffic traveled over TCP, the protocol that guarantees bytes arrive complete and in order. QUIC replaces TCP for the web. Started at Google around 2012 and standardized by the IETF in 2021 (RFC 9000), it runs on top of UDP and rebuilds reliability, ordering and congestion control itself, in software that browsers and servers can update quickly. HTTP/3 (RFC 9114, 2022) is simply HTTP carried over QUIC.

The first win is head-of-line blocking. HTTP/2 already sent many files at once over a single TCP connection, but TCP sees only one stream of bytes: if one packet is lost, everything behind it waits, even data for unrelated images. QUIC knows about the separate streams, so a lost packet only stalls the one it belongs to. On lossy mobile and Wi-Fi networks that makes a visible difference.

The second is setup time. TCP plus TLS needs a couple of round trips before the first useful byte; QUIC builds encryption (TLS 1.3) into its own handshake, so a new connection usually takes one round trip, and a returning client can sometimes send data immediately (0-RTT, with some replay-attack caveats). Almost everything in QUIC is encrypted, including much of the header that middleboxes used to inspect.

Third, a QUIC connection is identified by a connection ID, not by IP address and port, so it survives your phone hopping from Wi-Fi to 5G. Today Chrome, Firefox and Safari speak HTTP/3, and Google, Meta and Cloudflare serve a large share of traffic with it. Browsers learn a site supports it through an Alt-Svc header or a DNS record, and fall back to HTTP/2 over TCP when UDP is blocked by a firewall.