The Problem That Preceded the Internet
In the late 1950s, the United States military had a communications problem. Its command-and-control network was centralized, which meant a single nuclear strike on the right city could sever the entire system. The solution they needed wasn’t faster or more powerful communication. It was communication that couldn’t be decapitated.
The RAND Corporation researcher Paul Baran spent years in the early 1960s working on exactly this. His 1964 series of memos, “On Distributed Communications,” proposed something radical: a network with no center. Instead of messages traveling through a hub, they would be broken into pieces and each piece would find its own way through a web of interconnected nodes. If some nodes were destroyed, the pieces would route around the damage and reassemble at the destination.
Baran called this “distributed communications.” We now call it packet switching. And the protocol family built on that idea, TCP/IP, moves nearly all the data on the modern internet.
What Packet Switching Actually Does
Most people’s intuition about sending data is wrong. They imagine it working like a phone call: a dedicated line opens between sender and receiver, data travels down it, the line closes. This is called circuit switching, and it’s how telephone networks were built for most of the twentieth century.
Packet switching is stranger and, it turns out, far more resilient. When you load a webpage, your request doesn’t travel as a single coherent stream. It gets broken into packets, each roughly 1,500 bytes under typical Ethernet settings. Each packet carries a header with the destination IP address, a sequence number, and enough information to be reassembled later. Crucially, packets can take different physical paths through the network and arrive out of order. The receiving end sorts them.
This is counterintuitive. It seems inefficient to deliberately fragment your message and let the pieces wander. The efficiency comes from what you don’t need: no reserved channel, no dedicated line, no single point of failure. The network’s routers make independent forwarding decisions at every hop, responding to real-time conditions. If a router goes down, traffic reroutes. This wasn’t an accident of design. It was the entire point.
The Two-Protocol Stack and Why Both Pieces Matter
TCP/IP is commonly treated as a single thing. It isn’t. It’s a collaboration between two protocols that handle different problems.
IP (Internet Protocol) handles addressing and routing. It defines what an address looks like, how packets are labeled, and the rules for forwarding them toward their destination. IP is deliberately simple and makes no promises. It will try to deliver your packets, but it offers no guarantee they’ll arrive, arrive in order, or arrive at all. In networking terms, IP is “connectionless” and provides “best-effort delivery.”
TCP (Transmission Control Protocol) sits on top of IP and adds reliability. Before any data moves, TCP performs a three-way handshake: the sender sends a SYN packet, the receiver replies with SYN-ACK, the sender confirms with ACK. Both sides now know the connection is live. From there, TCP tracks which packets arrived, asks for retransmission of any that didn’t, enforces ordering, and manages flow control to prevent a fast sender from overwhelming a slow receiver.
The division of labor is important. By keeping IP simple and pushing reliability up to TCP, the designers created a stack that could run on almost any hardware and network type. A satellite link, a fiber line, and a radio connection all speak IP. The complexity lives at the edges, in the software running on endpoints, not in the network itself. This principle, sometimes called the “end-to-end argument,” was formalized by Jerome Saltzer, David Reed, and David Clark in a 1984 paper and remains one of the most influential ideas in networking.
How the Military Research Became a Commercial Standard
The protocol’s path from ARPANET research to global infrastructure is not a clean story of visionary planning. It’s closer to a series of pragmatic accidents that happened to compound in the right direction.
ARPANET, the Defense Department’s experimental network, began operating in 1969 with four nodes. The early network didn’t actually use TCP/IP. It used a different protocol called NCP. TCP/IP came later, standardized by Vint Cerf and Bob Kahn in their 1974 paper “A Protocol for Packet Network Intercommunication.” The transition from NCP to TCP/IP on ARPANET was completed on January 1, 1983, a date sometimes called “Flag Day” in networking history.
What made TCP/IP dominant over competing protocols like IBM’s SNA or the OSI reference model (backed by European governments and major telecom companies) wasn’t technical superiority on every dimension. OSI was arguably more carefully designed and more complete as a specification. TCP/IP won because it was already running. Universities and research institutions had built real networks on it. The software existed. The expertise existed. When the commercial internet started expanding in the late 1980s and early 1990s, TCP/IP was the obvious choice because it was the only choice with a proven track record at scale. Why the Second-Best Technology Usually Wins Markets describes this pattern well: first-mover advantage combined with good-enough performance tends to outrun theoretical superiority.
The Nuclear War Paranoia Was Justified, Just Not in the Way Anyone Expected
Here’s the irony worth sitting with. TCP/IP was built to survive nuclear war, and in its entire operational history, it has never had to survive nuclear war. What it has survived, repeatedly, is everything else.
The 2011 earthquake and tsunami that devastated Japan knocked out data centers, severed fiber lines, and disrupted power across entire regions. Internet traffic to and from Japan rerouted. The network degraded but didn’t collapse. When a major BGP (Border Gateway Protocol) misconfiguration in 2010 caused a Chinese telecom to briefly advertise routes for large portions of global traffic, drawing packets through Chinese networks, the internet didn’t break. It misrouted, then corrected. When individual submarine cables are cut (which happens more often than most people realize, typically from ship anchors or fishing equipment), traffic shifts to surviving paths.
The resilience that Baran designed for a specific catastrophic scenario turned out to be resilient against the ordinary, constant, grinding reality of infrastructure at scale: hardware failures, human error, natural disasters, and bad actors.
The Limits Baran’s Design Didn’t Anticipate
Distributed design solves availability but creates its own problems. The same lack of central authority that makes the network hard to destroy makes it hard to manage.
IP addresses were originally allocated with almost no coordination. The designers assumed 32-bit IPv4 addresses would be more than sufficient. That meant about 4.3 billion unique addresses. By the early 1990s, researchers could see that number would be exhausted. IPv6, with 128-bit addresses (providing roughly 340 undecillion addresses), was standardized in 1998. More than 25 years later, IPv4 and IPv6 coexist in a messy dual-stack arrangement because the transition has been excruciatingly slow. Most major networks now support both. Most traffic still runs IPv4.
Security was an even larger oversight. The original ARPANET connected trusted research institutions. Authentication, encryption, and malicious actors weren’t design priorities. The result is a protocol stack that routes packets with no inherent verification of whether the sender is who they claim to be. IP spoofing, where an attacker sends packets with a forged source address, is possible precisely because IP was never designed to prevent it. BGP, the routing protocol that helps networks find each other, operates largely on trust. When a network advertises that it can reach certain IP addresses, other networks generally believe it. The 2010 Chinese telecom incident and dozens of other BGP hijacking events exploit this.
These aren’t obscure edge cases. They are structural properties of a system designed for resilience in a trusted environment that was later deployed in an adversarial one.
What This Means
The history of TCP/IP contains a lesson that extends well past networking. Baran’s original paranoid design constraint, build it so nuclear strikes can’t take it down, created a protocol robust enough to handle threats its designers never imagined. The discipline of designing for catastrophic failure produced incidental resilience against ordinary failure.
Most systems are designed for the expected case. The requirement to handle the worst case forced architectural choices (no central authority, stateless routing, end-to-end reliability) that turned out to be valuable independent of the original threat model.
The protocol’s weaknesses follow the same logic in reverse. Security and address space were afterthoughts because the designers were solving a different problem. Those gaps have proven costly in ways that are still playing out.
The internet you’re using right now runs on infrastructure whose core design decisions were made by researchers trying to survive thermonuclear war. The nuclear war never came. The design decisions survived anyway, along with everything that was built on them.
