HTTP/3 and QUIC

For fifty years, TCP has powered the Internet with a simple promise: bytes arrive in order, or they don't arrive at all. This guarantee made TCP reliable. It also made TCP a bottleneck.

HTTP/3 abandons TCP entirely. Instead, it uses QUIC—a new transport protocol that solves problems TCP cannot solve because TCP's design prevents it.

The Problem TCP Cannot Fix

HTTP/2 introduced multiplexing: multiple requests sharing a single connection. Ten images loading simultaneously over one TCP connection instead of ten separate connections. Efficient.

But TCP sees only bytes. It doesn't know about images or requests or streams. It knows: byte 41 comes before byte 42 comes before byte 43. Always. No exceptions.

When packet 42 gets lost on the network, TCP waits. Packets 43 through 100 might arrive successfully, but TCP holds them hostage until packet 42 is retransmitted. The application cannot touch them.

This is head-of-line blocking. If packet 42 contains data for image 5, images 6 through 10 wait—even though their data arrived intact. TCP's greatest strength became its greatest weakness: the guarantee that bytes arrive in order became a promise that every stream must wait for every other stream's problems.

You cannot fix this in TCP. The ordering guarantee is TCP. Removing it would create a different protocol.

So they created a different protocol.

What QUIC Is

QUIC is built on UDP, which promises almost nothing—packets might arrive, might not, might arrive out of order. This sounds like a downgrade. It's actually freedom.

UDP's emptiness lets QUIC implement exactly what modern applications need:

Native streams exist at the transport layer. QUIC knows that stream 5 and stream 6 are independent. When stream 5 loses a packet, stream 6 continues uninterrupted. Head-of-line blocking becomes per-stream, not per-connection.

Built-in encryption makes TLS mandatory and integrated. There is no unencrypted QUIC. The handshake combines transport setup and cryptographic setup into one exchange.

Connection IDs identify connections independent of IP addresses. This matters more than it sounds.

The Handshake Revolution

TCP + TLS requires a courtship ritual:

1. TCP SYN
2. TCP SYN-ACK
3. TCP ACK
4. TLS ClientHello
5. TLS ServerHello and certificate
6. TLS Finished
7. Finally, your actual request

Two round-trips minimum before a single byte of application data flows.

QUIC combines everything. Client sends initial parameters including TLS in one packet. Server responds with its parameters and completes the handshake. One round-trip. Application data flows immediately.

For returning visitors, QUIC offers something stranger: zero round-trips. The client sends encrypted application data with its very first packet using parameters from a previous connection. The server responds with application data immediately.

This sounds like magic until you realize the tradeoff: the server cannot know if that first packet is fresh or a replay of yesterday's request. 0-RTT data might be replayed by an attacker. Only idempotent requests—ones where repeating them causes no harm—should use 0-RTT.

Connection Migration

A TCP connection is defined by four things: source IP, source port, destination IP, destination port. Change any one and the connection breaks.

You're on a video call at home. You walk outside. Your phone switches from WiFi to cellular. Your IP address changes. Your TCP connection dies. The video app must reconnect, renegotiate TLS, restore state.

QUIC connections use connection IDs. Your IP address changes, but the connection ID doesn't. You send packets from your new IP address with the same connection ID. The server recognizes you. The video call continues without interruption.

This is transformative for mobile users who constantly transition between networks. Connections survive what used to kill them.

Security as Foundation

TCP treats encryption as optional—something you layer on top if you want it. QUIC treats encryption as mandatory.

Every QUIC packet is encrypted using TLS 1.3. Not just the payload—most header fields are encrypted too. Network equipment cannot inspect or manipulate QUIC traffic the way it can with TCP.

This improves privacy. It also prevents ossification—the problem where middleboxes start depending on protocol internals, making the protocol impossible to evolve. QUIC's encrypted headers ensure only endpoints can interpret them.

HTTP/3: HTTP Over QUIC

HTTP/3 is HTTP semantics—methods, headers, status codes—transported over QUIC instead of TCP.

The adaptation is straightforward: each HTTP request uses a separate QUIC stream. Header compression (QPACK) replaces HTTP/2's HPACK, redesigned for streams that might arrive out of order.

HTTP/3 removes server push, which proved too complex and underutilized in HTTP/2. It simplifies priority signaling based on what actually worked in practice.

The changes are at the transport layer. Application code rarely needs modification.

What the Numbers Show

On good networks: 5-10% faster than HTTP/2. The handshake improvements matter, but TCP handles reliable networks reasonably well.

On lossy networks: 20-30% faster. This is where QUIC shines. Packet loss no longer cascades across streams. Mobile users on inconsistent connections see the biggest gains.

Connection migration provides benefits that don't show in simple benchmarks. Users who move between networks experience continuity instead of reconnection.

Why Adoption Takes Time

UDP has a reputation problem. Corporate firewalls often block it. Public networks rate-limit it. Historical abuse (DNS amplification attacks, UDP floods) made network operators suspicious.

HTTP/3 falls back to HTTP/2 when UDP fails. Graceful degradation, but the benefits disappear.

QUIC implementation is harder than TCP. TCP has decades of optimization, much of it in kernel code with hardware acceleration. QUIC runs in userspace, doing encryption that TCP offloads to hardware. The CPU overhead is higher, though narrowing as implementations mature.

Debugging tools lag behind. tcpdump and Wireshark understand TCP intimately. QUIC support exists but lacks depth. Network operators cannot see inside encrypted QUIC packets—a privacy feature that's also a debugging obstacle.

Where We Are Now

Every modern browser supports HTTP/3. Chrome, Firefox, Safari, Edge—all of them.

Major CDNs serve HTTP/3: Cloudflare, Fastly, Akamai, Amazon CloudFront. Google, Facebook, and much of the modern web use it.

Current estimates: 25-30% of web traffic uses HTTP/3, and growing.

Discovery happens through Alt-Svc headers (servers advertise HTTP/3 availability) or DNS HTTPS records (advertising in DNS for first-connection use). Both allow graceful fallback.

The Larger Significance

QUIC proves that fundamental Internet protocols can be replaced. TCP seemed permanent—so deeply embedded that change was impossible. QUIC demonstrates otherwise.

The approach matters: build on UDP, implement everything in userspace, encrypt everything so middleboxes cannot ossify around implementation details. Evolution becomes possible again.

QUIC is already being adapted for non-HTTP uses. DNS over QUIC. WebTransport for real-time applications. The benefits of native streams, fast handshakes, and connection migration apply broadly.

The Internet's transport layer, frozen for decades, is moving again.