TCP Ruled for 40 Years. Why Did HTTP/3 “Dump” It?

TL;DR

Let’s fact-check the title first: TCP has not been abandoned — file downloads, video, email, and SSH still run on it today. But the Web really did change drivers: in June 2022, HTTP/3 became an official standard (RFC 9114), and it no longer uses TCP — web traffic is handed to QUIC, running over UDP.

TCP got “replaced” because of three incurable midlife conditions:

1. Head-of-line blocking: TCP is a byte stream that must be delivered in order — lose one parcel, and every parcel behind it stands at attention;
2. Expensive handshakes: before any data flows, 2-3 round trips of “small talk” (TCP handshake + TLS handshake) — half a second gone on intercontinental links;
3. A protocol welded shut: TCP lives inside the OS kernel, and middleboxes only recognize the “classic model” — improving it is nearly impossible.

QUIC’s fix is beautifully blunt: rebuild all of TCP’s wisdom on top of UDP, where nobody interferes. This is the finale of our networking trilogy — part one covered how to use the network, part two why TCP/IP was designed so well, and this one how even the mighty TCP got replaced by its own heirs. All screenshots come from real systems; IPs and hostnames are masked.

Figure 1: The Web changed drivers. The new driver is QUIC; the chassis is still the same one (UDP).

1. The Day the Web Changed Drivers

In June 2022, the IETF published RFC 9114, and HTTP/3 became an official standard. A notable day in Internet history: for the first time since the Web was born in 1991, web traffic no longer depends on TCP.

The story started earlier: in 2012, Google engineers, fed up with TCP’s limits, built an experiment called gQUIC (Quick UDP Internet Connections) and quietly shipped it in Chrome and their own servers. After nearly a decade of real-world validation, they handed it to the IETF — the result was QUIC (RFC 9000, 2021). The combination “HTTP over QUIC” was named HTTP/3.

This is no paper standard — it’s deployed in production. Here’s a real DNS query I ran against Cloudflare (asking for a newer record type called HTTPS, which sites use to advertise which protocols they speak):

Figure 2: A real query. alpn="h3,h2" means: “I speak HTTP/3 (h3) and HTTP/2 (h2) — your pick.” Note h3 is listed first: HTTP/3 is already the preferred protocol at major providers.

So what was worth replacing a 40-year incumbent for? Three midlife conditions — each harder to cure than the last.

2. Condition 1: Head-of-Line Blocking — One Parcel Detained, Everyone Waits

TCP’s essence is a single ordered byte stream. Picture a single-lane toll booth on a highway: parcels must pass in numbered order, and if parcel #3 gets lost on the way, parcels #4, #5, #6… must all wait in line — even if they already arrived — until #3 is retransmitted. That’s head-of-line (HOL) blocking.

You might say packet loss isn’t an everyday thing. Sorry — it literally is. Real TCP statistics from my server:

Figure 3: Real netstat -s output. Of 16.65 million segments sent, 52,981 had to be retransmitted — roughly 1 in every 300+ parcels needs a resend. Every resend is a full-queue standstill.

HOL blocking used to be one connection’s private problem. But in 2015, HTTP/2 did something that backfired: multiplexing — a single TCP connection between browser and server carries dozens of requests (HTML, CSS, images, JS) as dozens of “streams,” interleaved on the wire.

Real HTTP/2 connection logs from my machine — note every stream has its own ID:

Figure 4: Real curl -v output. [HTTP/2] [1] OPENED stream — the request goes into stream number 1. Multiplexing did cure application-layer HOL blocking (requests no longer queue), but underneath, it’s still the same single TCP.

See the problem? HTTP/2 strapped dozens of streams onto one TCP lane. Before, one lost packet stalled one stream; now one lost packet stalls dozens of streams at once — images, styles, and scripts on the page all freeze together. The more successful the multiplexing, the more painful the blocking.

Figure 5: Left (TCP): parcel #3 is lost; every stream waits for its retransmission. Right (QUIC): streams are independent; only the owning stream waits.

3. Condition 2: Expensive Handshakes — Half a Second of Small Talk Before Business

TCP is a phone call, and phone calls start with dialing. Before any data flows:

1. TCP three-way handshake: 1 round trip (RTT) — “hello, can you hear me?” (covered in part one);
2. TLS handshake: another 1-2 round trips — “let’s agree on a cipher, then talk privately.”

So before the browser sends its first real request, it waits 2-3 network round trips doing nothing else. On a same-city link (a few ms), who cares; on intercontinental fiber or mobile networks, one round trip is 100-300 ms — half a second burned on pleasantries alone.

Not theory — real measurements from my machine:

Figure 6: Real curl timing. TCP connected at 279 ms (first round trip), TLS agreed at 573 ms (second round trip) — 0.57 seconds of pure greeting before the first data byte.

How many pleasantries does a TLS handshake actually take? Also measured:

Figure 7: Real curl -v output. Client hello → Server hello → Certificate (show me your papers) → Key exchange… a whole etiquette ritual before business begins.

The TCP community tried to fix this long ago — “TCP Fast Open” sends data during the handshake. The result? Hardly anyone dares enable it — because it requires changing TCP itself, which brings us to the third, most hopeless condition.

4. Condition 3: A Protocol Welded Shut — Want to Fix TCP? Replace Every OS on Earth

The deadliest condition of all: TCP can no longer be improved.

Two reasons:

• TCP lives in the operating system kernel. Upgrading TCP means upgrading billions of Windows, macOS, Linux, Android devices and router firmwares — a multi-decade project at best;
• Middleboxes have welded TCP in place. Your packets traverse countless NATs, firewalls, and carrier appliances. These “middleboxes” only recognize classic TCP. Use a TCP extension they’ve never seen (Fast Open, multipath MPTCP), and your packet gets dropped as a suspicious character. Protocol researchers have a name for this: ossification.

Figure 8: Middleboxes (firewalls, NATs, carrier appliances) only recognize classic TCP. The moment a packet looks different, they drop it. TCP is effectively welded shut from both sides.

Remember “we believe in running code” from part two? TCP no longer gets to run new code — it is locked in by its own success.

So QUIC’s designers reached a conclusion that sounds like giving up but is actually genius: if TCP can’t be changed, don’t change it — rebuild TCP’s wisdom on top of UDP, where nobody interferes.

Why UDP? Because middleboxes mostly leave UDP alone (legacy services like DNS depend on it), making UDP the last free channel on the Internet. Inside this “unfinished loft” called UDP, QUIC re-implements reliable delivery, retransmission, congestion control, and flow control — every one of TCP’s signature skills, but now as code that ships with the app, changeable at will.

5. QUIC’s Four Trump Cards

Trump 1: Independent streams — the HOL cure. QUIC natively multiplexes independent streams over UDP, with retransmission and ordering tracked per stream — parcel #3 lost? Only its own stream waits; the rest flow on (right half of Figure 5). The multiplexing HTTP/2 dreamed of is finally real.

Trump 2: Encryption built into the handshake — the cost cure. QUIC welds TLS 1.3 directly into its own handshake: for a new friend, 1 round trip and data flows (versus 2-3 for TCP+TLS); for a returning friend, even 0-RTT — the very first packet already carries data. Not a single pleasantry wasted.

Figure 9: Left (TCP): dial (1 RTT) + agree on cipher (1-2 RTT) — business starts on trip 3. Right (QUIC): the cipher is embedded in the dial; old friends start talking business immediately.

Trump 3: Connection IDs — the cure for dropped calls on the go. TCP identifies a connection by four values — both IPs and both ports. Walk from your living room to the street, and as WiFi hands over to 5G (part one covered these two networks), your IP changes and every TCP connection dies. QUIC ignores IPs: it issues each connection a badge (Connection ID). Switch networks all you like — as long as the badge holds, the video call and the download continue.

Figure 10: Carrying the same badge (Connection ID) from WiFi to 5G — to QUIC, you’re still you.

Trump 4: User-space and fully encrypted — the ossification cure. QUIC ships as ordinary code inside the app (Chrome updates, QUIC updates) — no waiting for OS upgrades. And it goes further: nearly everything, packet headers included, is encrypted. Middleboxes see nothing but “a UDP packet,” so there’s nothing for them to meddle with. You love ossifying things? Fine — you get to see nothing.

Figure 11: Left (TCP): lives in the kernel, upgrades require OS swaps, headers in cleartext for middleboxes to inspect and police. Right (QUIC): travels with the app, upgrades anytime, encrypted end to end — middleboxes can only stare.

6. Has TCP Really Been Abandoned?

No — far from it. On today’s Internet:

• Big downloads, video on demand, email, databases, SSH, API calls — the vast majority of traffic still runs on TCP;
• HTTP/3 is, for now, an optimization for the specific scenario of web browsing — many short connections, latency-sensitive, often on flaky networks;
• QUIC has its own headaches: running in user space means higher CPU costs (TCP enjoys decades of kernel tuning and NIC hardware offload); some carriers inexplicably throttle UDP; and its congestion-control algorithms are, for now, largely copied from TCP’s homework.

The accurate statement is: TCP hasn’t been eliminated — it has, for the first time, met someone who can take the baton. On the Web track, a better-suited runner has taken the field; TCP remains the load-bearing pillar of the whole Internet.

7. The Most Interesting Ending: Not Rebellion — Inheritance

If you read part two of this series (TCP/IP’s design philosophies), the HTTP/3 story reads like a graduation exam for those six principles:

• The end-to-end principle: QUIC was invented at the “edge” (Google’s own browser and servers) without touching a single router — innovation happened at the edge, again;
• The hourglass’s empty space: UDP, that “uselessly thin” layer of 40 years ago, became the runway for a new protocol — the room left for the future got used, for real;
• Running code: gQUIC ran in production for nearly a decade before becoming an RFC — the same old family tradition of “make it run, then standardize.”

TCP didn’t lose. It simply passed the baton of “keep evolving” into QUIC’s hands — and every move QUIC learned to walk with, it learned from TCP.

Q&A

Q1: Is my browser using HTTP/3 right now? Very likely. Chrome, Edge, Firefox, and Safari all support HTTP/3 by default, and Google, Cloudflare, Meta, Bilibili, and many others have it enabled — check your favorite sites with the method from Figure 2 and look for alpn="h3".

Q2: Why not invent a brand-new transport protocol instead of hiding inside UDP? Because middleboxes drop protocols they don’t recognize — SCTP, technically superior to TCP, starved exactly this way. Wrapping up in UDP is “dressing like a regular person”: survive first, then chase ideals.

Q3: Is 0-RTT safe? There’s a “replay attack” caveat: an attacker can re-send your first packet verbatim. So 0-RTT suits idempotent queries only; anything like a transfer must wait for the full handshake — QUIC leaves that gate for the application to guard.

Q4: Will HTTP/3 make my home Internet faster? Depends: on a good, low-latency network you’ll barely notice; but on the subway, in an elevator, on intercontinental links, or in a weak-signal corner (high latency, lossy), the improvement is very visible — which is exactly what it was invented for.

Q5: With HTTP/3 out, is it still worth learning TCP? More than ever. Every QUIC feature is the standard answer to some TCP problem — without understanding TCP’s head-of-line blocking, handshake costs, and kernel ossification, QUIC’s design will never make sense to you.

From an eight-page paper in 1974 to HTTP/3 in 2022 — 48 years apart. TCP’s story tells us: a truly great design is not one that can never be surpassed, but one whose rules of the game even its successors must obey.