The TCP/IP triumph, why the protocol you've never thought about runs the world
The TCP/IP triumph, why the protocol you've never thought about runs the world
Field note. TCP/IP won by accident as much as by design. Now every Minecraft join, Discord call, and modpack download depends on it. The 'why' is interesting.
In the 1970s and 1980s, there was a real competition for "which protocol stack will run the future networks." Major candidates included OSI (a comprehensive, formally-designed suite from international standards bodies), proprietary networks from IBM (SNA) and DEC (DECnet), and the upstart TCP/IP from ARPA.
TCP/IP won. The others mostly didn't. Why is one of the most important stories in computing history.
TCP/IP's rise
The candidates
OSI (Open Systems Interconnection). Designed by ISO and ITU. Comprehensive seven-layer model. The "officially correct" answer endorsed by governments and standards bodies worldwide. Slow to implement, complex, never quite shipped.
SNA (IBM's Systems Network Architecture). Powerful but proprietary. Worked great if you were all-IBM. Locked customers in.
DECnet (Digital Equipment Corporation's networking). Strong technical design, also proprietary. Worked great in DEC shops.
XNS (Xerox Network Systems). Influential design, used by Banyan VINES and several others. Always a minority.
TCP/IP (the ARPANET-rooted protocol). Open, free, designed by Vint Cerf and Bob Kahn (1974), implemented and refined throughout the 1970s.
Why most observers bet on OSI
OSI had the official backing:
- Designed in committee by international experts.
- Endorsed by ISO, ITU, and most national governments.
- The U.S. government's GOSIP (Government OSI Profile, 1990) was supposed to mandate OSI for federal agencies.
- European telecoms were committed to OSI.
- Academic textbooks treated OSI as the standard answer.
In the mid-1980s, if you asked an industry expert "what will run computer networks in 2000?", OSI was the modal answer.
What TCP/IP had
TCP/IP had different advantages:
- It actually worked. ARPANET ran on it. NSFNET ran on it. Real networks, real users, real applications.
- Free. The RFCs were public. Anyone could implement, no licenses needed.
- Simple enough to implement. A small team could write a TCP/IP stack. OSI required hundreds of person-years.
- Battle-tested. Years of real-world refinement, vs. OSI's theoretical perfection.
- Backed by Berkeley. BSD Unix included a TCP/IP stack starting in 1983, making it the default for the entire Unix world.
The disadvantages:
- No formal blessing from international standards bodies.
- "Just" a research protocol, not a "real" enterprise system.
- Lacked some features OSI offered in theory (formal X.400 directory services, etc.).
The cutover: January 1, 1983
ARPANET formally switched from NCP (its older protocol) to TCP/IP on January 1, 1983. This was a forced cutover; the old protocols stopped working. Sometimes called "flag day."
The transition required every host on ARPANET to be upgraded. Months of planning. Some hosts missed the deadline and were temporarily cut off.
After flag day, ARPANET was a TCP/IP network. Every other network connecting to it had to speak TCP/IP. The protocol's reach extended.
Berkeley Unix and the free stack
The biggest accelerant of TCP/IP's adoption: it shipped free in Unix.
The University of California, Berkeley's Computer Systems Research Group released BSD 4.2 Unix in 1983 with a complete TCP/IP stack. The stack was funded by DARPA, written largely by Bill Joy and team. It was good.
BSD Unix was widely used in universities and research institutions. By the mid-1980s, every Unix-using site had a free, working TCP/IP stack. Workstations from Sun, DEC, HP, Apollo, etc. all shipped with TCP/IP.
This was decisive. While OSI advocates were still designing implementations, TCP/IP was deployed everywhere Unix was deployed.
The OSI struggle
OSI advocates worked hard. ISO standardized layer after layer through the 1980s. Vendors built OSI products. Governments mandated OSI adoption.
What went wrong:
Over-engineering. OSI tried to specify everything formally, including alternatives at every layer. The result was complex, expensive to implement, and incompatible between vendors implementing different optional parts.
Slow committee process. Decisions took years. By the time a feature was standardized, the world had moved on.
Lack of working implementations. Universities and researchers couldn't easily get OSI software running. TCP/IP was on every workstation.
No clear win. OSI's theoretical superiority never translated to user-facing benefits. If anything, OSI products were slower and less reliable than TCP/IP equivalents.
Internet network effects. Once enough sites used TCP/IP, the cost of using anything else included "you can't reach the rest of the internet."
By 1990, OSI was visibly losing. By 1995, GOSIP requirements were quietly being relaxed. By 2000, OSI was a historical footnote in production networking.
What killed proprietary networks
SNA and DECnet had different problems:
Vendor lock-in. Customers came to resent being locked to one vendor's networking. Heterogeneous environments became normal.
Interconnection requirements. Even strong proprietary networks needed to connect to the wider world. Adding TCP/IP gateways became standard practice. Once you had TCP/IP gateways, why not just use TCP/IP everywhere?
Standards momentum. TCP/IP becoming the de-facto open standard meant vendors competed on TCP/IP performance and features. Proprietary protocols got less investment.
Internet boom. As the internet became prominent in the 1990s, "internet compatibility" became a critical purchase criterion. TCP/IP was the only real answer.
Both SNA and DECnet got TCP/IP gateways, then de-emphasized their proprietary stacks, then quietly phased them out. By the 2000s, they were legacy.
TCP/IP's technical merits
Beyond the political and economic factors, TCP/IP had real technical strengths:
Layered but pragmatic. It had layers (link, IP, transport, application) but didn't over-engineer them. Working code over theoretical purity.
End-to-end design. Smart endpoints, dumb network. The network's only job is to move packets; complexity lives at the edges. Has scaled well.
Composable. New applications could be built on top easily.
Recovery from loss. TCP's congestion control was added incrementally as the network grew. It scaled.
Vendor-neutral. Anyone could implement, no permissions needed.
These weren't perfect choices for every scenario. TCP/IP has well-known weaknesses (DDoS susceptibility, congestion in specific conditions, limited QoS). But the design was good enough to scale.
What 1995 looked like
By 1995, the verdict was clear:
- The commercial internet had taken off (NSFNET commercial restrictions had ended).
- Every major operating system had native TCP/IP support.
- ISPs were proliferating.
- The Web (which we'll cover in the next article) was emerging.
OSI was effectively dead, except for some niche deployments in European telcos. Proprietary networks were transitioning to TCP/IP. Universities, businesses, and consumers all standardized on TCP/IP.
The protocol that started as a research experiment had become the protocol of human civilization's communication infrastructure.
The lesson
The TCP/IP story is sometimes told as "the better protocol won." That's partly true but oversimplified. The fuller story:
Working code beats theoretical perfection. TCP/IP shipped and was refined; OSI specified and was over-specified. The shipped thing wins.
Free and open beats proprietary, eventually. Proprietary networks had advantages in features but lost as customers preferred not to be locked in.
Network effects compound. Once TCP/IP had a critical mass, the cost of using anything else included losing connectivity.
Incremental refinement beats big upfront design. Decades of small TCP/IP improvements beat one big OSI design.
These lessons apply far beyond networking. They're echoes of the open-source movement's later patterns. Working things win; perfect things don't ship.
What still uses non-TCP/IP
A few corners:
- Some mainframe networks still run SNA internally, with TCP/IP gateways.
- Some industrial control systems use proprietary protocols (Modbus, etc.) on isolated networks.
- Some military and government systems use specialized protocols.
- Some specialized fast-trading networks use custom low-latency protocols.
These are niches. The 99 percent of networked communication is TCP/IP, in some form.
What TCP/IP looks like in 2026
The protocol has evolved:
- TCP itself has been refined (many extensions: SACK, ECN, BBR congestion control).
- UDP gained reliability layers on top (QUIC).
- IP itself migrated from IPv4 to IPv6 (slowly).
- TLS made the application layer mostly encrypted.
But the core architecture is unchanged. The packet format, the addressing concept, the protocol numbers, the end-to-end design: all still recognizable from the 1980s.
This is a remarkable property. Networking technology that's older than most of its users still works, scales, and is improved incrementally. Few infrastructure technologies have such longevity.
Conclusion
TCP/IP didn't win because it was perfect. It won because it worked, shipped, and was free. The protocol designed by Vint Cerf, Bob Kahn, and the small ARPA community of the 1970s ended up running the world.
OSI's lesson is real: standards bodies designing comprehensive systems without working implementations tend to lose. SNA and DECnet's lessons are real: proprietary lock-in eventually loses to open alternatives.
The internet's foundation is a 50-year-old protocol that beat its competitors not by being theoretically best, but by being available, refinable, and useful. That's a kind of victory worth remembering.
Coming up
We've covered the protocol's victory. Next, the protocol that turns names into addresses: DNS. Its history is its own quiet drama.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
Why your server's IP being public is fine, and when it isn't
A game server has an IP address. Players connect to it. The IP is, by definition, reachable from the internet. Many server owners feel uneasy about their IP being known, often because they don't know what risk it actually represents.
What a DDoS actually looks like to a Minecraft server, and what protection means
"DDoS protection" is on every hosting marketing page. Most people who pay for it don't know what it does, how attacks actually work, or what level of protection is enough. This article explains, in honest terms, what to expect.
Why "ping to server" can lie, and how to measure properly
The number next to a server in your game's server list (the "ping" or latency display) is convenient. It's also frequently misleading. This article explains what it actually measures, when it's wrong, and how to get a real number.