1. Library
  2. TCP and UDP
  3. UDP Deep Dive

Updated 1 day ago

QUIC: Rebuilding Reliable Transport Without TCP's Constraints

Every TCP connection starts with a ritual. Your device sends a SYN. The server responds with SYN-ACK. You reply with ACK. That's one round trip before anything real happens. Now add TLS encryption: more messages, another round trip. On a fiber connection in the same city, you barely notice. On a mobile network in rural India, you're waiting 400 milliseconds before a single byte of your actual request travels the wire.

QUIC eliminates this ritual. It establishes encrypted connections in a single round trip—sometimes zero. And that's just the beginning of what changes when you rebuild reliable transport from scratch on top of UDP.

The Problem with TCP

TCP was designed in 19741. It has served remarkably well, but three limitations have become increasingly painful as the Internet evolved.

The handshake tax. Every new TCP connection requires a three-way handshake. Add TLS for encryption, and you need another exchange. That's two round trips minimum before application data flows. On high-latency networks, this adds hundreds of milliseconds to every new connection.

Head-of-line blocking. TCP guarantees that bytes arrive in order. If packet 5 gets lost, packets 6, 7, and 8 must wait—even if they contain completely unrelated data. HTTP/2 tried to multiplex multiple requests over one TCP connection, but this made the problem worse: lose one packet, and every request stalls.

Fragile identity. TCP identifies connections by four numbers: source IP, source port, destination IP, destination port. Change any one—like when your phone switches from WiFi to cellular—and the connection dies. You start over.

These aren't bugs. They're consequences of decisions made fifty years ago, baked into operating system kernels worldwide. You can't fix TCP without updating every device on the Internet.

What QUIC Actually Is

QUIC is a transport protocol that provides reliable, ordered delivery—like TCP—but runs on UDP. Google started building it in 2012; the IETF standardized it in 2021.

The UDP foundation matters. UDP is simple: it sends packets without guarantees. No handshakes, no ordering, no reliability. QUIC builds all of those features on top of UDP, but in application code rather than the kernel. This means QUIC can evolve without waiting for operating system updates.

TCP is infrastructure buried in the ground. Changing it requires updating billions of devices maintained by thousands of organizations—phones, servers, routers, IoT sensors. Even small TCP changes take years to propagate. QUIC sidesteps this by running in user space, where applications control their own updates.

Connections in One Round Trip

QUIC combines the transport handshake and the TLS handshake into a single exchange. Client sends its hello and cryptographic parameters; server responds with its hello and the connection is established. One round trip, and you're sending encrypted data.

For returning visitors, it gets better. QUIC can resume previous sessions with zero round trips. The client sends encrypted application data in its very first packet. The server can respond immediately. This 0-RTT mode is what makes QUIC feel instant on repeat visits.

Streams That Don't Block Each Other

Within a single QUIC connection, you can open multiple independent streams. Each stream has its own ordering guarantees. If a packet belonging to stream 4 gets lost, only stream 4 waits for retransmission. Streams 1, 2, and 3 continue uninterrupted.

This solves HTTP/2's multiplexing problem. When your browser requests an image, a stylesheet, and a script over HTTP/2 on TCP, they share one ordered byte stream. Lose a packet from the image, and the stylesheet and script wait too. Over QUIC, each resource gets its own stream. Packet loss affects only the resource that lost the packet.

This is why HTTP/3—the version of HTTP built on QUIC—exists. The protocol couldn't reach its potential on TCP.

Connection Migration

TCP remembers you by where you're standing: your IP address and port. Move—switch networks—and TCP forgets you exist. The connection breaks. You start the handshake ritual again.

QUIC gives connections an ID instead. When your phone switches from WiFi to cellular, your IP address changes, but your connection ID doesn't. The QUIC connection migrates to the new network path without interruption. Your video call continues. Your download resumes.

We spent decades building a reliable Internet on a foundation that breaks the moment you walk from your living room to your kitchen. Connection migration fixes this.

Encryption Is Not Optional

TCP treats encryption as a separate concern. You can run TCP without TLS. Many applications do, either intentionally or through misconfiguration.

QUIC encrypts everything except the initial handshake. There is no unencrypted mode. You cannot accidentally deploy QUIC without encryption, because the protocol doesn't support it.

This makes the Internet more secure by default. It also makes QUIC harder to interfere with—middleboxes can't inspect or modify what they can't read.

HTTP/3: QUIC's Primary Application

HTTP/3 is the first major Internet protocol built on QUIC. While HTTP/1.1 and HTTP/2 run on TCP, HTTP/3 runs exclusively on QUIC.

The combination addresses every performance problem HTTP/2 faced. No head-of-line blocking across requests. No multi-round-trip connection setup. No broken connections when networks change. HTTP/3 is what HTTP/2 wanted to be, finally possible because the transport layer cooperates.

Deployment Reality

QUIC adoption has grown rapidly. Chrome, Firefox, Safari, and Edge all support HTTP/3. Cloudflare, Fastly, and major cloud providers offer QUIC endpoints. As of 2025, approximately 30-36% of websites support HTTP/3, and around 40% of Chrome browser traffic uses QUIC2.

But challenges remain. Some corporate firewalls block UDP except on specific ports. Deep packet inspection equipment may not handle QUIC properly. Browsers implement fallback: try QUIC first, fall back to HTTP/2 over TCP if it fails.

This fallback pattern means QUIC adoption can happen gradually. Sites can enable HTTP/3 knowing that incompatible networks will still work. Over time, as network equipment becomes QUIC-aware, more connections will use the faster protocol.

Why This Matters

QUIC delivers the same guarantees as TCP—reliable, ordered delivery with congestion control—without the constraints that came packaged with those guarantees fifty years ago. No handshake rituals. No head-of-line blocking across unrelated data. No identity tied to network location.

The performance benefits are real and measurable, particularly on mobile networks, high-latency connections, and lossy wireless links. But the deeper lesson is architectural: by building on UDP in user space, QUIC can evolve at the speed of application updates rather than the speed of kernel updates.

TCP isn't going away. But the Internet can finally have reliable transport that doesn't punish you for moving.

Frequently Asked Questions About QUIC

Sources

Sources

  1. Transmission Control Protocol (TCP) 1973-1976 | History of Computer Communications

  2. An update on QUIC Adoption and traffic levels - CellStream, Inc.

Was this page helpful?

😔
🤨
😃
QUIC: Rebuilding Reliable Transport Without TCP's Constraints • Library • Connected