A 1974 Design Still Rules the Internet. Why? The 6 Design Philosophies of TCP/IP
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.
Figure 1: A design from 1974, still carrying the world’s traffic.
1. Opening: The 50-Year-Old Grandpa and the Rivals It Buried
In May 1974, the IEEE Transactions on Communications published an eight-page paper — “A Protocol for Packet Network Intercommunication” — by Vint Cerf and Bob Kahn. It described a way to connect many different networks into a “network of networks.” That was the beginning of TCP/IP.
Figure 2: Vint Cerf, co-designer of TCP/IP, later called one of the “fathers of the Internet.” (Photo: Veni Markovski, CC BY 3.0, via Wikimedia Commons)
On January 1, 1983, the ARPANET — the Internet’s predecessor — did something unprecedented: the entire network switched off its old protocol (NCP) and moved to TCP/IP on a single day. It became known as “Flag Day” — like a whole country re-gauging its railways overnight. From that day on, TCP/IP took the throne. It has never left.
You’d think a half-century-old technology would be retired by now. Instead — its rivals all died, and it lived:
- The phone companies’ X.25 (1970s): dead;
- IBM’s SNA (aristocrat of the mainframe era): dead;
- The OSI seven-layer model, painstakingly designed by the international standards body (the “official standard” of the 1980s): survives only as a textbook chapter;
- The carriers’ darling ATM: dead.
And TCP/IP’s own birth certificate — RFC 791, published September 1981 — remains, word for word, the law of the Internet. I pulled it from the RFC site; the letterhead looks like this:
Figure 3: The real RFC 791 front page. “INTERNET PROTOCOL, September 1981” — this 45-year-old document defines the IP you are using right now.
Figure 4: The ARPANET of the 1970s — the Internet’s childhood. A handful of university and research nodes was “the whole world” back then.
Myth-busting: many articles claim “ARPANET was designed to survive a nuclear war.” That’s the Internet’s most persistent legend. ARPANET’s real goal was resource sharing — letting researchers share expensive computers. But the idea that “the network should keep working even when pieces are blown away” did exist, coming from Paul Baran’s contemporary research on survivable networks — and it did merge into the Internet’s DNA.
So here’s the question: X.25 was more rigorous, OSI was more “standard,” ATM was fancier — why did the seemingly rough-and-ready TCP/IP win? The answer isn’t in technical specs. It’s in six design philosophies.
2. Philosophy 1: Packet Switching — No Private Trains, Share the Highway
Before TCP/IP, the patriarch of communications was the telephone network, built on circuit switching: when you make a call, the exchange lays a “private railway” from your mouth to the other person’s ear. For the whole call, nobody else may use an inch of it — even when neither of you is speaking, the railway idles.
TCP/IP chose the other road: packet switching. Chop data into small parcels, label them with addresses, and toss them into a shared highway system; each parcel finds its own way and the parcels are reassembled at the far end. A courier company doesn’t dispatch a dedicated train for your box — it shares one train with thousands of other people’s boxes.
Figure 5: Left — circuit switching: a private train that must be fed even when running empty. Right — packet switching: a shared highway, parcels ride together, and if a road breaks, take another.
Two decisive benefits came from this choice:
- Cheap: shared lines run at high utilization, so connectivity became affordable for everyone;
- Survivable: if a sorting center dies, parcels detour around it — the network is resilient by birth.
The costs: sharing means congestion; packets get lost, delayed, reordered. Every philosophy that follows is, in a sense, an ingenious way of cleaning up after packet switching.
3. Philosophy 2: Layering — LEGO Bricks You Can Swap
The previous article explained TCP/IP’s four-layer delivery pipeline. Here we ask one step deeper: why layer at all?
Because layering gives every layer the freedom to be replaced independently. Like LEGO: every brick snaps into standard studs, so you can swap a bottom brick without touching the castle on top.
Fifty years of evidence:
- The link layer went from phone lines and coax to fiber, WiFi, 4G/5G, and Starlink — reinvented over and over;
- The application layer went from Telnet and FTP to the Web, messaging super-apps, and short video — unrecognizable;
- And the IP layer in the middle barely moved.
IP stayed stable because its self-assigned job is so restrained: it reads only protocol numbers and addresses, and never cares what’s inside the parcel. Your operating system still keeps this “protocol number registry” today:
Figure 6: A real /etc/protocols file. ICMP is 1, TCP is 6, UDP is 17… IP forwards by number and doesn’t care about contents. Any future protocol can join the Internet by claiming a new number.
That’s the power of layering: the bottom can revolt without the top noticing; the top can innovate without the bottom moving.
4. Philosophy 3: The End-to-End Principle — Dumb Network, Smart Edges
This is the most central, and most counter-intuitive, philosophy of all.
In 1981, three MIT researchers — Saltzer, Reed, and Clark — published “End-to-End Arguments in System Design,” stating it bluntly: if a function can only be implemented completely and correctly with the knowledge of the communicating end points, then don’t build it into the middle of the network.
Think of the postal service: the post office delivers your letter and never opens it — love letter or contract, it can’t read it and shouldn’t. Checking “was this letter tampered with?” can only be done by the recipient (say, verifying the signature); the post office can’t do it for you.
So TCP/IP made an astonishing decision: keep the network deliberately dumb. Routers do exactly one thing — read the address, forward the parcel. Whether parcels were lost, arrived in order, or stayed confidential is the end computers’ problem.
Figure 7: The end-to-end principle. The clever work (reliability, encryption, application logic) lives at the ends; the network in the middle does one thing only: carry.
The whole Internet thereby took the shape of the famous hourglass model:
Figure 8: The hourglass. Applications above are infinite, link technologies below are infinite, but everyone must pass through the narrow waist — IP. The thinner the waist, the more stable the system.
The waist is IP: the one universal language every device on Earth must speak; above and below it, anything goes.
What did the dumb network buy? Permissionless innovation. The Web was invented in 1989 by Tim Berners-Lee at a research lab — he didn’t need to reprogram a single router or ask anyone’s approval, because the network only moves bytes. P2P downloads, video calls, Bitcoin… all were “inventions at the edge,” and the network never changed a byte. Compare the telephone network: want a new phone feature? Upgrade every switch on the planet first. That is the difference in destiny between a smart network and a dumb one.
Even TCP itself evolves by negotiation rather than by rewriting the standard. In this real capture, two strangers exchange capabilities while shaking hands:
Figure 9: A real capture. Via the options field, both sides advertise abilities: mss (maximum parcel size), sackOK (selective acknowledgment), TS (timestamps), wscale (window scaling). These were all grafted onto TCP years after its birth — old protocols upgrade by negotiating, not by being rewritten.
5. Philosophy 4: Best Effort — Put Reliability in the Right Place
Right after end-to-end comes an even thriftier decision: the IP layer promises only “best effort.”
IP never says “I will deliver.” It says “I’ll try.” Parcels may be lost, late, duplicated, reordered — want guaranteed delivery? Turn right and use TCP, or handle it in your application.
It sounds like cutting corners; it’s actually a shrewd allocation of responsibility, exactly like the postal service:
- Regular mail: cheap and fast, no compensation if lost — for postcards (UDP, video calls, live streams);
- Insured express: signed delivery, guaranteed compensation, but pricey and ceremonial — for important documents (TCP, web pages, bank transfers).
The key insight: not everyone is willing to pay for absolute reliability. If every parcel were insured, mailing a postcard would be a luxury; if the network gave every flow TCP-grade guarantees, video calls would stutter to death waiting for retransmissions (we covered this in the previous article).
“Best effort” hides another dividend: routers can stay dumb and fast. No bookkeeping, no tracking each parcel’s fate — read, forward, done. Precisely because each device is simple, the network could grow from 4 nodes to billions. Simplicity scales; scale made the Internet.
6. Philosophy 5: Rough Consensus and Running Code — Standards Aren’t Voted In
Beyond technology, TCP/IP also won on culture.
At a 1992 meeting of the Internet Engineering Task Force (IETF), David Clark said the famous words:
“We reject: kings, presidents and voting. We believe in: rough consensus and running code.”
TCP/IP’s standards were never decreed by an authority. Its standards documents are called RFCs — Requests for Comments. Even the name is humble: here’s my draft, everyone please critique; when opinions converge and code actually runs, it becomes the standard.
The control group was OSI: national delegates, committees, meeting rooms — a decade spent designing the “perfect” standard, by the time the documents were done, the world had already been claimed by the “run-and-fix” TCP/IP. Perfect blueprints lost to running code.
This culture had a soul figure, Jon Postel, whose “Robustness Principle” — written into RFC 793 — is remembered as Postel’s Law:
Figure 10: Postel’s Law — “be conservative in what you send, be liberal in what you accept.” Send impeccably; interpret others’ imperfect packets generously. That’s how billions of implementations that never met each other manage to talk.
Strict with yourself, lenient with others — eight words that let thousands of vendors and tens of thousands of implementations assemble a working Internet with no central coordinator.
And the culture still operates today. Here is a real HTTPS connection negotiation from my machine:
Figure 11: A real capture. The client says “I speak h2 and http/1.1” (ALPN: curl offers); the server answers “then h2 it is” (server accepted h2). Protocol versions are negotiated between ends, not commanded — the Internet of 2026 still works the way it did in 1992.
A critical footnote: Postel’s Law has a cost. “Excessive tolerance” breeds buggy implementations into de-facto standards and can hide vulnerabilities in security contexts — the newer QUIC protocol deliberately chose strictness. See? Even the philosophy keeps evolving.
7. Philosophy 6: Room for the Future — the Foundation Stays, the Floors Get Rebuilt
The final philosophy decides whether a design can live long: evolvability.
To be fair, TCP/IP’s designers had no crystal ball. IPv4 uses 32-bit addresses — about 4.3 billion, which seemed “infinite” in the 1970s when only a few hundred computers existed. Then, in 2011, the addresses really ran out. A design flaw? Arguably. What’s remarkable is how the system digested the flaw:
- NAT (Network Address Translation) bought time: a whole household of devices shares one public address, like an apartment building sharing one switchboard — a compromise that genuinely wounded the end-to-end purity, but kept the Internet running smoothly for another decade-plus;
- Meanwhile IPv6 takes over: 128-bit addresses, enough to number every grain of sand on Earth. And the transition is gradual — two generations run side by side; nobody has to “re-gauge the rails overnight.”
Today’s Internet is a dual-stack world. Real DNS answers from my machine:
Figure 12: Real DNS resolution. One domain returns both an IPv4 address (104.x.x.x) and an IPv6 address (2606:xxxx::xxxx) — two protocol generations on duty together, and users never notice.
Look at the application layer’s revolutions: HTTP/1.1 (1997) → HTTP/2 (2015) → HTTP/3 (2022 — which abandoned TCP entirely and rebuilt itself as QUIC over UDP). Web transport changed three times in 25 years, while the IP underneath is still the 1981 IP.
Figure 13: Fifty years of evolution. The foundation (IP) barely moved while the floors above were rebuilt again and again — the reward of leaving room for the future.
Good design isn’t getting everything right once; it’s staying fixable. Every “simplicity” and every “blank space” TCP/IP left in 1974 became a runway for those who came later.
8. The Costs: Greatness Isn’t Perfection
Calling TCP/IP a “perfect design” would be dishonest. The debts it ran up are still being paid:
- Security was bolted on later. The designers assumed “everyone online is one of us”; encryption (TLS) and secure tunnels (IPsec) are all after-market patches — the Internet opened to traffic before installing traffic lights;
- NAT broke end-to-end. Your phone and laptop have no “global street address,” making direct peer-to-peer connections hard — idealism bowed to reality;
- No QoS. “Best effort” means no latency guarantees; congestion control (slow start, congestion avoidance) was emergency surgery after the great congestion collapses of 1986;
- IPv6 has been “rolling out” for over 20 years. If changing just the “waist” is this hard, it also proves how vital — and how irreplaceable — that waist is.
But notice what these criticisms share: each one ends up proving the value of the six philosophies — security can be patched at the edges (end-to-end), NAT nests inside layering (layering), congestion control can be added later (running code), IPv6 can transition gradually (evolvability). A design’s greatness isn’t measured by whether it errs, but by whether it can still move after erring.
9. Closing: Leave Room for the Future
Back to the opening question: why does a 1974 design still rule the Internet?
Because from day one it never tried to predict the future. It assumed nothing about cables (layering), nothing about applications (end-to-end), nothing about who’s in charge (rough consensus), nothing about unchanging needs (best effort + evolvability). It’s a house where only the foundation and load-bearing walls were built — the rooms inside were left for the future to partition.
Next time some “revolutionary technology” claims it will replace everything about the Internet, ask three questions first: Is it layered? Does it keep the smarts at the edges? Does it leave room for applications not yet invented? That is what TCP/IP taught us in half a century.
Q&A
Q1: The OSI seven-layer model was more “scientific” and more “standard” — why did it lose? On timing and method: OSI was committee-designed, aiming for a one-shot, all-encompassing standard; by the time the documents were finished, implementations were scarce. TCP/IP coded first and standardized as it ran; when OSI woke up, the ecosystem was taken. OSI didn’t lose everything, though — its seven-layer teaching model remains a great scaffold for explaining networking (our previous article’s layering diagram borrows from it).
Q2: Will TCP/IP be replaced? Not in the foreseeable future. Its biggest self-replacement ever was IPv4→IPv6, and 20+ years later it’s still in progress — if merely “changing the waist” is this hard, a wholesale overthrow has no realistic path. The likelier script: it keeps evolving by its own philosophy (exactly what QUIC/HTTP/3 did).
Q3: Why is the hourglass “waist” (IP) so important? It’s the only universal language the whole planet must speak. A thin waist is what gives freedom to the applications above and the links below. Replacing the waist (e.g., moving to IPv6) means the entire world relearning how to talk — hence the decades-long rollout.
Q4: Do 5G and Starlink still use TCP/IP? Entirely — and that’s layering’s victory. 5G and Starlink replace the link layer (how bits get beamed around); they’re completely transparent to IP and the layers above. Browsing over Starlink, you’re running the 1981 IP.
Q5: If a kid can only remember three sentences, which three? ① Layers mind their own business, so bricks can be swapped (layering); ② Keep the network dumb and the ends smart (end-to-end); ③ Running code beats perfect blueprints (rough consensus).
At the end of that eight-page paper in 1974, Cerf and Kahn probably didn’t realize they hadn’t written a protocol — they had written a way for the world to grow by itself. Fifty years on, the world is still using it. And by the looks of it, will be for a long while yet.