When Google's networking team set out to design QUIC, they faced a fundamental architectural decision: what transport substrate should they build upon? They could attempt to extend TCP, create an entirely new IP-level protocol, or build on top of an existing transport. Their choice—User Datagram Protocol (UDP)—was neither obvious nor accidental. It was a strategic masterstroke that enabled QUIC to succeed where other transport protocol innovations had failed.

UDP as a "universal pass-through":

UDP's simplicity—essentially just a thin multiplexing layer over IP with minimal error checking—makes it the most permissive transport protocol in the Internet's arsenal. NATs translate it, firewalls allow it, load balancers route it, and middleboxes generally leave it alone. This "universal pass-through" property makes UDP the ideal substrate for QUIC's ambitious reliability and encryption layers.

Before exploring why QUIC uses UDP, we must understand why extending TCP wasn't viable. On the surface, TCP seems perfect: it's universally deployed, well-understood, and already provides reliable, ordered delivery. Why not add encryption and multiplexing to TCP directly?

The Ossification Problem Revisited:

TCP's wire format—the structure of TCP headers as they appear on the network—has remained essentially unchanged since RFC 793 in 1981. Not because TCP is perfect, but because the Internet ecosystem has calcified around its exact format. Middleboxes (firewalls, NATs, load balancers, intrusion detection systems) don't just route TCP packets—they parse and modify them.

Consider what happens when you try to add a new TCP option:

1. Firewall drops unknown options: Many firewalls strip or drop packets with unrecognized TCP options, treating them as potential attacks.

2. NATs corrupt extended headers: Some NATs assume fixed TCP header layouts and corrupt data when headers are longer than expected.

3. Middle boxes rewrite segments: Performance-enhancing proxies, WAN optimizers, and other middleboxes may reassemble or split TCP segments, breaking any assumptions about segment boundaries.

4. Load balancers parse headers: Many load balancers make routing decisions based on TCP header fields, failing when those fields change unexpectedly.

Kernel Implementation Friction:

Beyond wire format ossification, TCP is implemented in operating system kernels. Deploying a TCP modification requires:

1. Kernel development and testing (6-12 months)
2. Upstream acceptance into Linux/Windows/macOS/iOS/Android (3-12 months)
3. Distribution through OS updates (6-24 months)
4. User adoption of updated OS versions (years)

Total time from design to widespread deployment: 3-7 years minimum

Compare this to QUIC's user-space deployment model, where a library update can reach production in days or weeks. The innovation velocity difference is transformative.

If TCP can't be extended, why not create an entirely new protocol with its own IP protocol number? This would seem to offer complete design freedom.

The NAT Traversal Catastrophe:

Network Address Translation (NAT) devices—which mediate between private and public IP addresses—are ubiquitous. Virtually every home router, mobile carrier network, and enterprise firewall performs NAT. And NAT devices, by design, understand only established transport protocols.

When a NAT device sees a packet with IP protocol 6 (TCP) or 17 (UDP), it knows how to:

• Extract port numbers for connection tracking
• Maintain state for return traffic
• Implement timeout behaviors
• Handle fragmentation

When a NAT device sees an unknown IP protocol number, it typically has two options:

1. Drop the packet (most common behavior)
2. Pass it through without state (breaking return path)

Either outcome is fatal for a general-purpose transport protocol.

With TCP extension and new protocols ruled out, UDP emerges as the logical choice—but this isn't just a process of elimination. UDP has specific properties that make it an ideal substrate for QUIC.

UDP's Essential Properties:

The User Datagram Protocol (RFC 768, 1980) is remarkably simple: it adds only source port, destination port, length, and checksum to IP datagrams. This simplicity is its strength.

UDP Header (8 bytes):
+--------+--------+--------+--------+
| Source Port     | Dest Port       |  (16 bits each)
+--------+--------+--------+--------+
| Length          | Checksum        |  (16 bits each)
+--------+--------+--------+--------+
|            Payload Data           |
+--------+--------+--------+--------+

UDP provides:

• Multiplexing via port numbers (enabling multiple applications per IP)
• Error detection via checksum (optional in IPv4, mandatory in IPv6)
• Nothing else—no ordering, no reliability, no flow control, no congestion control

This "nothing else" is precisely what QUIC needs. QUIC implements its own reliability, ordering, flow control, and congestion control—features that, if provided by the substrate, would conflict with QUIC's design goals.

UDP provides no reliability guarantees—packets may be lost, duplicated, reordered, or corrupted (beyond checksum detection). QUIC must implement all reliability mechanisms itself, giving it the flexibility to do so optimally.

Packet Numbers, Not Sequence Numbers:

Unlike TCP's sequence numbers (which count bytes), QUIC uses packet numbers (which count packets). Each QUIC packet has a unique, monotonically increasing packet number. This design choice has profound implications:

1. Unambiguous retransmissions: In TCP, a retransmitted segment has the same sequence number as the original, making it difficult to determine whether an ACK acknowledges the original or the retransmission. QUIC retransmissions use new packet numbers, eliminating ambiguity.

2. Simplified RTT estimation: Since each packet number is unique, RTT samples are unambiguous. No need for Karn's algorithm to handle retransmitted segments.

3. Encryption-friendly: Packet numbers serve as nonces for AEAD encryption. Unique packet numbers ensure unique nonces, satisfying cryptographic requirements.

QUIC's Reliability Mechanisms:

QUIC implements the complete suite of reliability features needed for a production transport protocol:

A common misconception about UDP is that it lacks congestion control, making UDP-based protocols dangerous network citizens that can cause congestion collapse. This concern is understandable—raw UDP applications (like some video streamers or DDoS tools) do indeed lack congestion response. However, QUIC is a responsible network citizen.

QUIC Implements Full Congestion Control:

QUIC mandates congestion control, specified in RFC 9002. The specification requires behavior at least as conservative as TCP congestion control, ensuring QUIC doesn't "cheat" by ignoring congestion signals that TCP would respect.

Key congestion control mechanisms:

Algorithm Flexibility:

Because QUIC's congestion control is implemented in user-space libraries, operators can choose and tune algorithms without OS changes:

Google's production QUIC uses BBR by default, which aggressively minimizes queuing delay while maximizing throughput—a profile well-suited to modern internet paths with deep buffers.

While UDP enables QUIC's deployment, it also presents challenges that QUIC must address. The internet treats UDP differently from TCP in several ways that affect QUIC operation.

Challenge 1: NAT Timeout Behavior

NAT devices maintain state to route return packets. For TCP, this state typically persists for hours (since the NAT expects long-lived connections). For UDP, NAT state often times out in 30-120 seconds of inactivity.

QUIC Solution: QUIC endpoints send PING frames or other traffic to keep connections alive through NATs. The keepalive interval should be shorter than the NAT timeout. Connection IDs also help: even if NAT state is lost and the client's external port changes, the server can recognize the connection by Connection ID and accept the path change.

Challenge 2: UDP Amplification Attacks

UDP's connectionless nature enables source IP spoofing. An attacker can send small requests with a forged source IP, causing large responses to flood the victim. DNS, NTP, and memcached have been exploited for such attacks.

QUIC Solution: QUIC mandates that servers never send more data to an unvalidated address than they have received. The Initial packet must be at least 1200 bytes (padded if necessary), and the server's response is limited to 3× this size until the client proves it can receive traffic at its claimed address.

For additional protection, servers can require Retry packets: instead of processing an Initial packet immediately, the server responds with a Retry containing an opaque token. The client must include this token in a new Initial packet, proving it received the Retry at its claimed address. Only then does the server allocate connection state.

The Maximum Transmission Unit (MTU) is the largest packet size that can traverse a network path without fragmentation. Discovering the path MTU is crucial for efficient data transfer—too small wastes bandwidth on headers, too large causes fragmentation (in IPv4) or drops (in IPv6).

TCP's PMTUD Problem:

TCP path MTU discovery (PMTUD) relies on ICMP "Packet Too Big" messages from routers that need to fragment (but can't because Don't Fragment is set). Unfortunately, many networks filter ICMP, creating "PMTUD black holes" where large packets silently vanish.

QUIC's DPLPMTUD Solution:

QUIC uses Datagram Packetization Layer Path MTU Discovery (DPLPMTUD), specified in RFC 8899. Instead of relying on ICMP, DPLPMTUD actively probes the path with increasingly large packets and observes what gets acknowledged.

Despite QUIC's advantages, some network paths don't support it. Enterprise networks may block UDP, ISPs may rate-limit it, or middleboxes may interfere. QUIC deployments must gracefully handle these situations.

Happy Eyeballs for QUIC (RFC 9312):

The Happy Eyeballs algorithm, originally designed for IPv4/IPv6 selection, has been extended for QUIC. When establishing a connection, the client attempts both QUIC (UDP) and TCP/TLS concurrently, with a slight head start for the preferred option.

Alt-Svc Advertisement:

For HTTP/3, servers advertise QUIC support using the Alt-Svc (Alternative Services) HTTP header or DNS HTTPS records. This allows clients connecting via HTTP/2 to learn that QUIC is available for future requests.

HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

OR

Alt-Svc: h3=":443"; ma=86400; persist=1

This header tells clients:

• h3=":443": HTTP/3 is available on UDP port 443
• ma=86400: Cache this information for 86400 seconds (1 day)
• persist=1: This alternative should persist across network changes

We've explored why QUIC uses UDP and how this design decision shapes the protocol's capabilities. Let's consolidate the key concepts:

What's next:

With UDP as the substrate understood, we'll next explore one of QUIC's most transformative features: Connection Migration. This capability—enabled by Connection IDs rather than IP:port tuples—allows QUIC connections to survive network changes that would terminate any TCP connection.