Why you cannot just fix TCP
By now you know the transport layer intimately: the three-way handshake that syncs sequence numbers, the sliding window, congestion control as a careful driver speeding up gently and braking hard, and the head-of-line blocking you met when streams share one TCP pipe. So here is a fair question. If TCP has known flaws, why not just improve TCP? The answer is one of the most important practical lessons in all of networking, and it has almost nothing to do with cleverness.
TCP lives in the operating system kernel, and it is implemented by the routers, firewalls, and home gateways scattered across the entire Internet. Many of those boxes — collectively called middleboxes — peek inside TCP headers and quietly rewrite or drop anything that does not look like the TCP they were programmed to expect, years ago. So a brand-new TCP option often gets stripped or breaks the connection. This calcification is called protocol ossification: the protocol is frozen in place not by its designers but by the millions of devices that have hard-coded assumptions about it.
There is a second reason. Because TCP lives in the kernel, upgrading it means upgrading billions of operating systems — phones, servers, embedded gadgets — and waiting years for everyone to reboot into the new version. The web could not wait. So the designers of QUIC made two radical choices at once: build the new transport over UDP so middleboxes leave it alone, and run it in user space, inside the application, so it can ship and update as fast as a browser does.
UDP as a blank slate, not a lesser TCP
It is tempting to think QUIC chose UDP because UDP is simpler or weaker. Not so. Remember that UDP is a deliberate choice, not a broken TCP — it offers bare best-effort datagrams with ports and a checksum, and crucially imposes no ordering, no retransmission, no congestion control of its own. To QUIC, that emptiness is the whole point. UDP is treated as a thin, well-understood envelope that middleboxes already forward without inspecting, leaving QUIC free to build whatever it wants inside.
Inside that UDP envelope, QUIC rebuilds, in user-space code, everything TCP gives you and a couple of things it never could: reliable delivery with acknowledgments and retransmission, congestion control, flow control, and — built in from the start, not bolted on — encryption. And it carries not one ordered byte stream but many independent streams, each with its own ordering, so a loss on one stream no longer freezes the others. That is the cure for the head-of-line blocking you traced in the transport rung.
Connecting in one round trip — or zero
Here is where QUIC really shines, and it comes down to round trips. Recall that a round-trip time (RTT) is one full there-and-back journey, and that you cannot beat the speed of light — more bandwidth never shortens an RTT. So the number of round trips before useful data flows is pure, unavoidable latency. With classic TCP plus TLS, you pay the TCP handshake (SYN, SYN-ACK, ACK) and then the TLS handshake on top, costing two or three round trips of waiting before the first byte of your web page can even start.
QUIC folds the transport handshake and the cryptographic handshake into one. Because reliability and encryption are designed together, a fresh QUIC connection is ready after a single round trip (1-RTT): the client's very first flight already begins negotiating keys, and the server's reply lets real data start. Better still, if you have talked to this server before, QUIC can remember a secret from last time and send encrypted application data in the very first packet — zero round trips of setup (0-RTT) — so the request leaves on the same flight that opens the connection.
Connection IDs: surviving a change of address
A TCP connection is named by four numbers: source IP, source port, destination IP, destination port. Change any one and the connection is, by definition, a different connection. This is exactly what happens when your phone hops from Wi-Fi to cellular — your IP address changes, so every TCP connection silently dies and your downloads stall while they reconnect. Remember that an IP address names a location or interface, not a device, so when the interface changes, the address changes with it.
QUIC fixes this by naming a connection with its own identifier — a connection ID — chosen by the endpoints and carried inside the QUIC packet, above the changeable IP and port. When your phone's address changes mid-download, the new packets still carry the same connection ID, so the server recognizes the connection and keeps going. This is called connection migration, and it is why a QUIC video can ride smoothly from your home Wi-Fi out to the street without a single stall.
TCP identifies a connection by the 4-tuple:
( srcIP , srcPort , dstIP , dstPort )
change Wi-Fi -> cellular => srcIP changes => connection is dead
QUIC identifies a connection by a Connection ID inside the packet:
[ UDP header | QUIC: ConnID=0xA17F | streams... | encrypted ]
change Wi-Fi -> cellular => srcIP changes => ConnID unchanged
=> same connection, keep goingHTTP/3, and the wider reinvention of transport
Stack all of this up and you get HTTP/3, which is simply HTTP carried over QUIC. The page-fetching logic you know is unchanged — same methods, same headers, same status codes — but the transport beneath it is now QUIC instead of TCP. So HTTP/3 gets per-stream multiplexing without head-of-line blocking, encryption that is never optional, 1-RTT or 0-RTT setup, and connections that survive a change of network. It is the same web, riding on a transport rebuilt from the ground up.
QUIC is the most visible reinvention, but it is not the only one. Multipath TCP takes a different angle: it lets a single connection spread its bytes across several paths at once — your phone using Wi-Fi and cellular together — for more throughput and a seamless fallback if one path dies, while still looking like ordinary TCP to the application. Further out, named-data networking questions an even deeper assumption: instead of addressing a host (where is it?), you request content by name (what do I want?), and any nearby cache that holds that named, signed chunk can answer. It is a research direction, not a deployed Internet, but it reframes what a network is even for.
What ties these together is a single hard-won realization. Transport is not sacred. TCP's reliable ordered byte stream was the right abstraction for terminals and file transfers in the 1980s; today's web wants many independent streams, built-in privacy, and mobility across networks. QUIC delivers exactly that, and it could only do so by stepping outside the kernel and outside TCP — proof that on the Internet, the place a protocol lives can matter as much as what it does.
Tracing one QUIC page load
Let us walk the whole thing once, end to end, for a returning visitor fetching a page over HTTP/3. Watch how few round trips it costs, and where the old blocking simply cannot happen anymore.
- The browser sends a QUIC packet over UDP that both negotiates encryption keys and, because it has visited before, carries the first HTTP request as 0-RTT data — zero setup round trips.
- The server replies on the same connection ID, confirming keys and opening several independent streams — one for the HTML, one for the script, one for the stylesheet — all multiplexed inside one QUIC connection.
- A packet carrying part of the image is lost; QUIC retransmits it, but only the image stream waits. The script and stylesheet streams keep flowing to the page, so there is no transport-level head-of-line blocking.
- Mid-load the user walks outside and the phone switches from Wi-Fi to cellular; the IP address changes, but the connection ID does not, so the connection migrates and the download never stalls.
- Every byte in every stream was encrypted the whole time, because QUIC bakes encryption into the transport — there is no unencrypted mode to forget to turn on.