TCP on Margrop Blog

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

Sat, 18 Jul 2026 19:40:00 +0800

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:

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;

Expensive handshakes: before any data flows, 2-3 round trips of “small talk” (TCP handshake + TLS handshake) — half a second gone on intercontinental links;

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.

A 1974 Design Still Rules the Internet. Why? The 6 Design Philosophies of TCP/IP

Sat, 18 Jul 2026 09:30:00 +0800

TL;DR

TCP/IP is almost 50 years old. Every one of its rivals — the phone companies’ X.25, IBM’s SNA, the standards body’s OSI — is in a museum, yet it still carries every page you load today. It didn’t win by being the most advanced. It won through six design choices:

Packet switching: no private trains — everyone shares the highway. Cheap, and hard to kill;

Layering: each layer does one job and can be swapped out like a LEGO brick;

The end-to-end principle: keep the network dumb and put the smarts at the edges — so innovation never requires rewiring the network;

Best effort: the core promises nothing, reliability is bought à la carte — simple scales globally;

Rough consensus and running code: no kings, no voting — standards grow by working, not by decree;

Room for the future: from IPv4 to IPv6, from HTTP/1 to HTTP/3 — the foundation stays while everything above is rebuilt.

One sentence: good design doesn’t predict the future; it leaves room for it. This is the companion piece to Why Is Your WiFi Lagging? — that article explained what the network is and how to use it; this one explains why it was designed this way and how it survived half a century. All screenshots come from real systems and real protocol documents; IPs and hostnames are masked.

Why Is Your WiFi Lagging? Networks, TCP vs UDP, and the Two “5Gs” — Explained So a Kid Gets It

Sat, 18 Jul 2026 08:30:00 +0800

TL;DR

A network is a delivery service for computers: data is chopped into “parcels” (packets), labeled with “addresses” (IPs), and relayed by “sorting centers” (routers) hop by hop to the recipient.

TCP is a phone call: connect first, talk later, repeat anything that wasn’t heard — reliable but fussy. UDP is a postcard: drop it in the mailbox and hope — fast, but no delivery guarantee. Live video and games prefer UDP; files and web pages prefer TCP.

The three-way handshake is just the opening of a phone call: “Hello, can you hear me?” — “I can. Can you hear me?” — “I can too. Let’s talk.”

Wired is a private water pipe; WiFi is shouting in a crowded square — when everyone shouts at once, nobody is heard clearly. That is the number-one reason WiFi lags.

WiFi’s “5G” means the 5GHz frequency band (a wider lane). Your phone carrier’s “5G” means the 5th generation of mobile networks (a whole standard). They share a name and nothing else.

No jargon without an everyday analogy, but every number below comes from real measurements on real machines (all IPs and hostnames are masked). A kid can follow most of it; an adult won’t find it shallow.

Cross-Border VPS Feels Glacial? One Kernel Sysctl Speeds International Links 20×

Thu, 02 Jul 2026 20:00:00 +0800

The short version

You’re accessing your overseas VPS from within China. SSH feels snappy. curl on a small JSON endpoint returns instantly. But downloading a 2 MB HTML file takes over a minute. Convinced it’s “peak-hour international link congestion”? Probably not — you’re being sabotaged by Linux’s default CUBIC congestion control. CUBIC treats every packet loss as “the road ahead is jammed” and immediately backs off. But international links have baseline 5–15% loss from physical-layer imperfections, not congestion. So your TCP flow gets permanently stuck in slow-mo. Switch to Google’s BBR algorithm and the exact same physical path, same moment, same loss rate delivers 15–24× more throughput.

This post walks through a real mesh-VPN investigation: pulling a 2.3 MB page from a US VPS across a Chinese home connection went from 30 KB/s to 500–1000 KB/s after four shell commands. It ships three one-shot scripts (Windows 11 / Ubuntu 26.04 / macOS 26), covering both manual execution and AI-agent-driven deployment. All internal IPs, hostnames, and public IPs have been redacted.