Heads up: posts on this site are drafted by Claude and fact-checked by Codex. Both can still get things wrong — read with care and verify anything load-bearing before relying on it.
why → how

Why does QUIC exist when TCP already works?

TCP works fine — until you're on a flaky phone connection, juggling a dozen multiplexed streams, and one lost packet stalls all of them. QUIC is the protocol designed around that specific frustration.

Networking intermediate Apr 29, 2026

Why it exists

Picture this: you’re on a video call walking out of your house. Your phone hops from home Wi-Fi to mobile data. With most older internet protocols the call would drop right there — your phone’s “address” just changed, and the connection is defined by that address. With newer ones, the call survives the switch without a hiccup. That’s QUIC at work. Same goes for the moment a single packet gets lost on a flaky hotel Wi-Fi: with TCP every other download in your browser briefly freezes too. QUIC was designed so only the affected file pauses.

For decades, the answer to “how do two computers reliably exchange a stream of bytes over the internet?” has been TCP. It works. It’s everywhere. So why did Google spend years inventing a replacement and pushing it through the IETF?

Because TCP was designed in a world that no longer exists. Three things changed underneath it, and the friction kept growing:

  1. Connections move now. Your phone hops between Wi-Fi and cellular mid-page-load. A TCP connection is keyed by (source IP, source port, dest IP, dest port) — change any of those four and the connection is, by definition, dead.
  2. Pages need many things at once. A modern page pulls dozens of resources in parallel. HTTP/2 tried to fix this by multiplexing many streams over a single TCP connection. But TCP is a single ordered byte stream — if one packet is lost, every stream above it has to wait. This is head-of-line blocking, and HTTP/2 made it worse, not better, on lossy links.
  3. Encryption is the default. TLS used to be optional. Now it’s mandatory for anything serious. But TLS sits on top of TCP, so connecting takes a TCP handshake (one round trip) plus a TLS handshake (one or two more). On a satellite link or congested mobile, that’s painful before any actual data moves.

You could fix all of this inside TCP, in theory. In practice you can’t, because TCP lives in the kernel and middleboxes — routers, NATs, “smart” firewalls — have spent thirty years hard-coding assumptions about what TCP packets look like. Try to add a new TCP option and a chunk of the internet’s middle silently drops your packets. This is protocol ossification: the protocol can’t change because the network refuses to let it.

QUIC’s move is to side-step that entirely. Build a new transport on top of UDP, encrypt everything (including the parts middleboxes try to inspect), and put the protocol in userspace so applications can ship updates without waiting for the kernel.

Why it matters now

If you serve traffic to browsers, you’re already using QUIC for a chunk of it. HTTP/3 is HTTP carried over QUIC, and the major browsers and CDNs negotiate it by default when both sides support it. Your phone’s first connection to a popular site this morning probably went over QUIC and you didn’t notice — which is the whole point.

For engineers, the practical consequences:

The short answer

QUIC = UDP + TLS 1.3 + per-stream reliability + connection IDs

QUIC is a reliable, multiplexed, encrypted transport built on UDP instead of TCP. It folds the crypto handshake into the transport handshake, gives each logical stream its own loss recovery so a dropped packet doesn’t stall its neighbors, and identifies connections by an ID rather than the source/destination 4-tuple — so the connection survives when the network path underneath changes.

How it works

Three design moves do most of the work.

1. UDP as the substrate. QUIC packets ride inside UDP datagrams. UDP gives you almost nothing — just “deliver this to that IP/port, maybe” — and that’s exactly the appeal. There’s so little structure for middleboxes to ossify against. The protocol logic that TCP does in the kernel (sequence numbers, acknowledgments, congestion control, retransmission) all moves into a QUIC library in userspace.

2. Encryption is part of the transport, not a layer above it. In TCP+TLS the transport runs first, then TLS negotiates on top. In QUIC, almost every byte of every packet is encrypted or authenticated from the start, including fields a middlebox would historically read. The handshake reuses TLS 1.3’s key schedule but folds it into the transport’s own packets. The result is one unified handshake instead of two.

This is also a deliberate anti-ossification move. If middleboxes can’t read the fields, they can’t grow assumptions about them, and the protocol stays free to evolve.

3. Streams are first-class, and independent. A QUIC connection carries many streams. Each has its own sequence space and its own retransmission state. Lose a packet on stream 7 and only stream 7 is held up; streams 1–6 and 8–N keep delivering bytes to the application. This is the head-of-line blocking fix, and it’s the part HTTP/2 fundamentally couldn’t do because TCP underneath only knew about one stream.

Connection IDs. Instead of (srcIP, srcPort, dstIP, dstPort), a QUIC connection is identified by an opaque connection ID chosen during the handshake. If your IP changes — Wi-Fi to LTE, NAT rebinding — the connection ID is still valid, and after a small “is this really you?” check the connection continues. TCP fundamentally can’t do this without protocol surgery.

Show the seams

A few things the marketing version glosses over:

Going deeper