That the web seems faster is not only thanks to fiber optics. Much of the credit belongs to a protocol born a decade ago with an idea that was uncomfortable for the standards of the time: ditching the most reliable protocol on the Internet, TCP, and sending data down a path considered until then too casual. Its name is QUIC, and on top of it runs HTTP/3, the current version of the language the browser uses to request pages.
For twenty years, web traffic traveled over TCP (the Transmission Control Protocol, which guarantees packets arrive complete and in order) and the web was built on top of it with HTTP/1.1. It worked, but with a hidden cost: each request needed its own connection, and each connection had to “shake hands” before it could send data. Opening a resource-heavy page meant opening dozens of parallel connections to dodge the limit. It was effective, but wasteful.
HTTP/2 fixed that… and hit a wall
HTTP/2, standardized in 2015, squeezed all those requests into one TCP connection and multiplexed them: several streams travel at once over the same wire. The problem is that TCP treats everything on that connection as a single conveyor belt that delivers packets in order. If packet number 3 is lost, the receiver waits for it and holds back packets 4, 5 and 6 even though they arrived. That is head-of-line blocking: one stuck request blocks every one behind it on that connection.
This jam is especially painful on an unstable network: on a 4G link with packet loss, a single slow request ruined the perceived speed of the whole page. The obvious fix was to rebuild the transport from scratch, and that is where QUIC comes in.
QUIC: throw away the conveyor belt and use independent packets
QUIC (for Quick UDP Internet Connections, conceived by Jim Roskind at Google in 2012, today an IETF standard in RFC 9000) runs on UDP, a much simpler protocol that promises neither order nor delivery. Why weaken the foundation? Because by controlling reliability inside QUIC rather than in TCP, each stream (each independent data flow) is managed separately: if a packet in one stream is lost, that stream is resent while the others keep flowing without pause. Head-of-line blocking at the connection level disappears.
Under the hood, QUIC reproduces everything good that TCP provided — congestion control, retransmissions, packet numbering — but it programs those mechanisms in the application’s user space, not in the operating system kernel. That lets improvements roll out without waiting years for every OS to update its TCP stack. It is a modern transport by design.
A handshake that doesn’t wait: 0-RTT
Opening a classic connection cost three round-trips: TCP’s SYN packet, then the TLS key negotiation. QUIC embeds cryptography directly into the protocol and completes the whole agreement in a single round-trip; if the client connected before, not even that: it sends data in the first message (a 0-RTT connection). It’s the equivalent of walking back into an office that already knows you: you start working, the identification arrives afterward.
There is also a detail almost nobody notices: QUIC identifies each connection by a Connection ID chosen by the server, not by the IP-port pair the way TCP does. That small decision enables mobility: if your phone jumps from WiFi to cellular, the connection is not dropped — it simply changes the path toward the same ID. Doing that with TCP meant reconnecting from scratch.
The details you notice when you inspect the traffic
If you open your browser’s network tools and see h3 or quic in the protocol column, you are watching HTTP/3 in action. The h3 is the ALPN identifier (Application-Layer Protocol Negotiation) that the client presents to the server during the handshake to propose that protocol. Header compression changed too: HTTP/2 used HPACK and centralized the compression index over the whole connection (another source of blocking); HTTP/3 uses QPACK, which distributes the compression state so that a lost header does not stall the others.
Even the encryption is more ambitious. In HTTP/2, content was encrypted but headers remained visible to intermediaries; in HTTP/3 the transport itself and practically the whole packet header are encrypted, so an observer can only see where data is going, not which internal protocol it carries. All over TLS 1.3, whose negotiation is embedded inside QUIC itself (RFC 9001).
From Google’s oddity to the majority of traffic
QUIC started as an internal experiment and was deployed across Google’s services in 2013; the IETF standardized it in 2021. Today every major browser speaks it, and servers such as Caddy, LiteSpeed, Envoy or nginx serve it out of the box. According to measurements from Cloudflare and from the standardization body itself, a substantial share of web requests already travels over HTTP/3, and on lossy mobile networks the perceived speed gain is noticeable.
The technical lesson is elegant: when the bottleneck lives inside the protocol itself, sometimes no shortcut will do. The only way out is to build another path. QUIC did not make TCP faster; it stopped using it for the traffic that could move faster elsewhere. And that, in network engineering, is an architecture decision with a capital A.
