Chapter 11: QUIC & HTTP/3

---

Metadata Card

Attribute	Content
Volume	Vol 4 — Computer Networking
Chapter	Chapter 11: QUIC & HTTP/3
Prerequisites	Chapter 3 (TCP Deep Dive), Chapter 4 (HTTP), Chapter 5 (HTTPS & TLS)
Next	Chapter 12 (Network Debugging)
Theory Depth	(3/5)
Python Relevance	≈90%; aioquic library for QUIC client/server
Core Models	QUIC connection lifecycle, 0-RTT handshake, HOL-free multiplexing, QPACK
Code	~150 lines

---

Your Progress

"TCP is good, but its incantation comes from the 1980s post road world. The 2020s magic post road needs something faster, more flexible, without queuing concerns — QUIC and HTTP/3 are the answer. They abandon TCP entirely, rebuilding reliable transport directly on UDP mana carrier pigeons."

TCP's Three Sins

Sin 1: Connection Setup Latency

TCP three-way handshake: SYN →          1 RTT (~50ms)
                         ← SYN-ACK
                         ACK →

TLS 1.3 handshake:       ClientHello →  1 RTT (~50ms)
                         ← ServerHello + Finished
                         Finished →

Total: ~2 RTT = 100ms (even in the same city)
If server is on another continent (RTT 200ms): = 400ms

During these 100-400ms, the browser can do nothing — the connection isn't established yet.

Sin 2: Head-of-Line Blocking

HTTP/2 multiplexing shares one TCP connection. But TCP's reliability is at the byte stream level — if one packet (from stream 1) is lost, TCP blocks delivery of ALL subsequent packets, including those from unrelated streams 2 and 3.

Sin 3: No Connection Migration

TCP identifies a connection by (src_ip, src_port, dst_ip, dst_port) — change IP = connection dead. Switch from WiFi to cellular? All TCP connections break.

QUIC's Answer: Use UDP

Why UDP? UDP gives you the minimal abstraction — sendto() and recvfrom(). Whether packets arrive, in order, or duplicated — none of that is guaranteed. QUIC reimplements all TCP functionality (reliable transport, flow control, congestion control) plus encryption, multiplexing, and connection migration — in userspace, without changing a line of kernel code.

Traditional: [Application HTTP/2]
             [Transport TCP]        ← Kernel space, updates need OS upgrade
             [Network IP]
             [Link Layer]

QUIC:        [Application HTTP/3]
             [QUIC (in userspace)]  ← User space, update = library upgrade
             [UDP]                  ← OS only needs to support UDP
             [IP]
             [Link Layer]

0-RTT Connection Establishment

First connection (1-RTT): Like TLS 1.3, QUIC establishes in 1 round trip.

Subsequent connections (0-RTT): The server issues a Session Ticket. The client sends encrypted HTTP requests immediately — no network round trips needed before sending data.

Connection Migration — WiFi to Cellular Without Breaking

QUIC identifies connections with a 64/128-bit Connection ID, not IP:port. Change IP, keep the same Connection ID — the connection survives.

HTTP/3 — HTTP over QUIC

Component	HTTP/2	HTTP/3
Transport	TCP	QUIC
Multiplexing	Multiple streams over TCP (HOL affected)	Independent QUIC streams (no HOL)
Header Compression	HPACK (relies on TCP ordering)	QPACK (adapted for out-of-order delivery)

QPACK

QPACK splits the compression table into encoder and decoder tables, synced via a separate instruction stream. This decouples "header data" from "table sync" — out-of-order arrival of streams won't corrupt the shared compression state.

---

Traveler's Notes

QUIC represents the biggest change to internet transport in 40 years. Google's internal data shows QUIC reduces video buffering time by 30%+ on mobile devices. With YouTube using QUIC, reconnection latency dropped from >1000ms to <100ms. TCP's 40-year reign is finally seeing its successor.