The story of a thirty-year wait
When you hit Enter, your request does not travel as a loose envelope across the internet. Before moving a single byte of useful data, your browser and the server have to negotiate a reliable transport channel, and that negotiation takes time. That waiting has been the original sin of the web since the 1990s, and solving it is exactly what HTTP/3 and the QUIC protocol (RFC 9000) have done: the first big transport-level revolution on the web in decades.
For all of its life, HTTP has relied on TCP, the transport protocol that guarantees packets arrive in order and without loss. TCP is robust, but expensive: opening a connection requires a three-way handshake (SYN, SYN-ACK, ACK) that costs one round trip (RTT, the time a packet takes to go to the server and come back). On top of that you need encryption, and the TLS 1.3 handshake adds almost another full round trip. If you also arrive at a cold network or a cacheless server, the first page can take several round trips before a single pixel is drawn.
HTTP/2 fixed one queue and created another
HTTP/2, introduced in 2015, attacked the problem of the many parallel connections that HTTP/1.1 opened for each resource. Instead it opened a single TCP connection and multiplexed it: several requests and responses travel through the same pipe, each in its own independent stream, each identified by a number.
The catch is that TCP delivers bytes in order. All streams share a single transmission queue at the transport layer, and if a single packet is lost, the entire connection stalls waiting for its retransmission. That is head-of-line blocking: one heavy image or one lost packet can freeze the text that already arrived below. At the application level HTTP/2 has no queues; at the transport level it has all of them.
QUIC: inventing a new transport over UDP
In 2012 Google started experimenting with its own transport that did not have that flaw. The result, standardized in 2021 as RFC 9000, is called QUIC and runs over UDP instead of TCP. UDP is a minimalist protocol that guarantees neither order nor delivery: no handshake, no retransmission, it just throws datagrams. Its lack of services is precisely what lets QUIC build them to order.
QUIC implements for itself what TCP used to do: loss detection, retransmission, congestion control (the CUBIC or BBR algorithms) and reliable delivery. But it does this per stream, not per connection. Each QUIC stream has its own packet number and its own control space, so a lost packet only affects its own stream; the others keep flowing. Head-of-line blocking disappears at the transport level.
A handshake in a single trip
QUIC did not just carry the transport: it built encryption into the protocol itself. The QUIC handshake combines the transport negotiation with TLS 1.3 in a single exchange. For a new visitor, the full connection —transport plus encryption— is established in one round trip (1-RTT), instead of the two or three of TCP+TLS.
For returning visitors there is also 0-RTT: if the client keeps valid session credentials, it can send application data in the very first packet that opens the connection. Zero round trips of waiting. The blog or feed loads almost instantly. The technical caveat is that 0-RTT should only be used for requests that tolerate being repeated (an idempotent GET is ideal), because the server may receive the data twice if the packet is replayed.
Another consequence of full encryption: unlike TCP, where the sequence number is visible to intermediate routers, in QUIC everything is encrypted, including the control area. A network observer sees that there is QUIC traffic, but not which streams it carries or how they are reordered.
Connections that survive a network switch
One of the most elegant consequences is connection migration. In TCP the connection is identified by the pair of IP address and port; switching from Wi-Fi to mobile data breaks the session and it must be renegotiated. QUIC identifies the connection by a connection ID that the client can change freely without losing state. Going down the metro, crossing from one network to another, and not having to reload: that is the basis of why modern apps and websites keep the session alive when your IP changes.
HTTP/3 and compression without order
HTTP/3 is simply HTTP running over QUIC instead of over TCP. It also changes a fine detail: header compression. HTTP/2 used HPACK, which requires packets to be received in strict order to keep its dynamic table of repeated headers synchronized. Because QUIC delivers out-of-order streams by design, HTTP/3 brings QPACK, a compression scheme that lets encoder and decoder keep the table synchronized even when packets arrive out of order. HTTP/3 also uses its own (stream id, stream type) tuples: one for the control stream, one for the push stream, and one for each data stream.
A new transport in production
QUIC is not laboratory theory. Today it is supported by Chrome, Edge, Firefox and Safari, and the big content delivery networks (CDNs) such as Cloudflare, Akamai or Google already serve a growing share —in many cases more than a third— of their traffic over HTTP/3 (identifiable by the h3 prefix in the protocol the server advertises). Servers enable it with minimal configuration over a UDP 443 socket next to the TCP one.
Switching transport protocols is not decided overnight: it is the kind of infrastructure that stays installed for decades. The fact that QUIC solved at the same time latency, head-of-line blocking and connection rewiring is what has finally convinced the industry. A web that stops waiting was not achieved with one more cache optimization, but by rewriting from the base the transport on which everything else depends.
