The internet did not arrive fully formed. It grew slowly, over decades, out of a specific Cold War anxiety: what happens to military communications if a nuclear strike destroys a central hub? The answer, proposed by RAND Corporation researcher Paul Baran in 1964, was a network with no center at all — a mesh of nodes where messages could find their own path through whatever connections remained standing. Baran called it a distributed network, and the concept of packet switching — breaking messages into discrete chunks and routing each one independently — was born.
The U.S. Department of Defense’s Advanced Research Projects Agency (ARPA) took that idea and built something real. In 1969, four nodes came online: UCLA, Stanford Research Institute, UC Santa Barbara, and the University of Utah. The first message ever transmitted over this network was supposed to be “login.” The system crashed after the first two characters. The actual first message sent over ARPANET was “lo.” An accidental haiku, and a fitting one for a technology that would spend its first decade barely holding together.
Packet Switching: The Protocol That Changed Everything
Understanding the internet requires understanding packet switching, because it is the foundational departure from every network that came before it. Traditional telephone networks used circuit switching: when you called someone, a dedicated physical circuit was established between you and them. That circuit held open for the entire conversation, whether you were talking or sitting in silence. It was efficient for voice, but fragile and wasteful for data.
Packet switching works differently. Data is divided into small, labeled packets, each one containing a destination address, a sequence number, and a chunk of the original payload. Those packets are sent into the network independently. Each router they encounter examines the destination address and forwards the packet toward that destination using whatever path looks best at that moment. The packets may travel completely different routes. They may arrive out of order. Destination nodes reassemble them into the original message using the sequence numbers.
This design has a profound consequence: the network is inherently resilient. If a node goes down, packets simply route around it. No single point of failure can bring the whole system down. Baran’s original insight about surviving a nuclear strike turned out to be useful for a much more mundane but equally relentless problem: equipment failures, congested links, and the sheer chaotic growth of the network itself.
TCP/IP: The Language Everyone Agreed to Speak
ARPANET worked, but it worked in isolation. Throughout the early 1970s, different networks were proliferating — satellite networks, radio networks, local Ethernet networks being developed at Xerox PARC. Each used its own protocols, its own conventions, its own assumptions. Connecting them was a Tower of Babel problem.
Vint Cerf and Bob Kahn tackled this directly. In 1974, they published a paper titled “A Protocol for Packet Network Intercommunication” that laid out the architecture for what would become TCP/IP — the Transmission Control Protocol and the Internet Protocol. The core insight was elegant: instead of designing a single unified network, design a protocol that allows any network to connect to any other network. Build a network of networks. An internetwork. An internet.
IP handled addressing and routing. Every machine on the network gets a unique numerical address. Packets carry that address and are forwarded hop by hop toward their destination. TCP handled reliability. IP itself makes no guarantees — packets can be lost, duplicated, or arrive out of order. TCP adds a layer of acknowledgment and retransmission on top, so applications can rely on their data arriving intact.
On January 1, 1983, ARPANET switched over from its older NCP protocol to TCP/IP in a single coordinated cutover. This date is sometimes called the “flag day” of the internet. Every machine had to be updated simultaneously. There was no graceful migration path — you were either on TCP/IP or you were cut off. The fact that it worked is a testament to how thoroughly the research community had already internalized the new protocol stack.
DNS: Giving Names to Numbers
Early on, every machine on ARPANET was listed in a single text file called HOSTS.TXT, maintained at SRI International and manually distributed to every node. If you wanted to reach a machine, you looked up its IP address in that file. As the network grew, this became untenable. By the early 1980s, the file was being updated multiple times a week, and every host had to constantly re-download it. The system was collapsing under its own weight.
Paul Mockapetris designed the Domain Name System in 1983, publishing the specs in RFC 882 and RFC 883. DNS is a distributed, hierarchical database. Instead of one central file, there is a tree of name servers, each authoritative for a portion of the namespace. At the root are a small set of root servers. Below them are the top-level domain servers — .com, .org, .net, and country-code domains. Below those are the authoritative servers for individual domains.
When you type a domain name into a browser, a resolver walks that tree, caching results at every step, until it gets an IP address. The system is both resilient and scalable. It handles billions of queries per day, across a namespace containing hundreds of millions of domains, using essentially the same architecture Mockapetris designed forty years ago. DNS is one of the most durable pieces of infrastructure in computing history.
From ARPANET to the Public Internet
Throughout the 1970s and early 1980s, the internet was largely the province of universities, research institutions, and the military. The backbone infrastructure — the high-speed links connecting major nodes — was funded and operated by the National Science Foundation through NSFNet, which replaced ARPANET as the primary U.S. backbone in 1986. Commercial activity on this backbone was explicitly prohibited by the NSF’s Acceptable Use Policy.
That began to change in the late 1980s as commercial internet service providers started building their own backbone networks. UUNET was founded in 1987. PSINet and CERFNET followed. These networks interconnected at exchange points — physical facilities where ISPs would peer their networks, agreeing to carry each other’s traffic. The first Network Access Points, or NAPs, formalized this peering infrastructure in the early 1990s.
In 1991, NSFNet lifted its commercial traffic restrictions. In 1995, it shut down entirely, handing the backbone over to private ISPs completely. The public internet as we know it — a commercial, competitive, decentralized collection of interconnected private networks — came into being through this gradual transfer rather than any single dramatic moment.
The World Wide Web: HTTP, HTML, and the Browser Wars
The internet and the World Wide Web are not the same thing, a distinction that matters more than most people realize. The internet is the underlying infrastructure — the physical cables, routers, and protocols that move packets between machines. The Web is an application that runs on top of that infrastructure, one of many alongside email, FTP, IRC, and later peer-to-peer filesharing and streaming.
Tim Berners-Lee was a physicist at CERN when he wrote a proposal in March 1989 titled “Information Management: A Proposal.” His boss returned it with the annotation “vague but exciting.” That vague proposal became the World Wide Web. Berners-Lee defined three foundational technologies: HTML, the markup language for creating documents; HTTP, the protocol for transferring them; and URLs, the addressing scheme for locating them. He also wrote the first web browser and the first web server, running them on a NeXT workstation at CERN.
The first website went live on August 6, 1991. It explained what the World Wide Web was. By 1993, there were still only around 500 servers. Then NCSA released Mosaic — the first browser with inline images, the first with a point-and-click interface accessible to non-technical users. Suddenly the Web looked like something ordinary people might use. Within a year, traffic was growing at a rate of 341,634% annually. Marc Andreessen, one of Mosaic’s authors, left NCSA and co-founded Netscape. The browser wars began.
Routing at Scale: BGP and the Autonomous System Model
As the internet expanded beyond any single organization’s control, the routing problem became genuinely hard. TCP/IP defines how packets are addressed and forwarded, but it does not define how routers discover paths through the global network. Early routing protocols like RIP (Routing Information Protocol) worked fine for small networks but broke down at scale. They flooded the network with routing updates and converged slowly when topology changed.
The Border Gateway Protocol, or BGP, emerged as the solution. First deployed in 1989 and still in use today in its fourth major revision, BGP is the routing protocol that holds the internet together. It operates between Autonomous Systems — the technical term for an independently operated network, each assigned a unique Autonomous System Number by IANA. Your ISP is an Autonomous System. Google is an Autonomous System. A major university is an Autonomous System.
BGP allows these autonomous systems to advertise which IP address ranges they can reach, and to propagate that reachability information to their peers. Routing decisions incorporate not just technical metrics but also policy — an ISP can prefer certain paths over others, filter out certain announcements, and implement business relationships in routing logic. This makes BGP extraordinarily flexible and equally extraordinarily fragile. A misconfigured BGP advertisement in 2010 caused Pakistan Telecom to accidentally black-hole YouTube traffic for the entire global internet for two hours. The same basic event has happened dozens of times. BGP’s security model was designed for a network of trusted peers; it has not aged gracefully into a network of billions of adversarial participants.
The Infrastructure Beneath Everything
It is easy to think of the internet as a wireless, intangible thing — a cloud. The physical reality is anything but. The internet runs on approximately 1.3 million kilometers of submarine fiber optic cable laid across the ocean floors, connecting every continent except Antarctica. Those cables carry roughly 99% of all international internet traffic. Satellites, despite their cultural prominence, handle a fraction of a percent of global bandwidth.
On land, internet traffic flows through a hierarchy of data centers, exchange points, and ISP networks, ultimately terminating at the fiber and copper cables connecting individual homes and businesses. The major internet exchange points — the Equinix facilities, DE-CIX in Frankfurt, AMS-IX in Amsterdam, LINX in London — are unremarkable-looking warehouses where hundreds of networks physically connect and exchange traffic at aggregate speeds measured in terabits per second.
The hyperscalers — Google, Amazon, Microsoft, Meta — have increasingly built their own parallel infrastructure, running private fiber networks between their data centers that carry their internal traffic off the public internet entirely. Google’s private network is estimated to carry more traffic than the entire public internet carried in 2000. The internet is increasingly a collection of massive private networks that interconnect at carefully controlled points, rather than the egalitarian mesh its founders imagined.
What the Architects Got Right — and What They Didn’t
The internet’s founding architecture made some prescient bets and some catastrophic omissions. The end-to-end principle — the idea that intelligence belongs at the edges of the network, not the core — was visionary. It meant the network itself was simple and generic, capable of carrying any application its users could dream up. You did not need to ask permission to build a new application on the internet. You just built it. This is what enabled the Web, email, voice-over-IP, streaming video, and everything else.
What the founders did not build in was security, authentication, or privacy. IP has no native mechanism for verifying that a packet’s source address is genuine. BGP has no native mechanism for verifying that a route advertisement is legitimate. The original DNS had no mechanism for verifying that a response came from an authoritative server. These omissions were not oversights in the pejorative sense — the network was being built among trusted researchers with no adversarial model in mind. But as the internet became a global infrastructure carrying financial transactions, medical records, and the communications of billions of people, those architectural gaps became load-bearing vulnerabilities.
Extensions have been bolted on: DNSSEC adds cryptographic signing to DNS. BGPsec attempts to authenticate route announcements. TLS encrypts web traffic. IPsec can encrypt at the network layer. But these are retrofits, and retrofits are never as clean as original design. The security model of the internet is a patchwork, and it shows.
What ARPANET’s founders built, in the end, was something more durable than any of them probably expected: a general-purpose communication substrate that has outlasted every prediction about what it was for, who would use it, and how large it would grow. The four nodes of 1969 have become roughly five billion connected devices. The protocols designed for a research network among trusted peers now carry the weight of the global economy. That the thing still works at all is the most remarkable fact in the history of engineering.