QUIC: the transport hiding inside UDP

QUIC is TCP and TLS redesigned together, with thirty years of lessons applied, and then smuggled across the internet inside UDP packets so that nothing in between has to change. It is what HTTP/3 runs on, which means it already carries a large share of web traffic. This page is about what it fixes, how the pieces fit, and what you give up.

The map

Read this first when short on time. Every branch is a section below.

Why anyone would build a new transport

TCP works. It has worked for forty years. But three of its problems could not be fixed in place, and by 2012 they were costing real time on every page load.

One lost packet stalls everything. TCP is a single ordered stream. HTTP/2 puts many requests on one connection, so when one packet is lost, every request on that connection waits for the retransmit, even the ones whose data has already arrived. The TCP article calls this head-of-line blocking. On a lossy mobile link it makes HTTP/2 slower than the HTTP/1.1 it replaced.

Two handshakes before a byte. TCP needs a round trip to connect, and then TLS needs another to agree on keys. On a 200 ms path that is 400 ms of waiting before the request is even sent, as the packet journey adds up.

A connection is tied to four numbers. Source address, source port, destination address, destination port. When your phone walks out of Wi-Fi range and onto cellular, its address changes, every TCP connection dies, and every app reconnects.

None of these can be patched into TCP. The header is visible to every router and firewall on the path, and many of them inspect it and drop anything unfamiliar; the protocol is frozen by the middleboxes that watch it. This is called ossification. And TCP lives in the operating system kernel, so a change ships when every OS updates, which is years.

So Google built a transport that avoids both traps. It runs in user space, inside the browser or the server program, so it ships with the app. It travels in UDP datagrams, which every middlebox already passes. And it encrypts almost the entire header, so no middlebox can inspect it, depend on it, or freeze it. The UDP article explains why UDP was the only usable base: it does nothing, which is exactly what a new transport needs underneath.

Head-of-line blocking

One lost packet holding back data behind it that has already arrived.

Ossification

A protocol becoming impossible to change because devices in the middle depend on its current shape.

User space transport

A transport protocol implemented in the application or a library instead of the kernel.

One handshake for transport and encryption

QUIC does not have a TLS handshake after a transport handshake. It has one handshake that does both. The TLS 1.3 messages travel inside the very first QUIC packets, so the keys are agreed in the same round trip that establishes the connection.

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server
  Note over C,S: TCP plus TLS 1.3: two round trips
  C->>S: SYN
  S-->>C: SYN-ACK
  C->>S: ACK, ClientHello
  S-->>C: ServerHello, certificate, Finished
  C->>S: Finished, GET /
  Note over C,S: QUIC: one round trip
  C->>S: Initial: ClientHello
  S-->>C: Initial and Handshake: ServerHello, certificate, Finished
  C->>S: Finished, GET /

1. The client sends an Initial packet with the TLS ClientHello inside: supported ciphers, its key share, the server name. The packet is padded to at least 1,200 bytes, which proves the path can carry that size and stops a tiny packet from triggering a large reply.
2. The server replies with the ServerHello, its certificate and its own key share, and its own transport parameters. Both sides now derive the keys. The server may already send application data encrypted with them.
3. The client confirms with a Finished message, and its first request goes in the same packet. One round trip, and the request is on the wire.

On a repeat visit it is faster still. The client kept a ticket from the last session and can encrypt data with keys derived from it before hearing from the server at all. This is 0-RTT: the first packet carries the request. The catch is that an attacker who captured that packet can replay it, and the server cannot tell, so 0-RTT data must be safe to process twice. A GET is fine. A payment is not. Browsers send only idempotent requests this way, and servers may reject 0-RTT for anything else.

One more rule protects against amplification, the attack the UDP article describes. Until the client has proved it really is at the address it claims, by echoing something the server sent, the server may send at most three times the bytes it received. That is why the first client packet is padded to 1,200 bytes: it buys the server room to reply with its certificate.

Initial packet

The first QUIC packet, carrying the TLS ClientHello. Encrypted with keys anyone can derive, which stops casual inspection but not a determined observer.

0-RTT

Sending application data in the very first packet of a resumed connection, using keys from the previous session.

Address validation

Proving a client can receive at the address it sends from, before the server sends more than three times what it got.

Streams: many independent conversations in one connection

Inside one QUIC connection there are many streams, and each one is its own ordered, reliable byte stream. A lost packet delays only the streams whose data was in it. Every other stream keeps flowing. This is the fix for head-of-line blocking, and it is the single biggest difference from TCP.

flowchart LR
  P1["packet 7<br/>stream 0: 0 to 800<br/>stream 4: 0 to 400"] --> R
  P2["packet 8<br/>stream 4: 400 to 1200"] -. lost .-> R
  P3["packet 9<br/>stream 8: 0 to 1000"] --> R
  P4["packet 10<br/>stream 0: 800 to 1600"] --> R
  R["Receiver"] --> S0["stream 0<br/>1600 bytes delivered"]
  R --> S4["stream 4<br/>400 delivered, waiting"]
  R --> S8["stream 8<br/>1000 bytes delivered"]

Streams are cheap to create: sending data on a new stream ID creates it, with no handshake. They are numbered so the two sides never collide: the low two bits of the ID say who opened it and whether it is one-way or two-way, so client-opened bidirectional streams are 0, 4, 8 and server-opened ones are 1, 5, 9. A stream ends with a FIN bit on its last frame, or is cut off with a RESET frame that says "stop, forget the rest". Resetting one stream costs nothing to the others, which is how a browser abandons one image download without touching the rest of the page.

Flow control works at two levels. Each stream has its own window, so one slow consumer cannot eat the whole connection's buffer, and the connection has a total window on top. Both are advertised with MAX_STREAM_DATA and MAX_DATA frames and grow as the receiver reads, like TCP's receive window in the TCP article but multiplied.

Stream

One ordered, reliable byte stream inside a QUIC connection. Independent of every other stream for loss and flow control.

RESET_STREAM

Abandon one stream immediately without affecting the connection.

Packets and frames: how loss is detected

A QUIC packet is an encrypted envelope with a number. Inside it are frames: pieces of stream data, acknowledgements, control messages. The separation of the two is what makes QUIC's loss recovery cleaner than TCP's.

The rule that matters: a packet number is never reused. TCP retransmits a lost segment with the same sequence number, so when an ACK arrives the sender cannot tell whether it is for the first copy or the retransmit, and its round trip estimate is wrong. QUIC puts the retransmitted stream data into a fresh packet with a fresh number. Every ACK unambiguously names one transmission, so round trip times are exact, and loss is detected by gaps in the numbers rather than by guessing.

ACK frames list ranges, so one frame can say "I have 1 to 40, 42 to 57, and 60" and the sender knows exactly what to resend. It resends the frames that were in the lost packets, not the packets themselves, so an ACK frame that was lost is simply replaced by a newer one and stream data is repackaged however fits.

Congestion control is the same idea as TCP's: start small, grow while acknowledgements come back, cut back on loss. The standard describes a Reno-like algorithm and implementations use Cubic or BBR, the same names as in the Linux kernel. The difference is where it runs: in the library, in the application, tunable per deployment, upgradeable with a software release.

Frame

One unit of content inside a packet: stream bytes, an ACK, a control message.

Packet number

A counter that never repeats within a connection, so every ACK is unambiguous.

ACK range

A run of packet numbers received, so gaps are described exactly.

Connection IDs and migration

A TCP connection is identified by its two addresses and two ports, so it cannot survive any of them changing. A QUIC connection is identified by a connection ID, a random token carried in every packet. The addresses are just where the packets happen to come from right now.

sequenceDiagram
  autonumber
  participant P as Phone
  participant S as Server
  P->>S: packets from Wi-Fi 192.0.2.5, connection ID ab12
  Note over P: leaves the house, switches to cellular
  P->>S: packet from 198.51.100.9, same connection ID ab12
  S->>P: PATH_CHALLENGE to the new address
  P-->>S: PATH_RESPONSE
  Note over S: new path confirmed, keep going
  S->>P: stream data continues, no reconnect

When the server sees a known connection ID arrive from a new address, it does not just trust it, because that would let an attacker redirect someone's download to a victim. It sends a PATH_CHALLENGE to the new address and waits for the echo. Once confirmed, the connection continues on the new path, with the congestion window reset because the new path may be very different.

The same mechanism handles the mundane case of a NAT quietly changing your port after a period of idleness, which on TCP would also kill the connection. And because each side hands the other several connection IDs in advance, a migrating client can switch to a fresh one, so an observer cannot link the Wi-Fi traffic to the cellular traffic by the ID.

Connection ID

A random identifier in every packet that names the connection independently of addresses.

Path validation

A challenge and echo that prove a new address belongs to the peer before traffic moves to it.

HTTP/3: HTTP on top of it

HTTP/3 is the same HTTP the HTTP article describes, the same methods, headers and status codes, carried over QUIC instead of TCP. The differences are all in the plumbing.

Each request goes on its own bidirectional stream, so responses arrive in whatever order they are ready. Header compression had to change: HTTP/2's HPACK assumes headers arrive in order, which QUIC streams do not guarantee, so QPACK sends the shared dictionary updates on a separate stream and lets headers refer to entries only once they are known to have arrived.

A browser does not know a site speaks HTTP/3 until it is told. It connects over TCP first, and the server's response includes an Alt-Svc: h3=":443" header, after which the browser tries QUIC on the next connection and remembers the result. A newer way is an HTTPS record in DNS that announces it before any connection. If the QUIC attempt gets no reply, because a firewall drops UDP, the browser goes back to HTTP/2 without the user noticing.

QPACK

HTTP/3's header compression, designed to work when streams arrive out of order.

Alt-Svc

A response header telling the client that the same service is available on another protocol, used to advertise HTTP/3.

What QUIC costs

Nothing in networking is free, and QUIC pays in three places.

CPU. TCP has forty years of hardware help: network cards segment and checksum for it, and the kernel path is tight. QUIC encrypts every packet individually, runs in user space with a system call per datagram or batch, and has fewer offloads to lean on. Servers report QUIC using two or three times the CPU of TCP for the same bytes, and the gap is closing as UDP offloads and kernel batching improve, but it has not closed.

Blocked UDP. A few percent of networks drop or throttle UDP, particularly on port 443. Every QUIC client carries a fallback to TCP and pays a wasted attempt when it is needed. Some enterprise networks block QUIC deliberately so their inspection proxies can keep seeing HTTP/2.

Visibility. The encrypted header that protects QUIC from ossification also hides it from operators. Wireshark shows a UDP flow; nothing in the middle can measure loss, retransmits or round trip times the way it can for TCP. The designers left one bit, the spin bit, that flips once per round trip so a passive observer can estimate latency, and many implementations do not set it.

And QUIC is not for everything. Inside a data centre, where loss is rare and the network is trusted, TCP with hardware offload is faster and cheaper. QUIC earns its cost on the paths it was designed for: lossy, long, mobile, and shared with middleboxes.

Offload

Work a network card does instead of the CPU: checksums, segmentation, sometimes encryption.

Spin bit

The one unencrypted QUIC header bit that lets an observer estimate round trip time.

Recap