QUIC

QUIC (RFC 9000, 2021) was developed by Google and standardised by the IETF to address structural limitations of TCP. Because TCP is implemented in OS kernels, updating it requires OS upgrades — slow across billions of devices. QUIC runs in user space over UDP, allowing rapid iteration. It packages everything TCP provides (reliability, ordering, flow control, congestion control) plus TLS encryption into a single protocol, while adding stream multiplexing that doesn't suffer from TCP's head-of-line blocking. Google, Cloudflare, and Meta serve significant fractions of their traffic over QUIC today.

Why QUIC was created

HTTP/2 was designed to solve HTTP/1.1's inefficiencies by multiplexing many requests over a single TCP connection. It succeeded in eliminating HTTP-level head-of-line blocking — but exposed a deeper problem. TCP is a single ordered byte stream. When one TCP segment is lost, the OS kernel must wait for its retransmission before delivering any subsequent data to the application, even data belonging to completely independent HTTP/2 streams. This TCP-level head-of-line blocking could not be fixed without changing TCP itself. Additionally, each new TCP+TLS 1.3 connection requires two round trips before the first byte of application data — one for the TCP three-way handshake and one for the TLS handshake. On a 100 ms RTT connection that is 200 ms of setup latency before any content arrives. QUIC was built to solve both problems simultaneously.

Why UDP was chosen

QUIC runs over UDP rather than TCP for two reasons. First, deploying a new transport protocol directly over IP would require every router, firewall, and middlebox in the internet to recognise and permit it — a multi-decade project. UDP is universally permitted on port 443 (or at least widely enough). Second, UDP provides the bare minimum the network layer needs to offer: datagram delivery with source/destination ports, checksums, and no kernel-imposed ordering or reliability. QUIC implements all reliability, ordering, flow control, and congestion control itself in user space, which also means it can be updated by shipping a new version of Chrome or a server-side library — no OS upgrade required.

QUIC vs TCP+TLS comparison

Stream multiplexing without HOL blocking

QUIC implements multiple independent streams within a single connection. Each stream has its own sequence numbering and flow control. When a QUIC packet carrying stream 3 data is lost, only stream 3 is blocked waiting for retransmission — streams 1, 2, 4, and 5 continue delivering data to the application without interruption. This is the fundamental architectural difference from TCP, where a single lost segment blocks the entire connection regardless of how many logical streams HTTP/2 has multiplexed over it. For a web page loading 20 resources in parallel, a single dropped packet under TCP can stall all 20 resources; under QUIC it stalls only the one resource in the affected stream.

0-RTT connection resumption

When a QUIC client reconnects to a server it has previously connected to, it can send application data in the very first packet — zero additional round trips. The client uses a session ticket (a cryptographic token) from the previous connection to derive encryption keys without a fresh handshake. The server can begin processing the request before completing key exchange. This 0-RTT mode has a security caveat: the data in the first packet is not protected against replay attacks (an attacker could retransmit it). For this reason, 0-RTT is typically restricted to safe, idempotent requests like GET — not state-changing operations like POST.

Connection migration

TCP identifies a connection by its 4-tuple: source IP, source port, destination IP, destination port. If your phone switches from Wi-Fi to mobile data (changing your IP), the TCP connection breaks and must be re-established. QUIC identifies connections by a Connection ID — an arbitrary number agreed at handshake. When your IP changes, QUIC sends a PATH_CHALLENGE on the new path and continues the same connection without interruption. This is particularly valuable for mobile users who frequently switch between networks.

QUIC encryption is always on

Unlike TCP, which can carry unencrypted application data, all QUIC payload is encrypted. QUIC integrates TLS 1.3 directly into its handshake — there is no plaintext QUIC. Even QUIC's own transport-layer headers (beyond the very minimal unencrypted portion needed for routing) are encrypted. This prevents middleboxes from inspecting or modifying QUIC stream data, which is a deliberate design choice to avoid the ossification problem described below.

Middlebox ossification

TCP's long history means billions of network devices — firewalls, load balancers, transparent proxies, WAN optimisers — have been programmed with assumptions about TCP behaviour. Many of these devices modify TCP headers, insert data, or block connections exhibiting unexpected TCP options. This "ossification" made evolving TCP nearly impossible. QUIC's designers deliberately encrypted as much as possible to prevent middleboxes from making assumptions about QUIC's internals. The trade-off is that some middleboxes block or rate-limit QUIC's UDP traffic, requiring fallback to TCP. Studies have shown QUIC is blocked or degraded in 5–10% of network paths, primarily in enterprise environments and some mobile carrier networks.

Frequently Asked Questions

Why is QUIC faster than TCP+TLS?

TCP + TLS 1.3 requires 2 round trips before data flows. QUIC combines transport and crypto handshakes into 1-RTT, and uses 0-RTT for returning connections — data starts flowing in the very first packet using a cached session ticket from the prior connection.

What is head-of-line blocking and how does QUIC fix it?

In TCP, a lost packet stalls all subsequent data — even unrelated requests. QUIC's independent per-stream multiplexing means a lost packet blocks only its own stream; all other streams continue unaffected. This matters most for web pages loading many resources in parallel.

Does QUIC work through all firewalls?

No. Some firewalls block UDP port 443. When blocked, HTTP/3 clients fall back to HTTP/2 over TCP automatically. You can verify QUIC usage in browser DevTools Network tab — look for "h3" in the protocol column.