Why HTTP/3 Runs Exclusively on QUIC and UDP

HTTP/3 represents a fundamental evolution in web architecture by discarding the traditional Transmission Control Protocol (TCP) in favor of QUIC, which operates over User Datagram Protocol (UDP). This article explains the technical limitations of TCP that led to this shift, how QUIC resolves issues like head-of-line blocking and connection latency, and why UDP was selected as the underlying transport layer to achieve faster, more reliable, and encrypted web communications.

Overcoming Head-of-Line Blocking

HTTP/2 introduced multiplexing, allowing multiple requests and responses to travel concurrently over a single TCP connection. However, because TCP enforces strict in-order delivery of all packets at the transport level, losing a single packet pauses the entire connection. All streams are forced to wait until the missing packet is retransmitted and acknowledged.

QUIC solves this by implementing independent streams directly at the transport layer. If a packet belonging to one HTTP stream is lost, only that specific stream is delayed. The other streams continue transferring data uninterrupted, eliminating the transport-level head-of-line blocking that plagued HTTP/2 over TCP.

Faster Connection Handshakes

Establishing a secure connection over TCP requires multiple round trips: 1. The standard TCP three-way handshake (SYN, SYN-ACK, ACK). 2. The Transport Layer Security (TLS) cryptographic handshake.

Even with TLS 1.3, this process requires at least two round-trip times (2-RTT) before any application data can be sent.

QUIC combines the transport and security handshakes into a unified exchange. By integrating TLS 1.3 directly into its protocol, QUIC achieves a 1-RTT connection setup for new connections. For repeat connections, QUIC supports 0-RTT handshakes, allowing the client to send encrypted application data in the very first network packet.

Seamless Connection Migration

TCP identifies connections using a four-tuple: source IP, source port, destination IP, and destination port. If a user switches networks—such as moving from Wi-Fi to mobile data—the IP address changes, causing the TCP connection to break and forcing the application to renegotiate the entire session.

QUIC replaces IP-based identification with a unique 64-bit Connection ID (CID). Because the CID remains constant regardless of network changes, active downloads, video streams, or requests continue seamlessly without reconnection delays or state loss.

Avoiding Middlebox Ossification with UDP

Modifying or replacing TCP directly is practically impossible due to protocol ossification. Over decades, millions of internet routers, firewalls, and NAT devices (“middleboxes”) have been hardcoded to inspect and enforce strict TCP behaviors. Any new transport protocol or major TCP modification is routinely dropped or blocked by these intermediate devices.

UDP provides a lightweight, stateless envelope that is already universally permitted across the global internet infrastructure. By running over UDP, QUIC can implement its advanced congestion control, loss recovery, and stream multiplexing in user space rather than relying on OS kernel updates. Furthermore, because QUIC encrypts almost all of its transport headers, intermediate middleboxes cannot inspect or tamper with its internal mechanics, ensuring long-term extensibility and privacy.