Networking

QUIC

QUIC's existence looks like a contradiction at first: it's a reliable, ordered transport — exactly what TCP already provides — built on top of UDP, the protocol with no reliability at all. It isn't a contradiction; it's reliability rebuilt from scratch, in software, specifically to avoid a few structural costs that are baked into TCP itself and can't be fixed without replacing it.

The problem QUIC exists to fix

A modern web page isn't one request — it's dozens, fetched over the same TCP connection to avoid paying for a new handshake every time. That reuse is good, but it creates a new problem: TCP delivers bytes to the application strictly in the order they were sent, across the entire connection, even when those bytes belong to completely unrelated requests.

Head-of-line blocking

If a packet carrying part of request #1 is lost, TCP holds up everything behind it — including already-arrived data for requests #2 through #10 — until the lost packet is retransmitted and its place in the sequence is filled. The application can't see request #2's data yet, even though it's sitting right there in the OS's receive buffer, purely because TCP won't hand over anything out of order.

Independent streams, one connection

QUIC solves this by multiplexing multiple independent streams inside one QUIC connection, each with its own ordering guarantee. A lost packet only blocks the one stream it belonged to — every other stream keeps delivering data to the application the instant it arrives. This is the single biggest practical difference from TCP, and the reason QUIC was built as a new protocol instead of a patch to TCP: stream-level ordering isn't something you can retrofit onto a byte-stream protocol without breaking compatibility with every existing TCP implementation.

Faster handshake — and built-in encryption

Plain TCP needs one round trip before TLS even starts its own handshake on top — two separate negotiations, stacked. QUIC folds transport and encryption setup into a single handshake, because QUIC is encrypted by design; there's no such thing as unencrypted QUIC in practice. A returning client that has talked to a server recently can often skip the round trip entirely (0-RTT), sending encrypted application data in its very first packet.

Why build this on UDP instead of just fixing TCP

TCP is implemented deep inside operating system kernels, and middleboxes across the internet (firewalls, NAT gateways, corporate proxies) have decades of hard-coded assumptions about what a TCP segment looks like. Changing TCP's core behavior would mean waiting for every OS and every piece of middlebox hardware on the internet to update — effectively never. UDP, by contrast, is deliberately minimal — the network mostly just forwards UDP datagrams as opaque payloads. Building the new reliability logic inside that payload, as ordinary application-layer software, means QUIC can evolve at the pace of a library update instead of an operating-system release cycle.

Real-world applications

• HTTP/3 — the latest HTTP version runs entirely over QUIC instead of TCP; most major browsers and CDNs (Google, Cloudflare, Meta) support it today.
• Mobile web browsing — QUIC's connection migration (a connection survives switching from Wi-Fi to cellular, since it's identified by a connection ID rather than an IP/port tuple) avoids the dropped-connection stall TCP suffers on a network change.
• Video conferencing and gaming platforms — some latency-sensitive platforms have adopted QUIC-based transports for the same head-of-line-blocking reasons that push simpler cases straight to UDP.

Gotchas