Networking and the Internet, from First Principles · Faza

Have you ever wondered what happens when we text, call, or video chat with a friend or a colleague on another continent, and their reply arrives in a fraction of a second, as though they were in the same room? Behind the scenes, a chain of invisible conversions takes place: your voice, video, or message is translated into radio waves crossing the room to your Wi-Fi router, then electrical pulses in copper (or light, if you have a fiber connection), and then flashes of light inside a glass strand thinner than a hair lying deep on the ocean floor, only for the entire sequence to play in reverse at the other end. I find it mind-boggling that we can communicate instantly with anyone in the world by doing nothing more than creating controlled, patterned disturbances of electricity, light, and radio.

The message passes through equipment owned by dozens of independent companies in different countries. None of them coordinated with the others specifically for this message transfer, and none of them knows the full path your data took, they just hand it off to the next closest route. There is no central computer directing the traffic, and no single company owns the internet infrastructure. Yet it works, billions of times every second, so reliably that we only notice it when a call stutters or video buffers.

The software article followed the story of a single machine, from electrons in silicon up to the software you run. This article follows the story of the connections between those machines. Like the layers of computing, the internet was not designed in one stroke; it accumulated over decades, and each protocol makes sense only once you see the concrete limitation it was invented to fix. It is easy to mistake the result for something engineered to a finished blueprint, because failures are rare enough to feel like the system was always this reliable. In reality, every mechanism in this article, packet switching, TCP, DNS, and TLS, was a patch for a specific problem, deployed decades after the internet already “worked”, and the pressure that produced them hasn’t stopped: it now comes from new physical links, new failure scenarios, and new demands from software that didn’t exist when the layer beneath it was designed.

My aim is to build this understanding from first principles. By the end, many of the everyday mysteries of using the internet will make intuitive sense under a single, coherent mental model: how the padlock in your address bar protects your credit card details, whether a dead page is the website’s fault or a failure at your own end, why a webpage can feel sluggish even on a “gigabit” connection, and how your data dynamically reroutes around a failing undersea cable half a world away.

We Were Sending Bits Even Before Computers Existed

Networking is much older than computing, and older than electricity too. The word network itself originally meant exactly what it sounds like, a net-like fabric of threads or cords crossing at regular intervals. In the early 19th century, engineers borrowed the term to describe interconnected transit routes like canals and railways. When the electrical telegraph arrived in the 1840s, the word drifted naturally to describe the systems of wires and stations that carried its signals.

Yet the basic physical principle of a network link remains the same as the simplest mechanical connection. Knot a string tight between two tin cans, speak into one, and the string carries the vibration of your voice to the other as mechanical motion with no amplifier or relay, just a wave losing energy to friction and slack with every meter it crosses. That is already the whole principle behind every link built since, vary a physical quantity at one end and measure it at the other. What the string can’t do is carry a signal any real distance without it dying in the line. The telegraph’s true breakthrough wasn’t just replacing string with electrical wire, but overcoming this physical limit of distance.

In 1844, Samuel Morse sent the message “What hath God wrought” from Washington to Baltimore over a copper wire, using Morse code, a system of short and long electrical pulses. Notice what the telegraph actually was, a digital network. It did not transmit the sound of a voice; it transmitted discrete symbols from a fixed alphabet. That choice had an advantage the Victorians understood well. An electromechanical relay along the line didn’t need to pass the wave itself; it only needed to detect whether a pulse was present, and then recreate a brand new, clean copy of that pulse to send down the next segment of wire. Discrete symbols plus regeneration meant a message could cross a continent without degrading, something no analog signal could do.

Notice also what had to exist before the wire could carry anything, an agreement between sender and receiver. The telegraph only worked because both ends held the same table in advance, which pulses stood for which letters, and how operators signaled “received” or “repeat.” This shared rulebook is a protocol. Every protocol in this article (IP, TCP, DNS, TLS) is the same, a published agreement on message formats and who says what when, allowing independent machines to communicate with each other.

The simulator below sends Morse’s message down that historic line. Watch the pulses fade and pick up noise along each span of wire, and what the relays do about it, then switch the relays to bare amplification and see why the discrete alphabet (which modern computing simplified even further into binary bits) was such a smart choice.

The telegraph network even solved routing, with people. A message from a small town to another small town passed through relay offices, where operators received it, punched it onto paper tape, and retransmitted it down whichever outgoing line led closer to the destination when that line became free. Messages queued in bins during busy hours. Hold onto this idea, a hundred years later we will rebuild it with electronics and call it a router.

Morse’s own line only had to cross one state. Crossing an ocean took longer, requiring a decade of costly setbacks and a painful education in the physics of underwater cables. Cyrus Field’s first transatlantic telegraph cable went live in August 1858, carrying a congratulatory exchange between Queen Victoria and President Buchanan; three weeks later it was dead, its insulation damaged in handling and, some think, finished off by an engineer’s overvoltage trying to push a signal through it. The successful cable came in 1866, laid by the SS Great Eastern, at the time the largest ship ever built and the only one that could carry the roughly 4,000 kilometers of cable in a single piece. The ocean floor has carried communication cables ever since, a story we will return to when telegraph wires evolve into coaxial copper and, eventually, glass fiber.

The underlying trick generalizes to every link ever built since. To move bits between two points, you vary some physical quantity at one end and measure it at the other, on an agreed schedule. A bit, short for “binary digit,” is the smallest possible piece of information there is, a single choice between exactly two states, conventionally written 1 or 0, and everything this article measures, sends, or stores is ultimately some number of these (the software article builds this up from transistors and logic gates, if you want to understand that too). Group eight of them together and you have a byte, enough states, 256 of them, to stand for one character of text or one small number, which is why sizes throughout this article, a packet header, a frame, a file, all get counted in bytes rather than bits.

Put voltage on a wire for a 1, leave it off for a 0, measure a million times per second, and the wire carries a million bits per second. Optical fiber does it by switching a laser on and off inside the glass strand, light for a 1, darkness for a 0, millions of times per second; Wi-Fi does it by varying the shape of a radio wave (how exactly is the subject of the upcoming wireless article).

Two numbers characterize every such link, and keeping them separate resolves a lot of everyday confusion.

• Bandwidth is how many bits per second the link carries.
• Latency is how long one bit takes to get from one end to the other.

Bandwidth is an engineering problem, and engineers keep winning it. A single modern fiber strand carries terabits per second by sending many wavelengths of light at once. Latency is physics, light in glass covers about 200,000 kilometers per second, two-thirds of its speed in vacuum, so New York to London has a hard floor of roughly 28 milliseconds one way (twice that for a round trip) that no amount of money or engineering can lower. This is why a video stream and a video call feel so different, the stream needs bandwidth and tolerates latency (it buffers seconds ahead), while the call needs low latency and only modest bandwidth. When a page feels slow on a fast connection, latency is usually the culprit. As we’ll see later, a single page load requires multiple round trips (for DNS, TCP, and TLS) before any content actually starts moving.

The two numbers never trade off against each other, because they come from different places, bandwidth from the sender’s schedule, latency from the wire’s length. The simulator below sends the same 8 bits down one link, adjust the bandwidth and only the spacing between pulses changes, adjust the distance and only the delay before the first pulse arrives changes.

A Dedicated Circuit for Every Conversation

The telegraph carried text between offices. The telephone, from 1876 onward, carried live voice into homes, and to do it, the network worked on a completely different principle called circuit switching. When you placed a call, the system assembled a dedicated electrical path between your telephone and the receiver’s, originally by human operators plugging patch cords into switchboards, later by electromechanical relays doing the same thing automatically. For the duration of the call, that chain of copper belonged exclusively to your conversation, end to end.

For speech, this is a reasonable design, a phone call is a continuous signal flowing nearly the whole time, so the reserved line is actually used. So when computers first needed to talk over distance in the 1950s and 60s, they did the only thing possible, they dialed each other over phone lines. But because telephone lines were built to carry human voices, analog sound waves, rather than direct digital electrical pulses; computers had to use a modem (short for modulator-demodulator). The modem translated the computer’s digital binary bits into analog audio tones, audible as the chirps, beeps, and static of a dial-up handshake, that could travel over the voice network, and translated those sounds back into digital bits at the other end.

The earliest modems, like the 300-baud Bell 103, did this with FSK (Frequency-Shift Keying), the same trick as the telegraph’s on/off pulses, but with a wire that could only carry a continuous tone, not a clean on/off voltage. Every 1 bit plays one steady tone for its whole duration, every 0 bit plays a different, lower tone, and the modem on the other end just listens for which tone is present and reads back the bit. Watch one byte, the letter ‘A’, get modulated into tone and demodulated back into bits:

Before any data moved over that reserved line, the two modems first had to agree, over that same voice-grade circuit, on how fast they could talk and how they’d correct the errors a noisy copper pair was bound to introduce. Modems since the 1981 Hayes Smartmodem left a speaker wired in so a human could hear the call connect, dial tone through ringing, and confirm it hadn’t hit a busy signal or a wrong number before the computer took over; the speaker stayed on into the handshake and only cut out once the negotiation finished, which is why that negotiation was audible too. If you were using the internet during the 1990s and early 2000s, do you remember this tone?

That noisy handshake remained the way most people reached the internet well into the early 2000s, until broadband retired it. DSL and cable reused the same telephone and television wires, but as always-on digital links with no call to place, and fiber to the home dropped the voice network’s wires entirely.

The deeper mismatch, though, was never the modem’s translation, and it was clear decades before broadband. Computer traffic is bursty, a terminal sends a keystroke or a request in milliseconds, then the line sits silent while a human reads or a processor computes. (Even streaming a video today, which feels continuous, is actually delivered in short, intense bursts of packets that fill a playback buffer, followed by silence while you watch.) Measured over a session, a circuit reserved for a computer conversation is idle the vast majority of the time, yet it blocks that capacity for everyone else. Worse, the path is fixed at call setup, so one broken link or switching office anywhere along it kills the connection outright.

By the early 1960s, three pressures were converging on this circuit-switched design. Research computers were multiplying and needed to share expensive long-distance lines efficiently. Interactive computing made the burstiness extreme. And the United States military, in the middle of the Cold War, wanted a command network that could keep functioning after losing large pieces of itself, which a network of fixed paths through central switching offices could never do.

Splitting Messages into Packets

The alternative was worked out independently by two people who did not know of each other’s work, Paul Baran at the RAND Corporation, designing for survivability, and Donald Davies at the UK’s National Physical Laboratory, designing for line sharing, who gave the idea its name, the packet.

Instead of reserving a path and streaming data down it, split every message into small, self-contained units. Each packet carries a header, a few bytes of control information including the source and destination addresses, followed by the payload, the chunk of data itself. Every switching point along the way, a router, receives a packet in full, reads the destination address in its header, consults its own table of which outgoing line leads closer to that destination, and forwards the packet down it. This is store-and-forward switching, the telegraph relay office rebuilt in electronics, with the paper tape replaced by memory and the operator replaced by a lookup table.

To scale to billions of machines, routers don’t list individual addresses. Instead, their tables list networks, ranges of addresses grouped under a single next hop. The exact structure of these addresses, and how they are compared against ranges, depends on the protocol in the packet header (Baran and Davies each designed their own). We will explore the internet’s version, IP, in detail in Connecting the Networks.

With this design, packets from thousands of unrelated conversations interleave on the same wires, so no line sits idle while anyone has data to send. And because each packet is routed independently, the network flows around damage. If a router dies mid-conversation, subsequent packets simply travel through its neighbors. Baran called this a distributed network, one with no point whose loss can cut it in two.

The simulator below is a small packet-switched mesh. Clients on the left exchange packets with servers on the right. Both are examples of a host, the generic name for any addressable device on a network, computer, phone, server, whatever it is. The two roles themselves matter enough that this article will keep coming back to them, a client initiates a conversation, a server sits at a known, fixed address and waits to be reached. Each router in between makes only local decisions, forwarding each packet toward its destination while steering around links that are already busy. Watch how packets from the same conversation take different paths, and how congestion reshapes routes in real time. And click a router to kill it, notice the healing is not instant, for a few seconds its neighbors keep forwarding into the gap on stale information and those packets are lost, until news of the failure spreads and routes settle around it, a catching-up process called convergence that we will explore when we look at routing protocols.

Notice one more thing in the simulator, occasionally a packet is simply dropped. When packets arrive at a router faster than an outgoing line can drain them, the router queues them in memory, and when the queue is full, it discards what it cannot hold. This is not a failure of the design; it is the design. The network promises only best-effort delivery, packets may be lost, duplicated, or arrive out of order, and the network itself does nothing to correct it. Keeping the middle of the network this simple, and pushing all responsibility for reliability out to the computers at the edges, is the single most consequential decision in the internet’s architecture, and the key to how it scaled to a global network.

The First Packet Network

In 1969, ARPA, the US Advanced Research Projects Agency, funded the first real packet-switching network, the ARPANET, to connect the research computers it was already paying for at universities across the country.

There was an immediate, mundane obstacle. The mainframes at each site came from different manufacturers, ran incompatible operating systems, and had no spare capacity for the real-time work of switching packets. The engineering firm Bolt Beranek and Newman (BBN) solved this with a dedicated machine, the Interface Message Processor (IMP), a ruggedized minicomputer whose only job was to break messages into packets, route them, and reassemble them at the far end. Each site plugged its mainframe into its local IMP, and the IMPs talked to each other over leased telephone lines. ARPANET’s own protocol documents drew a sharp line between the two machines at each site, the IMP, dumb switching hardware with one job, and the mainframe behind it, which they called the Host, the machine that actually hosted the computation anyone cared about. That word outlived the hardware, a host today is any computer, phone, or server sending or receiving traffic, and a router or switch is whatever inherited the IMP’s old job of being infrastructure, not a host itself. The IMP was the first router, and its pattern, a dedicated box that speaks the network’s protocol so the computers behind it don’t have to, is sitting in your home right now with antennas on it.

The first transmission took place on October 29, 1969, from UCLA to the Stanford Research Institute. A student programmer, Charley Kline, began typing LOGIN to log into the remote machine. He typed L, confirmed by phone that it had arrived, typed O, and the receiving system crashed. The first message ever carried by the internet’s ancestor was LO. By December the network had four nodes; by 1973 it crossed the Atlantic to Norway and London.

One Shared Wire for the Whole Office

The packet-switching network built for the ARPANET connected distant sites over leased point-to-point lines, forming a WAN (Wide Area Network). The same core idea of packet transmission also solved a smaller, far more local problem, how do you connect the dozens of machines in one office, a LAN (Local Area Network), without running a dedicated wire between every pair?

In 1973, Robert Metcalfe at Xerox PARC designed Ethernet. Its collision handling drew directly on ALOHAnet, an earlier radio network linking the Hawaiian islands, whose core idea was refreshingly blunt, a station just transmits whenever it has something to send, and listens for whether it collided with someone else’s transmission, rather than asking permission first. Metcalfe’s design connected every computer in a building to one shared coaxial cable, which he called “the ether.” Coaxial means two conductors on the same central axis, a single copper core carrying the signal, wrapped in an insulating layer, then a cylindrical braided or foil shield, then a plastic jacket. The shield doubles as the return path and blocks outside interference from reaching the core, which is what let one long cable carry a clean signal past every desk in the building. Any machine could transmit onto the cable, and every machine received everything, keeping only the packets addressed to it.

A shared medium has an obvious flaw, if two machines transmit at once, they garble each other, a collision. Ethernet handled it with a few purely local rules, listen before transmitting, and wait if the cable is busy; keep listening while transmitting, and stop the instant you hear a collision; then retry after a random delay. By doubling the range of that random delay with each repeated collision, a strategy called exponential backoff, colliding machines spread themselves apart instead of jamming the line forever. This scheme is called CSMA/CD (Carrier Sense Multiple Access with Collision Detection), “carrier sense” is listening before you talk, and “collision detection” is stopping the instant you hear noise. As with packet routing, orderly sharing emerges from identical local rules, with no coordinator required.

The shared cable itself didn’t survive, offices moved to switches, and the coax went with it, replaced by twisted-pair copper terminating in an RJ-45 connector, a clear plastic clip slightly wider than a phone jack, one dedicated run from each device back to the switch instead of one wire threaded past every desk.

A switch solves the same problem as a router, delivering data only to its destination, but operates on local hardware addresses rather than global network addresses, and by a different mechanism entirely. A router reads a packet’s destination address and picks a line from a table someone configured. A switch reads a frame’s (Ethernet’s own name for its unit of data, a packet’s counterpart one layer down) MAC (Media Access Control) address, the identifier burned into a device’s network hardware, and picks a port from a table it built entirely by itself, by watching traffic go by.

A MAC address is written as six pairs of hexadecimal digits separated by colons, for example, 00:1A:2B:3C:4D:5E.

Hexadecimal just means base 16 instead of base 10, sixteen digits per place, 0 through 9 and then A through F standing in for ten through fifteen. It was chosen for a reason more specific than tradition, 16 is a power of 2, so one hex digit always encodes exactly four bits, no remainder, and two hex digits always encode exactly one byte, 1A is one byte with the value 26. Decimal has no such alignment, three decimal digits sometimes hold a byte and sometimes don’t, which is why engineers reach for hex anywhere they’re really looking at raw bits but want something more compact than writing them out as 1s and 0s. That’s the same reason it resurfaces later in this article, in packet header bytes and protocol numbers, it’s binary in fewer characters, not a different kind of number.

By dividing this 48-bit address into a manufacturer prefix (the first three pairs, known as an OUI or Organizationally Unique Identifier) and a serial number (the last three pairs), they ensured every network interface card on Earth gets a globally unique ID. Every connected device, including your smartphone, carries these identifiers for both its Wi-Fi and Bluetooth chips.

Because a permanent hardware address never changes, anyone operating public Wi-Fi networks (like in a shopping mall) could log your MAC address to track your physical movements over time. To prevent this, modern operating systems now generate temporary, randomized MAC addresses when scanning for networks or connecting to public Wi-Fi. The switch doesn’t mind; it only needs your address to be unique among the few devices currently in the room, which a randomly generated 48-bit number easily guarantees.

When a switch is powered on, its forwarding table starts empty. Every time a frame arrives, before the switch even checks where it is going, it notes where it came from. By pairing that source MAC address with the port it arrived on, the switch records a new entry. This process is called learning. It happens on every passing frame, not just those addressed to the switch, because the switch builds its table by passively observing traffic rather than being told the network’s layout. Only then does it check the table for the frame’s destination MAC, with two possible outcomes:

• If the destination is unknown, because that device hasn’t sent a frame yet, the switch floods the frame out of all other ports, guaranteeing it reaches the target while other devices ignore it.
• If the destination is known, the switch forwards the frame out of that single port only, keeping the other ports silent.

A switch learns the location of every device after just a few frames of traffic, making flooding the exception rather than the rule. Watch a switch build its table below, forwarding directly when it knows the destination and flooding when it doesn’t.

Both devices share the same core goal, making correct forwarding decisions locally without consulting a central authority, but they build their tables through completely different mechanisms. While a router’s table must be explicitly populated, either by manual configuration or by routing protocols that map the network, a switch’s table is filled in passively, by inference from traffic that was headed somewhere else anyway. And a switch’s table is strictly local in a way a router’s is not, a MAC address has meaning only within the local network segment where it was learned. This is exactly why the two devices divide the internet’s addressing between them, switches move frames within a network using addresses that never leave it, while routers move packets between networks using addresses that do.

One more thing quietly changed once switches took over, CSMA/CD’s whole reason for existing was a cable shared by many machines, where a collision was always possible. That shared cable was half-duplex (one signal on the wire at a time), so send and receive had to take turns, and a collision meant both signals collided on the wire, garbling the data. A switch gives every device its own private wire, so two machines wanting to talk at the same instant don’t collide. Instead, the switch holds one frame in a queue for a few microseconds while it sends the other. Modern Ethernet ports also run full-duplex, sending and receiving on separate internal paths at once, so there’s nothing to collide with even in principle. Collision detection became obsolete, a vestigial mechanism with no remaining use on modern full-duplex links.

Then Wi-Fi brought the shared medium back, in the form of air, where the same contention problem returns in a harder form; the upcoming wireless article will talk about that in detail.

Connecting the Networks

The ARPANET proved packet switching worked, and its success created the next problem. Through the 1970s, other packet networks appeared on entirely different physical media, satellite links (SATNET), packet radio for vehicles (PRNET), local cables inside buildings (the Ethernet you just met). Each had its own packet format, its own maximum packet size, its own addressing scheme. A machine on one network could not reach a machine on another, and demanding that every network rip out its internals and adopt identical ones was never going to happen.

In 1973, Vint Cerf and Bob Kahn designed the architecture that connected them all without unifying any of them. Rather than one network, they proposed an internetwork, a network of networks, which is literally what “the Internet” means. Routers called gateways would sit at the borders between networks, and the whole scheme rested on splitting the problem into two layers with sharply different jobs.

IP (Internet Protocol) is the one thing everyone must agree on, and it is deliberately tiny. It defines a universal address, the IP address, identifying every machine on any participating network, and a universal packet format that every network agrees to carry, tucked inside whatever local format that network uses internally. Crucially, IP promises almost nothing. It is stateless, no router remembers anything about your conversation from one packet to the next, and unreliable, it forwards each packet toward its destination as best it can, and if the packet is lost, IP does not notice or care. Together, those two properties are what connectionless means, there’s no setup phase and nothing shared between one packet and the next, every packet is handled as if it were the only one IP has ever seen. Because the bar is set so low, any network can clear it, copper, fiber, radio, satellite, anything that moves bytes can carry IP. This architecture creates an hourglass shape, with every physical medium on the bottom and every application on the top, interoperating because they all meet at one thin, simple protocol in the middle.

Here’s what that address, and the router’s table matching against it, actually look like. An IP address is nothing more than 32 bits, four bytes, octets in networking tradition, written in decimal and separated by dots, and a route in a router’s table names a network by a prefix, a claim about how many of those leading bits are fixed. /24 means the first 24 bits are fixed and the remaining 8 are free, so matching a route is just comparing bits, an address matches a route if its leading bits, up to the prefix length, equal the route’s leading bits. Router hardware does this comparison as one operation, XOR the address against the route, mask off everything past the prefix length, and check whether what’s left is all zero, XOR gives a 1 at every bit position where the two disagree, so a match is nothing more than “no disagreements inside the fixed part.” This is the same claim an older notation, the subnet mask, makes by spelling out which bits are fixed as a separate dotted-decimal number; 255.255.255.0 marks the same leading 24 bits as /24, just written one octet at a time instead of as a count. The simulator below expands one address, octet by octet, into its 32 bits and runs exactly that comparison against several candidate routes.

That comparison is the whole mechanism, and a real table runs it against every route it holds at once, taking the longest prefix match, whichever matching row fixes the most bits, and falling through to a catch-all default (0.0.0.0/0) only when nothing more specific matches. This single rule is what lets one table stay small: a router doesn’t need one row per address on Earth, only one row per network it has a more specific reason to know about; everything else rides the default toward whichever neighbor is closer to “the rest of the internet.” No router ever needs the whole picture; it only needs to know its own neighborhood plus one direction that’s more likely than the others, and forwarding on that alone is enough, because the next router applies the same partial knowledge, and the one after that, until the packet is close enough for someone to know it exactly. Correct delivery across a network no one fully maps is an emergent property of every hop doing this same small, local thing.

That freely-sized prefix wasn’t the original design. When IP addressing was formalized in 1981, it used a scheme called classful addressing, where an address’s network portion wasn’t an adjustable prefix, but one of three fixed sizes baked into the address itself. A Class A address gave an organization 16 million host addresses, a Class B gave 65,536, and a Class C gave only 256, with nothing in between. Most organizations needed only a few thousand addresses. Under this rigid system, they had to choose: either take a whole Class B (wasting tens of thousands of addresses) or collect multiple separate Class C networks. But because classful routing couldn’t group these separate networks together, every single Class C block had to be listed as a separate entry in the routing tables of every core router on the internet. By the early 1990s, the global routing table was growing faster than router memory could track, and free address space was draining fast. The fix, in 1993, was CIDR (Classless Inter-Domain Routing). This allowed the network portion to be any length rather than just three fixed sizes, so a network could be sized to exactly what an organization needed, and adjacent blocks could collapse into a single routing table entry. The /24 prefix in the simulator above is a CIDR prefix, and this has been the internet’s standard routing scheme ever since.

Where do those blocks actually come from? They follow the same hierarchical delegation as DNS (which we’ll explore in Remembering Names Instead of Numbers), just applied to numbers instead of names. IANA (Internet Assigned Numbers Authority), the same body that oversees the DNS root, holds the entire 32-bit address space. It distributes large blocks of addresses to five regional registries, one for each of North America, Europe, Asia-Pacific, Africa, and Latin America. Each registry carves its share into smaller blocks for the internet service providers in its region, who then slice those blocks further to hand out /24s or smaller to businesses and homes. In fact, your home router’s public IP address is drawn from one of these very blocks. Nobody holds the entire map; each registry only ever needs to know its own corner. This hierarchical delegation is the exact same design that allowed DNS to scale past a single file at Stanford, here applied to the administrative challenge of IP address allocation.

None of this says where the rows themselves come from, the simulator below just hands the router a finished table and watches it get used. The simplest source is a static route, configured manually, “anything for 10.0.0.0/8 goes out line 5,” which is exactly what that row is. That doesn’t scale to a network of any size, so real routers fill most of the table automatically instead, one mechanism for routers inside the same organization, comparing notes on a topology they can all see directly, and a different one for routers in different organizations that share no such trust, each simply announcing to its neighbors what it can reach. Both of those get their full explanation, and the table finally stops being a given, in Where Routes Come From, and Who Carries Your Packets. For now, treat the table as fixed and watch what the router does with it once a packet arrives.

Watch the same rule run inside one router’s hardware, a packet lands on an interface, its header is read, its TTL is decremented, the table is checked, and it goes out the matched line, cycling through a few different destinations to see the match change each time.

One field in that header deserves its own explanation, the time-to-live (TTL), a number the sender sets and every router along the way decrements by one before forwarding. Reach zero, and a router discards the packet on the spot. The value has nothing to do with clock time, it is a hop count, and it exists because in a network with no central authority, a routing table can develop a loop, two routers each honestly believing the other is closer to a destination, forwarding a packet back and forth forever, doubling the load with every unlucky arrival. TTL guarantees that no packet can circulate indefinitely.

When a router kills a TTL-expired packet, it doesn’t just drop it silently, it sends back a small ICMP (Internet Control Message Protocol) message, “Time Exceeded,” to whoever sent the original packet. ICMP is IP’s own maintenance channel, the protocol routers use to report problems back to a source rather than just discarding traffic into the void, and the same channel carries the internet’s simplest diagnostic, ping. Ping sends one kind of ICMP message, an “Echo Request,” to an address, and asks for nothing more than an ICMP “Echo Reply” sent straight back. There’s no port, no handshake, no payload that means anything, just a question (“are you there?”) and an answer, and the round-trip time between sending the request and receiving the reply is the number everyone means when they say “ping” as a noun, a direct, unfiltered measurement of latency to one machine. Here it is running against a real address, eight requests, eight replies, each stamped with how long it took.

That same ICMP Time Exceeded behavior described above is the entire mechanism behind traceroute, a diagnostic tool available on every operating system. It sends the same packet multiple times with TTL set to 1, then 2, then 3, and so on. The TTL=1 packet always dies at the very first router, which obligingly reports itself in the Time Exceeded reply; the TTL=2 packet dies at the second router, and so on, until a packet finally survives long enough to reach the destination itself. Nobody designed traceroute into the protocol, it falls entirely out of a hop counter that was only ever meant to kill loops, run against a real address, and it lists every router between you and it, one line per TTL, each one a little further from you.

That still leaves the other half of the problem flagged above unresolved, every network’s own “maximum packet size.” Each link technology imposes a ceiling on how many bytes it will carry in one unit, its MTU (maximum transmission unit), Ethernet’s is 1500 bytes, and it varies elsewhere. A packet built for a generous link can easily be too large for a stingier one further along the path, and IP’s answer, historically, was fragmentation, a router facing a packet bigger than the next link’s MTU slices it into smaller pieces, each a valid packet in its own right, and the destination reassembles them by the fragment numbers in their headers. It works, but it is expensive, the router has to do real work per fragment, and losing even one fragment means the whole original packet has to be resent.

Modern IP mostly avoids it instead, a sender marks its packets “don’t fragment,” and a router that can’t forward one whole sends back an ICMP message saying so, “packet is too big, try this MTU instead.” The source then shrinks what it sends for the rest of the conversation, a process called Path MTU Discovery, pushing the size problem back to the one place that can actually fix it, the sender. IPv6 goes further and removes router fragmentation from the protocol entirely, PMTUD is the only mechanism left. Watch the same oversized packet meet a narrow link both ways, the old fragmenting router and the modern one that just says no.

Everything so far has assumed one sender, one receiver, unicast, which covers nearly all traffic, but not quite. Your own address’s prefix, the /24 or whatever length from the CIDR discussion above, names your subnet, and a subnet is a physical neighborhood as much as a numeric one, the set of devices sharing one wire or radio channel directly, reachable by MAC address alone, no router in between. A packet addressed to every host on the subnet at once, no exceptions, is a broadcast, useful for the rare cases where a host doesn’t yet know who to ask, DHCP (Dynamic Host Configuration Protocol), handing out an address to a device that has none yet, is one, and ARP (Address Resolution Protocol), asking “who owns this IP on our subnet” to learn a MAC address, is another. A broadcast stops at the boundary of the subnet, routers refuse to forward them. If they did, a single broadcast would flood the entire internet, forcing every computer on Earth to process it.

ARP is worth pausing on, because it’s the exact joint between the two addresses this article has spent so long building separately. Your machine builds an IP packet addressed to some IP, but that packet still has to leave over Ethernet or Wi-Fi, and a frame needs a destination MAC address, not an IP address; IP has no idea a MAC address even exists. So before the first frame of a new conversation can go anywhere, your machine broadcasts a question the entire subnet hears, “Who has this IP? Reply to my IP.” Every other host checks the question against its own address and, unless it’s the one being asked for, says nothing at all; only the owner replies, and it replies unicast, straight back to the asker, not to the whole subnet. The answer is cached for a few minutes, so this whole exchange happens once per neighbor, not once per packet.

And notice which IP address you actually resolve, if the destination IP is outside your own subnet, which almost every request is, you don’t ARP for that distant server’s MAC at all, that would be meaningless, since no frame from your machine can reach a MAC address that isn’t on your own wire. You ARP for your default gateway’s MAC instead, the everyday name for the same border router Cerf and Kahn called a gateway at the top of this section, hand the frame to it, and let it take over from there, one hop at a time, exactly like the router-hop simulator above, just with the very first hop’s address filled in by this mechanism. Watch one host resolve a neighbor’s MAC, then resolve it again already cached, then do the same for a gateway, since off-subnet traffic only ever needs the next hop’s address, not the final one’s.

There is also a middle ground between one recipient and every recipient, multicast, one packet addressed to a group, forwarded only toward the hosts that asked to join that group. It’s the natural shape for feeds like IPTV, with many interested receivers but far fewer than everyone, and routing protocols lean on it internally, though on the public internet you will rarely meet it directly.

The original design gave addresses 32 bits, about 4.3 billion possible values, which seemed inexhaustible for a research network and has haunted the internet ever since, we will meet the consequences (and the workaround running in your home) later in this article. The successor, IPv6, with its effectively unlimited 128-bit addresses, written in the same hexadecimal as MAC addresses, eight colon-separated groups like 2607:f8b0:4004:c07::66, has been rolling out for two decades and now carries almost half of all traffic, the two versions running side by side, another thing the layered design quietly permits.

Making Packet Delivery Reliable

TCP (Transmission Control Protocol) is where all the reliability that IP refused to provide actually lives, and it runs only on the two computers at the ends of the conversation. The routers in between don’t even know it exists. TCP numbers every byte it sends, and the receiver continuously reports back the next byte it expects to receive, an acknowledgment, or ACK. Whatever isn’t acknowledged in time, the sender sends again. Packets that arrive out of order are put back in sequence by their numbers before the data is handed upward. Out of best-effort chaos, TCP manufactures the abstraction every networked program is written against, a reliable, ordered stream of bytes. Doing that requires both ends to remember where they are in the exchange for as long as it lasts, which is why TCP is called connection-oriented, the opposite of IP’s amnesia, and why a TCP conversation has an explicit beginning and an explicit end, while a single IP packet has neither.

One naming note before going further, this article has been saying “packet” for any unit of data at any layer, since the distinction rarely matters for the point being made, but TCP’s own unit does have a name, a segment, the chunk of the byte stream TCP hands down to IP for one trip, sitting alongside “frame” for Ethernet’s unit and “packet” for IP’s.

The explicit beginning is the three-way handshake, a three-segment exchange that synchronizes both sides’ byte numbering before any data flows. Each side picks a random starting sequence number for the bytes it’s about to send, then they trade them, the client sends SYN, seq=5000 (“I’ll start counting my bytes from 5000”), the server replies SYN-ACK, seq=9000, ack=5001 (“I’ll start from 9000; I have everything of yours up to 5000, send 5001 next”), the client replies ACK, ack=9001 (“send me 9001 next”). Three segments, and both sides now agree on where the byte count starts, which is what lets TCP later say precisely which bytes are missing when one goes astray. Watch that exchange run.

ACKs and retransmission answer “did it arrive,” but a packet can arrive without being correct, electrical noise, a bad connector, cosmic radiation hitting a memory chip, can flip a bit in flight without dropping the packet at all. Catching that is a separate, older, and much simpler mechanism, the checksum. The sender runs a small arithmetic function over the bytes it’s sending and appends the result; the receiver runs the identical function over the bytes it received and compares. Any disagreement means something changed in transit, and the receiver just discards the packet, silently, exactly as if it had never arrived, so the sender’s ordinary retransmission machinery, seeing no acknowledgment, sends it again.

It is deliberately not built to identify or repair the error, only to notice one, cheaply, on every single frame and packet, which is why the same idea reappears at almost every layer, Ethernet’s frame check sequence, IP’s header checksum, TCP’s own checksum over the segment. Notice what this does and doesn’t protect against, it catches accidental corruption from a noisy link, not a deliberate tamperer who recomputes the checksum to match their own forged bytes, that threat is what TLS, much later in this article, actually solves. Watch a clean transmission and a corrupted one side by side, and see the receiver catch the second:

TCP also decides how much to keep in flight. The sender maintains a sliding window, a cap on how many unacknowledged packets it may have outstanding at once; hit the cap, and it must pause and wait. The window doesn’t move on its own, an ACK moves it, each one confirming the oldest outstanding packet lets a new one take its place at the far edge, which is the literal reason it’s called sliding, advancing one confirmed packet at a time, and that discipline is what keeps a fast sender from drowning a slow receiver. And when packets go missing, TCP reads the loss as a signal, some router’s queue along the path is overflowing, and shrinks its window to back off. This reflex, congestion control, was added the hard way. In October 1986, the link between Lawrence Berkeley Lab and UC Berkeley, 400 meters apart, collapsed from 32,000 bits per second to 40, a thousandfold drop, as every sender responded to loss by retransmitting harder, a feedback spiral called congestion collapse. Van Jacobson’s fix, back off multiplicatively on loss, probe forward gently on success, still runs in essentially every TCP implementation on Earth. Billions of connections, each following this same local rule with no coordinator, is what keeps the shared network from strangling itself, the same emergent cooperation we saw in packet routing, applied to capacity.

The simulator below shows a TCP sender streaming packets under a sliding window. Watch what happens when a packet is lost, the receiver keeps acknowledging the last in-order byte it has, and that burst of duplicate ACKs tips off the sender to retransmit the missing packet without waiting for a timeout.

Two refinements complete the transport picture. An IP address identifies a machine, but a machine runs many programs at once, so TCP adds a port number, and the combination of address and port delivers each byte stream to the right program; a web server conventionally listens on port 443 for encrypted traffic. That combination, an IP address plus a port plus the protocol, is what a socket names, the actual endpoint an application opens rather than merely the machine it lives on. The server’s port is fixed so clients know where to knock, but the client side needs a port too, since a reply has to come back to something more specific than just your machine, so your operating system picks one at random from a range set aside for exactly this, an ephemeral port, borrowed for the life of one connection and handed back afterward. That’s the 54211 sitting in the source port field of the packet diagram near the end of this article, not a port anything was listening on, just the number your machine happened to draw for that one request.

And for applications where retransmitting stale data is worse than losing it, a live video call has no use for a frame from two seconds ago, there is UDP (User Datagram Protocol), a thin alternative that adds ports to IP and nothing else, leaving each application to handle loss in whatever way suits it. UDP’s own unit is a datagram (joining Ethernet’s frame, IP’s packet, and TCP’s segment). The word itself doubles as a description, a self-contained parcel with everything it needs addressed on it, sent with no setup and no memory of the one before it. UDP is connectionless for the same reason IP is, it keeps no state and requires no setup, simply adding enough addressing to reach the right program. That’s the whole tradeoff, not a lesser version of TCP, but a different bet. TCP for a web page, an email, or a file, where an incomplete copy is worse than a slightly late one; UDP for a video call, a multiplayer game, or a DNS query, where a late answer is worse than a missing one (or where the application will just request the latest state anyway).

TCP/IP became the ARPANET’s official protocol on January 1, 1983, and the definition of the internet has been simple ever since, it is the set of all networks that agree to carry IP packets. There is no membership office. You join the internet by speaking its protocol.

Where Routes Come From, and Who Carries Your Packets

One question has been quietly deferred since the packet-switching section, a router forwards each packet down “the line that leads closer to the destination,” but how does it know which line that is? The answer splits cleanly along the same boundary as everything else in this article, one set of rules for inside an organization, a different one for between organizations.

Inside one organization’s network, routers run an Interior Gateway Protocol (IGP), exchanging their own directly observed topology, which links are up, how congested each one is, and computing routes automatically. Two families dominate, and they disagree about a basic question, does a router need to see the whole network, or is a secondhand number enough?

Link-state protocols like OSPF (Open Shortest Path First) answer “see the whole network.” Every router floods a description of its own local connections to every other router, so each one ends up holding an identical map of the whole topology and runs the same shortest-path calculation independently.

Distance-vector protocols like the older RIP (Routing Information Protocol) answer “a number is enough.” Each router tells its neighbors only “I can reach this network in N hops,” never seeing the map itself, just trusting the secondhand count and adding one. It’s a far smaller exchange than flooding a map, but it also means a router has no way to check whether a neighbor’s number is still true. Try both below. Each cycle opens with an ordinary packet crossing all three routers first, the same longest prefix match lookup as the single router simulator earlier, just run three times in a row by three routers that never compare notes, so watch how little any one of them actually knows.

When a link fails, every router’s table is briefly wrong until the new state finishes propagating; as we saw in the packet-switching mesh, convergence is the industry’s word for that catching-up process. Link-state converges in exactly the two flooded messages you just watched, because a flood carries the actual topology change, not a guess. Distance-vector has no such certainty to fall back on, and the RIP tab shows the failure mode: two neighbors briefly routing through each other, each trusting the other’s now-stale number, while a real packet for that destination bounces between them until its TTL kills it. Production deployments bolt mitigations onto RIP, but none of them makes a secondhand number converge as fast as a verified map, which is why OSPF displaced it in most production networks. Either way, this is a single administrator’s problem to solve, one company’s routers, one company’s decision about which protocol to run.

Things get much harder between organizations. Without a single administrator or shared trust, the solution is where the internet’s decentralized character actually takes shape.

That patchwork of organizations didn’t exist yet when TCP/IP became official in 1983, the network was still essentially one federally funded system. What actually split it apart was the National Science Foundation’s NSFNET, built in 1985 as a backbone connecting regional academic networks, each already run by a different university consortium, into one national network. For its first several years, NSFNET’s Acceptable Use Policy barred commercial traffic outright, no business email, no advertising, research and education only. That restriction lifted in 1991, and when NSFNET itself was shut down in 1995, its backbone role passed not to one successor but to several competing commercial carriers, who had no reason to merge and every reason to stay separate, rival companies selling the same service to the same customers. That handoff, a government network dissolving into a market of competitors, is the moment the internet stopped having an owner and became the patchwork BGP now holds together.

The internet is physically a patchwork of tens of thousands of independently operated networks, called autonomous systems, your home internet provider, a university, a national telecom, a cloud company. They exchange routes using the Border Gateway Protocol (BGP). Each network announces to its neighbors, “I can reach these blocks of addresses,” and passes along, with itself appended to the path, the announcements it hears from others. Routes to every corner of the internet propagate from network to network, and each network chooses among the paths it has heard based not on speed but on business policy, money changes hands. Strip the business policy away and the shortest-path tiebreaker underneath it is simple enough to watch directly, one route, spreading hop by hop, each hop appending itself to the path, until a router two different ways away has to pick between them.

A small provider pays a larger one for transit, carriage to the whole internet, while networks of similar size peer, exchanging traffic between their customers for free, settlement-free in the industry’s terms, because it saves both sides transit fees, often meeting at internet exchange points, buildings where hundreds of networks plug into a common switching fabric, the largest, like DE-CIX in Frankfurt and AMS-IX in Amsterdam, connect on the order of a thousand. These two contracts are exactly what “business policy” meant in the route selection above. For any destination, a route through a neighbor falls into one of three cost classes, via a customer, that customer pays you to carry the traffic; via a peer, free; via a provider, you pay for every byte. So networks configure BGP to prefer customer routes over peer routes over provider routes, even when the paying route is longer, and shortest AS path decides only among routes of equal business standing.

At the top sit a handful of tier-1 backbones that peer with each other and pay no one, companies most people have never heard of, Lumen, Arelion, NTT, and a few others, and across the oceans run roughly 600 submarine fiber cables carrying essentially all intercontinental traffic. The internet holds together not by any authority, but by this mesh of contracts, handshakes, and BGP announcements.

Those cables are the telegraph’s ocean-floor wire, several generations on. The first transatlantic telephone cable, TAT-1, went into service in 1956, coaxial copper carrying 36 voice circuits, with an amplifier spliced in roughly every 70 kilometers to boost the signal before it faded into noise. That’s the telegraph section’s analog problem all over again, an amplifier can’t tell signal from noise, so it boosts both, and unlike a telegraph pulse, a voice waveform can’t be cleanly regenerated back to its original shape at each hop. Fiber broke that tradeoff. TAT-8, laid in 1988, was the first transatlantic fiber cable, and it didn’t just improve on TAT-1, it made it obsolete overnight, two glass strands carrying tens of thousands of voice-equivalent circuits, because light in glass can be sliced into far more independent channels than voltage on copper ever could. Every transatlantic cable built since has been fiber; the roughly 600 running today are TAT-8’s descendants, not TAT-1’s.

None of this works unless the light actually stays in the glass. A fiber’s core is glass of a slightly higher refractive index than the cladding wrapped around it, and light traveling down the core meets that boundary at a glancing angle, shallower than the critical angle, so instead of refracting through, it reflects back in, completely. That completeness is the whole trick. An ordinary mirror absorbs a fraction of a percent per bounce, which would extinguish a signal that bounces millions of times per kilometer; total internal reflection loses nothing at the boundary, which is why a hair-thin glass thread can guide a pulse for around a hundred kilometers, through every sag and curve of the seabed, before an amplifier needs to touch it.

The slicing of light into independent channels has a name, wavelength-division multiplexing, and the simulator below shows it in action. Each laser keys its own bit stream onto its own wavelength of light, and a combiner feeds them all into one strand. Because the glass acts as a linear medium, the different waves superpose, literally adding their amplitudes together, and travel through the same core without mixing or interfering, allowing a splitter at the far end to filter each wavelength back out intact. Rather than trying to make a single laser blink faster, the strand simply carries several streams in parallel using different colors. Adding a wavelength multiplies the throughput of glass that is already lying on the seabed.

Nothing in BGP’s mechanism says an address has to be announced from only one place, and giving that up on purpose is how anycast works. Multiple servers, often on different continents, are all configured with the identical IP address, and each one’s network announces a route to it exactly as if it were the sole owner. BGP doesn’t know or care that it’s hearing the same address from São Paulo, London, and Tokyo at once, it just does what it always does, keeps whichever announcement has the shortest path, which in practice means each client’s traffic lands on whichever copy is topologically nearest to it. Two people in different cities, requesting the same address, get routed to different physical machines, with nothing about the DNS lookup or the client’s own configuration hinting that this happened. Watch three clients, on three different continents, send to the same address and each land on a different server.

This routing-level approach, directing traffic to the nearest machine sharing a single IP address, is one of two key techniques behind a content delivery network (CDN). CDNs like Cloudflare (this site included) or Akamai run copies of the same content, video, images, whole websites, on servers scattered across the globe specifically so requests get answered from nearby hardware instead of one, possibly distant, origin server. The other technique, often layered on top or used instead is simpler, geo-aware name servers that look at where a query came from and hand back the address of a nearby data center rather than the same answer to everyone, a trick that lives inside DNS, the naming system in Remembering Names Instead of Numbers. Either way, the payoff traces straight back to the very first idea in this article, latency is a floor set by the speed of light, and the only way to beat it is to move the data closer to the reader before they ask.

BGP’s design is startlingly trusting, networks largely believe what their neighbors announce. In 2008, Pakistan Telecom, intending to block YouTube domestically, announced a more specific route to YouTube’s addresses than YouTube’s own. The announcement leaked past its borders, propagated worldwide in minutes, and much of the planet’s YouTube traffic obediently flowed into Pakistan and vanished. Incidents like this are why a service can occasionally disappear from half the world at once. They are also why engineers have spent years building cryptographic verification into BGP, an effort called RPKI (Resource Public Key Infrastructure) that lets a router check a route announcement against a signed registry rather than taking it on faith. What a cryptographic signature is, and why it can be checked but not forged, is exactly the machinery we’ll build up in Exchanging Secrets over Public Wires.

Your Private Home Network

Your home compresses several of these ideas into one plastic box. The router on your shelf runs a small Ethernet switch, the same MAC-learning trick from One Shared Wire for the Whole Office, plus a Wi-Fi radio for the wireless side; it hands each device an address when it joins, via the DHCP broadcast from Connecting the Networks, and the same reply carries the two other things a fresh device needs and nobody ever types in, the gateway to send off-subnet traffic to and the address of a DNS resolver (the name-lookup system we will explore in Remembering Names Instead of Numbers). And, because 32-bit IPv4 addresses ran scarce, those are private addresses that mean nothing outside your home. A handful of blocks are set aside by convention for exactly this, never handed out publicly and never routed across the internet, which is what lets every one of them be reused endlessly. One more reserved block rides along in the table below, addresses your machine keeps entirely to itself, and we’ll come back to it in a moment.

None of the first three is ever routed on the public internet, so your router’s 192.168.1.5 and a stranger’s 192.168.1.5 on the other side of the planet are different devices that never once collide, because neither packet carrying that address ever leaves the private network it was issued on. The router shares its single public address, itself assigned by your ISP’s DHCP, the same mechanism one network up, among all your devices by rewriting the addresses on packets as they pass through, NAT (Network Address Translation), keeping a table of which inside conversation each outside reply belongs to. Watch two unrelated homes reuse the identical private address and see why NAT keeps them from ever colliding, then watch a second device in one home share its router’s single public address.

NAT has a blind spot that quietly reshaped the internet. Because the router only records conversations started from the inside, it drops all unsolicited incoming traffic. This kills the symmetrical server role, your laptop can reach any server, but nothing can reach your laptop uninvited. It is why hosting from home requires manually setting up “port forwarding” (telling the router which internal machine should receive outside traffic on a specific port), and tracking your public IP address as your ISP periodically rotates it to save addresses. It is also why peer-to-peer apps like video calls must use complex workarounds (like having both sides send packets at once so both routers think their user started the conversation) to connect directly. A temporary workaround for address scarcity ended up sorting the internet into two classes, those that serve, and those that only ask.

The last row, 127.0.0.0/8, is more local still, a packet sent to 127.0.0.1, conventionally called localhost, never reaches your network card at all. Your own operating system loops it straight back to whatever is listening on your own machine, which is why a development server you start on your laptop answers at 127.0.0.1:3000 from that laptop, and nowhere else on Earth. And it isn’t just 127.0.0.1, the entire block loops back, all 16.7 million addresses of it, the same size as the largest private block, reserved for talking to exactly one machine, an extravagance from an era when nobody imagined 32 bits of address space could run out.

One layering detail is worth keeping, your device carries two addresses at once, a MAC address belonging to its network hardware, saying which machine on this cable or channel, and an IP address, assigned by whichever network you join, meaningful end to end. The MAC address never leaves your local network; the IP address is what the far end of the world routes on. We will see both riding in the same packet when we trace a click end to end in What Actually Happens When You Click a Link.

Remembering Names Instead of Numbers

Routers deliver packets to numeric addresses like 208.80.154.224, but those numbers are nearly impossible for us to memorize. Without names, you would need a personal diary just to keep track of the IP addresses of websites you like to visit. In the ARPANET days, the entire mapping lived in one file, HOSTS.TXT, maintained by hand at the Stanford Research Institute under Elizabeth Feinler, and every computer on the network periodically downloaded a fresh copy. By the early 1980s this was failing exactly as you’d expect, one office editing one file could not keep pace with an exponentially growing network, and everyone fetching that file from one place was itself a bottleneck.

These are a few lines from the 27 March 1984 version of that file, one entry per machine, listing its address (or addresses), its names, its hardware and operating system, and the protocols it spoke, every field curated by hand.

; DoD Internet Host Table
;  27-Mar-84
;
; Changes, corrections, comments or questions to (HOSTMASTER@SRI-NIC)

NET : 10.0.0.0 : ARPANET :
HOST : 10.0.0.51, 26.0.0.73 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 : TOPS20 : TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
HOST : 10.0.0.1 : UCLA-CS.ARPA,UCLA-CS,UCLA-CECS : VAX-11/750 : LOCUS : TCP/TELNET,TCP/FTP,TCP/SMTP :
HOST : 10.0.0.6 : MIT-MULTICS.ARPA,MIT-MULTICS,MULTICS : HONEYWELL-DPS-8/70M : MULTICS : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,TCP/ECHO,TCP/DISCARD,ICMP :
HOST : 10.0.0.4, 192.5.12.21 : UTAH-CS.ARPA,UTAH-CS : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP :

The first entry is the file describing its own home: SRI-NIC is the very machine everyone fetched HOSTS.TXT from, and HOSTMASTER@SRI-NIC in the header was Feinler’s group. To look up a name, a computer simply searched its local copy of this file, and any machine missing from the file effectively did not exist.

In 1983, Paul Mockapetris designed its replacement, the Domain Name System (DNS), built on delegation. The namespace is a hierarchy read right to left, for en.wikipedia.org, the root of the hierarchy knows only who runs top-level domains like org; the org servers know only who runs wikipedia.org; and Wikipedia’s own name servers hold the actual answer for en.wikipedia.org. Nobody stores the whole map; instead, the namespace is partitioned into administrative boundaries called zones. Each organization controls the authoritative name servers for its own zone (e.g., a company managing yourdomain.com) and can change its records or delegate sub-zones (like sub.yourdomain.com) to others without asking anyone. To look up a name, your device asks a recursive resolver, typically run by your internet provider or a public one like Cloudflare’s 1.1.1.1, which walks the chain of delegations on your behalf and returns the final address.

Walking that chain for en.wikipedia.org looks like this, each answer telling the resolver exactly one step further down:

1. Resolver asks a root server: “who is en.wikipedia.org?” Root doesn’t know, but answers: “I don’t hold org, but here’s who does,” and hands back the address of the .org name servers.
2. Resolver asks an .org server the same question. It doesn’t know en.wikipedia.org either, but answers: “Wikipedia runs its own servers, here they are,” and hands back the address of wikipedia.org’s name servers.
3. Resolver asks Wikipedia’s own name server, the last delegation in the chain, and finally gets a real answer: en.wikipedia.org is at 91.198.174.192, valid for 3600 seconds.

That 3600 is also called a TTL, confusingly, the same three letters as the IP hop counter earlier, but here it means a lifetime in seconds, not a number of routers, permission to cache the answer for an hour before asking again. The resolver hands 91.198.174.192 back to your browser, and every other request for en.wikipedia.org from anyone using that resolver is answered instantly from the cache, no chain to walk, until the hour is up.

At the internet’s scale, walking that chain for every lookup would crush the upper levels, so every answer carries a TTL and is cached close to the asker, by the browser or operating system, and especially by the recursive resolver serving many people. A home router may forward DNS or run a resolver too, but ordinary packet routing has nothing to do with the cache. Popular names are almost always answered from a cache a few milliseconds away, and the root servers rarely hear about anything twice.

That walk isn’t hidden machinery, you can run it yourself. Below, the same three delegations are asked by hand with dig, the standard DNS query tool, one question per server, the root answers with the .org servers, .org answers with Wikipedia’s own name servers, and those finally answer with an address, exactly the chain the simulator just walked.

DNS has done exactly one job, turn the name into a number. With 91.198.174.192 in hand, your browser can finally open a connection to that address, conventionally on port 443 for the encrypted web. The next packets are no longer DNS questions; they are TCP packets addressed to the web server, which is the handoff the simulator shows at the end.

None of that hierarchy is automatic to join, and it’s worth seeing how a name gets onto it, since the mechanism is just more delegation. You buy yourdomain.com from a registrar, an accredited reseller for whichever registry runs that top-level domain, Verisign for .com. The registrar’s actual job is one write into the registry’s zone, an NS record naming the name servers you’ve designated as authoritative for your domain, the exact delegation a resolver follows when it asks the .com servers who runs your name. Those name servers, run by your registrar, a provider like Cloudflare or Route 53, or a machine of your own, hold your domain’s zone file, records you control directly. The one that answers “how do I point my domain at my server” is the A record (or AAAA for IPv6), a line stating that yourdomain.com lives at, say, 192.0.2.7. Add it, wait out whatever TTL the last answer was cached under, and every resolver on Earth starts sending traffic for your name to your machine; no approval needed, just one write into a chain of delegations built for exactly this. This last step is also where a CDN’s geo-aware trick from the anycast section lives, nothing forces a name server to give every asker the same answer, so it’s free to reply with whichever data center’s address sits closest to the query.

The price of caching is staleness. When a site moves to a new address, the old answer lingers in caches worldwide until its TTL runs out. This lag is why DNS changes take time to propagate, and why a surprising fraction of mysterious outages, in home networks and billion-dollar clouds alike, trace back to DNS. Because a name lookup is the first step of nearly every connection, it remains the silent, load-bearing foundation of the entire internet.

DNS as designed in 1983 carries the same unguarded trust BGP does, when a resolver asks a question, it simply believes whichever answer arrives first, matching the query it sent. In 2008, researcher Dan Kaminsky showed just how little it took to abuse that. A resolver identifies which answer belongs to which question with a 16-bit transaction ID, only 65,536 possibilities, and an attacker who can guess it before the real answer arrives can hand the resolver a forged reply instead, one that doesn’t just answer the question asked, but tacks on an unrequested bonus, “and by the way, here are the real name servers for the rest of yourbank.com, from now on, ask them.” A resolver has no reason to be suspicious of a gift it didn’t ask for and takes it anyway. Get there first, and the resolver caches the lie for as long as its attacker-chosen TTL says to, quietly redirecting every one of that resolver’s users, for that entire domain, not just the one name that was queried.

The fix, DNSSEC (Domain Name System Security Extensions), closes the gap, each zone cryptographically signs its own records, and a resolver validates the signature chain up to a root key it already trusts (using the same signature concepts we will cover in Exchanging Secrets over Public Wires). A forged answer without a valid signature is simply discarded, unbelieved. It has been available for over a decade, and like IPv6, adoption is still catching up to the incentive to run it.

Crucially, DNSSEC only guarantees authenticity (that the answer wasn’t tampered with); it does not encrypt the query, so anyone along the path can still see which domains you are looking up. To close this privacy gap, modern operating systems and browsers increasingly encrypt the lookup itself by wrapping DNS queries inside TLS or HTTP, protocols known as DNS over TLS (DoT) and DNS over HTTPS (DoH).

Creating a User Interface for the Internet

By the end of the 1980s the plumbing was complete, IP routed packets worldwide, TCP made delivery reliable, Ethernet wired up buildings, DNS resolved names. Yet the internet remained a specialist’s tool. Retrieving information meant knowing which machine held it, then driving command-line tools to log in or transfer files. The infrastructure could move bytes anywhere; what it lacked was a way for a non-expert to find and read anything.

In 1989, Tim Berners-Lee, a software engineer at CERN, the European particle physics laboratory, proposed a document-sharing system for scientists, and by 1991 the World Wide Web was running. It rested on three deliberately simple inventions:

1. HTML (HyperText Markup Language), a document format whose defining feature is the link, any word in any document can point at any other document, anywhere on the internet.
2. URL (Uniform Resource Locator), a global address for a document (like https://en.wikipedia.org/wiki/Internet), naming the protocol (https), the server (en.wikipedia.org, resolved via DNS), and the document’s path on it (/wiki/Internet). One piece is missing on purpose, the port. Each protocol carries a default port, 443 for https and 80 for plain http, so the browser fills it in from the scheme, and https://en.wikipedia.org:443/wiki/Internet is the same address written out in full. That’s why typing a bare address into a browser just works, the scheme alone tells it which door to knock on.
3. HTTP (HyperText Transfer Protocol), a minimal request-response protocol on top of TCP, the client says GET /page, and the server’s reply opens with a status code before the document itself, 200 OK when it succeeds, 404 Not Found when the requested document does not exist, and 500 Internal Server Error when the server itself runs into a problem.

Each piece leans on a layer we have already built, URLs lean on DNS, HTTP leans on TCP, TCP leans on IP. Berners-Lee didn’t have to ask permission or upgrade a single router; the layers below were already there, and anyone was free to build on top of them. That permissionless quality, a direct consequence of keeping the network’s middle simple and its intelligence at the edges, is why the web went from one machine at CERN to the world in a few years, and why a student’s video-calling experiment or a new webapp can deploy globally today without anyone’s approval.

The openness runs deeper than the architecture, it’s written down. Every protocol in this article, IP, TCP, DNS, HTTP, is specified in an RFC (Request for Comments), a freely readable document anyone can implement without paying a fee or asking a license. The modest name is original, the first RFCs in 1969 really were memos circulated among the ARPANET’s builders inviting comment, and the culture they set persisted as the informal process hardened into the IETF (Internet Engineering Task Force), the volunteer body that has standardized internet protocols since 1986. Even the well-known defaults are just RFC text made habit, port 80 and port 443 are simply the numbers the relevant RFCs registered with IANA for HTTP and HTTPS. This is what “open standard” means concretely, the complete rules of the internet sit in public documents, and a compatible implementation, whether a browser, a server, or an operating system’s TCP stack, is anyone’s to write.

The web reached the public through graphical browsers, NCSA Mosaic (1993), built by Marc Andreessen and Eric Bina at the University of Illinois, put images alongside text and made the web feel like a place rather than a protocol, and Netscape Navigator (1994), from the same team gone commercial, carried it into homes and set off the dot-com boom. What browsers themselves grew into, a second operating system running strangers’ code safely, is the subject of the upcoming web browser article; here, one more problem the web’s success exposed needs solving first.

Exchanging Secrets over Public Wires

Commerce followed the browsers, and commerce collided with an assumption baked in from the ARPANET days, every protocol so far sends data as plain, readable bytes. Your packets pass through your router, your internet provider, and a dozen networks owned by strangers, and any machine along the path can read every byte, or quietly alter it in transit. That was tolerable among research labs sharing physics papers. It is intolerable for a credit card number.

Strip the problem to first principles and it looks unsolvable, two parties who have never met must agree on a secret, while communicating only over a channel that everyone can read. Anything one sends the other to establish the secret, an eavesdropper sees too.

The way out is public-key cryptography, developed in the 1970s. Certain mathematical operations are easy to perform but computationally infeasible to reverse, and from these you can build a key pair, two linked keys where data encrypted with one can only be decrypted with the other. The public key you hand to the world; the private key never leaves your server. Now anyone can encrypt a message that only you can read, with no prior secret, the eavesdropper sees the public key and the scrambled traffic and can do nothing with either. The same pair works in reverse: instead of encrypting a message that only the private key can decrypt, you can use the private key to generate a proof that anyone holding the public key can verify. Useless for secrecy, but it proves the private key’s holder issued it, because nobody else could have. That is a signature, a statement only you could have made and anyone can check. Two details separate this picture from real signatures, you sign a hash of the message, a short fingerprint computed from every byte of it, so the signature also proves nothing was altered along the way; and modern schemes, ECDSA and Ed25519 among them, reach the same guarantee through different mathematics than traditional RSA. The contract is what survives every change of scheme, the private key signs, the public key verifies, and the signature binds the exact bytes signed.

One gap remains. When your browser receives a public key claiming to belong to your bank, who vouches for that claim? An attacker sitting in the middle could present their key instead and decrypt everything. This is closed by certificates. A small set of organizations called certificate authorities, whose own public keys ship inside every browser, verify a server’s identity and cryptographically sign a statement binding that identity to its public key; that signed statement is the certificate. A certificate is rarely signed directly by one of those, instead it’s signed by an intermediate authority, whose own certificate is signed by the root, so your browser doesn’t check one signature, it checks a chain, climbing from the certificate in hand up through each issuer until it either reaches a root it already carries, verified, or runs out of chain to climb, which produces the full-page security warnings you have seen. Watch the browser walk that chain, once when it succeeds and once when it doesn’t.

Netscape assembled these pieces into SSL (Secure Sockets Layer) in 1994, later standardized as TLS (Transport Layer Security). It slots cleanly between TCP and HTTP: at the start of a connection, browser and server perform a handshake. The key agreement at its heart is Diffie-Hellman, and I’ll explain the concept using small numbers.

Both sides start from two public constants, here g = 5 and p = 23. The browser opens with a ClientHello proposing ciphers, and alongside it a key share, computed from a private number it picks and never sends, say a = 6, giving the share A = 5⁶ mod 23 = 8. The server picks its own private number, say b = 15, and answers with its chosen cipher, its certificate, and its own share B = 5¹⁵ mod 23 = 19, signed with the certificate’s private key, so a machine in the middle cannot swap in a share it controls. Then each side raises the share it received to its own private number, the browser computes 19⁶ mod 23 = 2, the server computes 8¹⁵ mod 23 = 2, and they land on the same value because both are 5⁹⁰ mod 23. That value is the session key, computed independently at both ends and never sent across a wire that carried only 8 and 19.

An eavesdropper holding both shares must recover a private number to get any further, which power of 5 gives 8, mod 23? That is the discrete logarithm problem, answerable by trial at this size, computationally infeasible at real sizes, where p runs to hundreds of digits. What browsers actually run is the elliptic-curve variant of the same exchange, which swaps modular exponentiation for point arithmetic on a curve, a different one-way operation that reaches equivalent security with far smaller numbers, and changes nothing else, the same private numbers kept, the same shares exchanged, the same key derived independently at both ends. Watch the exchange run with an eavesdropper on the wire, recording every number that crosses and still ending up with nothing.

Public-key math is too slow to run on every byte of a conversation, so it is only ever used for this one exchange; the session key is a plain symmetric key, the same key encrypts and decrypts, cheap enough to run on the full request and response, and both sides encrypt everything both ways with it from here on.

HTTP spoken through this channel is HTTPS, and the padlock in your address bar means exactly this and no more, the machines between you and the server can still see which server you talk to, when, and how much data moves, but not what is said. Your passwords and messages cross hostile territory unreadable, which is why the web has moved almost entirely to HTTPS and browsers now flag plain HTTP as a defect. Here is that whole exchange, ending in the encrypted request and response it exists to protect.

Notice what’s actually happening to the bytes as they leave your machine to make this possible. Each layer wraps the layer above it in its own header, and unwraps only its own layer on arrival. An HTTP request ends up riding inside a TLS record, inside a TCP segment, inside an IP packet, inside an Ethernet or Wi-Fi frame, one parcel inside another, and at every hop along the way, a router or switch touches only the outermost wrapper. The simulator below builds up that nesting layer by layer.

The same machinery, pushed one layer down, gives you the VPN (Virtual Private Network). Where TLS encrypts one application’s byte stream, a VPN encrypts entire IP packets and wraps each one inside a new packet addressed to the VPN server, encapsulation again, a whole packet riding as the payload of another. All your traffic detours through that server, which unwraps each packet and forwards it onward as if it had originated there. Notice precisely what this changes, your internet provider now sees only encrypted traffic to one address, and the sites you visit see the VPN server’s address instead of yours, but the VPN operator inherits exactly the view your provider used to have. A VPN does not add security in some absolute sense; it relocates the point of trust, which is why who runs the server matters more than any encryption claim in the marketing.

The construction’s original purpose was corporate, and still is, a remote laptop tunneling into the office network behaves as though it were plugged in at a desk there, private addresses and all. The simulator below traces one request through the tunnel, watch what each party along the path can actually read.

What Actually Happens When You Click a Link

All of these protocols run, essentially unchanged, every time you load a page. Tracing one click from end to end:

1. You click a link pointing to https://en.wikipedia.org. Your browser extracts the hostname and asks DNS for its IP address, which is answered in milliseconds from a nearby cache or by walking the hierarchy.
2. Your browser opens a TCP connection to that address on port 443, the same three-way handshake from the reliability section, three segments agreeing on byte numbering before any data flows.
3. The TLS handshake runs over that connection, the certificate is checked, a session key agreed.
4. The browser sends its encrypted request, GET /wiki/Internet.
5. The response, hundreds of kilobytes of HTML, returns as dozens of IP packets, individually routed, possibly reordered, occasionally lost and retransmitted, reassembled by TCP into an exact byte stream, decrypted by TLS, and parsed and painted by the browser.

This chain is also the diagnostic the introduction promised, whether a dead page is the website’s fault or something local, because each step fails in its own recognizable way. If nothing loads on any site, the failure sits in front of step 1, your Wi-Fi, your router, or your provider’s link, and a ping to an address you know, like 1.1.1.1, tells you in one round trip whether you can reach past your own walls. If other sites work but this name won’t resolve, the problem is DNS, a stale cache or the site’s own records. If the name resolves but the connection in step 2 times out, the server or a network on the way to it is down, and traceroute shows how far your packets get before they die. A full-page certificate warning is step 3 failing, the chain climb from the certificate section refusing to reach a trusted root. And if all of it succeeds and the reply comes back 500, your request crossed the world intact; the failure is finally, provably, inside the server itself.

Notice steps 1 through 3 are pure round trips, latency paid before a single byte of the page moves, which is why even a fast connection can feel sluggish to start. And notice that the GET request in step 4 is riding inside exactly the nesting the earlier simulator built up, HTTP inside TLS inside TCP inside IP inside an Ethernet or Wi-Fi frame, unwrapped one layer at a time as it arrives. If we peel back the encryption, the headers on that single packet, just a sequence of raw bytes, contain every instruction needed to guide it across the world.

Every router between you and Wikipedia reads only the IP row, matches the destination address against its table, and forwards, exactly as the routing-table example above, it never looks past byte 20. TCP’s row is invisible to them, opened only at the two endpoints; TLS encrypts the payload those headers are wrapped around, but never the headers themselves, which is why an eavesdropper can see which server and how much data, the point made earlier about HTTPS, without seeing the request.

Reading the table bottom-up summarizes this article, each layer exists to hide a specific limitation of the layer beneath it. The link layer hides the physics of shared cables and crowded airwaves. IP hides the boundaries between thousands of separately owned networks. TCP hides loss, duplication, and reordering. TLS hides the conversation from eavesdroppers. HTTP hides all of it behind a request and a response.

You will also hear this same stack described with different names and more boxes, the OSI model, seven layers instead of five. In 1984 the International Organization for Standardization set out to define a vendor-neutral network architecture by committee, before TCP/IP had already won in practice, and split things more finely than the running internet ended up needing, physical and data link where this article has one link layer, and session, presentation, and application where this article has one application layer. TCP/IP shipped first, ran the actual internet, and never adopted OSI’s extra seams. What survived from OSI is its vocabulary, not its architecture, engineers still say “layer 2” for switching, “layer 3” for routing, and “layer 7” for anything application-aware, like a firewall that reads HTTP headers, because those numbers became industry shorthand long after the model itself was bypassed in practice.

This layering is also why the internet can evolve while running. Because each layer depends only on the interface of the one below, any layer can be swapped without touching the others. Physical links can upgrade from copper to fiber, or wires to Wi-Fi, without requiring any changes to the applications on top. The web’s newest protocol, HTTP/3, even replaced TCP itself, rebuilding reliability and encryption together on top of UDP in a protocol called QUIC (originally short for Quick UDP Internet Connections, though the standard now treats it as a name rather than an acronym). Two specific costs justified that, both visible in what you’ve already seen. First, a browser opens one connection and multiplexes dozens of requests over it, but TCP’s reliability is a single ordered byte stream, so one lost packet stalls every request behind it on that connection, even ones that have nothing to do with the missing bytes; QUIC gives each request its own independently-acknowledged stream, so a loss only stalls the stream it belongs to. Second, the handshake in step 2 and the TLS handshake in step 3 above ran one after the other, two round trips of pure latency before a single HTTP byte moved; QUIC folds transport setup and encryption into a single handshake, and on a repeat visit to a server it remembers, into none at all. It also stops keying a connection to the IP and port tuple the way TCP does, so it survives your phone switching from Wi-Fi to cellular mid-download, something the three-way handshake above has no way to do, since a new IP means a new tuple means, to TCP, a new connection.

The simulator below runs all three comparisons in sequence, the same client and server, first setting up a connection, then losing one packet out of three multiplexed requests, then switching networks mid-download.

None of this required anyone’s permission. IP’s only promise is to deliver a payload to a port; it has no opinion on what’s inside, which means the application layer was never a fixed list, HTTP is simply the protocol that happened to win for browsing documents. Anyone who controls both endpoints is free to define their own framing over TCP or UDP when the existing options don’t fit, and plenty have, SSH defines its own protocol for remote shells, SMTP for mail, MQTT is a deliberately tiny publish-subscribe protocol built for IoT devices too constrained to parse HTTP headers, WebRTC lets two browsers exchange audio and video directly over UDP without a server relaying it, and multiplayer game engines routinely write custom UDP protocols that, like the tradeoff above, discard stale position updates rather than retransmit them. QUIC itself is the clearest case, Google first deployed it as a proprietary protocol running only between Chrome and Google’s own servers, over ordinary UDP, years before the IETF standardized it as HTTP/3; nothing about the internet’s architecture had to change to allow that, which is exactly the point, the same freedom is available to anyone with two machines and a socket.

The internet is constantly changing with new demands and bottlenecks. IPv4’s address space ran out years ago, and IPv6 is still only partway rolled out because swapping the foundation everyone depends on is incredibly slow. Real-time video, cloud gaming, and remote collaboration keep pushing the limits of latency, which is why low-orbit satellite constellations now compete with undersea cables on round-trip time, and why QUIC’s redesign happened at all. The next protocol, the one nobody has agreed on yet, will exist because some application running today is straining against a limitation that can only be solved with a new protocol and a new set of tradeoffs.