Why HTTP/3 Runs on UDP (And What That Actually Means)

If you told a networking engineer a decade ago that the web would eventually move its transport layer from TCP to UDP, they’d have called it reckless. UDP is the “unreliable” protocol — no delivery guarantees, no ordering, no congestion control. TCP is the dependable workhorse underneath essentially everything on the web.

Yet HTTP/3, the current version of HTTP, does exactly that. It runs over QUIC, a protocol built on UDP. This wasn’t a stunt. It was the only practical way to fix real, compounding problems with how HTTP worked at the transport layer — problems that TCP’s own success made impossible to solve directly.

The Problem TCP Became

TCP has been remarkably stable since the 1970s. That stability comes at a cost: the protocol is now baked into hundreds of millions of network devices — firewalls, load balancers, NAT boxes, carrier-grade middleboxes — that inspect TCP headers and sometimes modify traffic based on assumptions about how TCP is supposed to behave.

This is called middlebox ossification. Because so many devices in the network “understand” TCP, any meaningful change to the protocol risks being silently broken or dropped by some device along the path. Attempts to extend TCP with new options or behaviors have repeatedly failed in practice because middleboxes interfere. TCP, in other words, became too widely deployed to evolve.

HTTP/2 worked around some of this by multiplexing multiple request streams over a single TCP connection. That was a real improvement. But it introduced a different problem: head-of-line blocking at the transport layer. TCP guarantees in-order delivery. If one packet gets lost, TCP stalls every stream on that connection while it waits for a retransmission — even streams that have no relation to the lost packet. On a lossy connection (mobile networks, for instance), this is a serious performance hit.

What QUIC Actually Does

QUIC, originally developed at Google before being standardized by the IETF, solves this by moving the transport logic to userspace, sitting on top of UDP.

UDP itself does almost nothing — it just sends datagrams with no guarantees. That’s the point. QUIC implements its own reliability, ordering, flow control, and congestion control on top of UDP, but it does so at the application layer where it can actually be updated. When a better congestion control algorithm comes along, you ship it in a library update, not a kernel patch or an IETF standards process that takes a decade to reach real-world deployment.

The key technical improvements QUIC brings over TCP-based HTTP:

Per-stream flow control. A lost packet only blocks the stream it belongs to. Other streams on the same connection continue flowing normally. This directly eliminates the head-of-line blocking problem that HTTP/2 couldn’t escape.

Faster connection establishment. TCP requires a handshake, then TLS requires another. QUIC folds them together. A new connection to a known server can complete in a single round trip; subsequent connections can resume with zero additional round trips (0-RTT), sending data before the handshake finishes.

Connection migration. A QUIC connection is identified by a connection ID, not by the client’s IP address and port tuple. This means a phone switching from Wi-Fi to cellular keeps its connection alive without a reconnect. TCP can’t do this — the connection is fundamentally tied to the network address.

The Irony Worth Noting

QUIC essentially reimplements TCP, but in a place where it can evolve. Reliability, ordering, congestion control — all the things that made TCP trusted are present in QUIC. The difference is architectural: by running in userspace over UDP, QUIC sidesteps every middlebox that expects TCP semantics. The ossification problem becomes someone else’s problem.

This is a broader pattern in internet infrastructure. When a foundational protocol gets too entrenched to change, the industry doesn’t wait for it to change — it builds a new layer on top. DNS-over-HTTPS, encrypted SNI, QUIC itself: the trend is consistently toward moving protocol logic higher in the stack, where deployment is faster and legacy hardware can’t interfere.

HTTP/3 isn’t a replacement for everything TCP does. TCP isn’t going anywhere for databases, SSH, or bulk data transfers. But for latency-sensitive, multiplexed web traffic on unreliable networks, the transport layer needed to change — and the only way to change it was to leave TCP’s territory entirely.