Building Reliability on Top of Speed
We established that UDP is fast but unreliable. So why is it the foundation for HTTP/3, the newest version of the protocol that powers the web?
The answer lies in a fundamental constraint: TCP is implemented inside every operating system kernel in the world. Changing TCP's behavior requires updating billions of devices — a process that takes years or decades. Meanwhile, the web's needs have evolved. Modern HTTPS requires both a TCP handshake and a TLS handshake before the first byte of application data can flow. On a high-latency connection, this can mean 2–3 round trips of delay just to start loading a page.
QUIC (Quick UDP Internet Connections)
Google's engineers realized they could not fix TCP, but they could build a new protocol at the application layer — one that runs on top of UDP (which is universally supported) and implements its own reliability, ordering, and security.
QUIC's key innovations over TCP+TLS:
| Feature | TCP + TLS 1.3 | QUIC |
|---|---|---|
| Handshake round trips | 1 (TCP) + 1 (TLS) = 2 RTT | 1 RTT (or 0-RTT for repeat connections) |
| Head-of-line blocking | Yes — one lost packet blocks all streams | No — each stream is independent |
| Connection migration | No — tied to IP:port tuple | Yes — connections survive IP changes (e.g., switching from Wi-Fi to cellular) |
| Encryption | Optional (TLS is separate) | Mandatory and built-in |
The elimination of head-of-line blocking is particularly significant. HTTP/2 over TCP multiplexes multiple requests over one connection, but a single lost TCP packet stalls all of those requests. QUIC's streams are independent — a lost packet for one stream does not affect others.
QUIC is the transport layer for HTTP/3, which is now supported by all major browsers and CDNs including Cloudflare, Google, and Fastly. You can check if a site uses HTTP/3 by looking for the alt-svc: h3 response header.