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.
Radio to your router, copper and fiber across your city, light in a submarine cable, a data center at the far end, and a separate, often different path back for the reply. The faint dots are everyone else's traffic; every wire, cable, and machine here is shared by millions of conversations at once. How this can possibly work with nobody in charge is the subject of this article.
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.
Morse pulses fade and pick up noise along every span of wire. Because the network transmits discrete symbols, a relay doesn't need to pass the wave itself; it only needs to detect whether a pulse is present, and recreate a brand new, clean copy of that pulse. Switch the relays to bare amplification and the noise of each span rides into the next, until Baltimore misreads the message. Discrete symbols plus regeneration is why a message could cross a continent without degrading, something no analog signal could do.
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.
Bandwidth sets only how wide each pulse is; distance sets only how long the wave takes to slide down the wire. The bar shows the two delays in real proportion, the replay above is slowed and not to scale.
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:
higher-frequency tone (mark) = 1, lower-frequency tone (space) = 0
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?
solid: downstream (ISP → you) · dashed: upstream (you → ISP), simultaneous, full duplex
What sounds like noise is a protocol running in full: capability lists, line probes, and equalizer training, all audible because early modems left the speaker on by default so a human could hear whether the call was progressing normally. Recording: "Dial up modem noises," public domain, Wikimedia Commons.
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.
A toy mesh of a dozen routers; click any router to destroy/disable it. For a few seconds its neighbors keep forwarding into the gap and those packets are lost, then routes settle around the failure, while reserved circuits stay broken. Hover routers to inspect local lookup tables.
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 Note on “Switches”
The word “switch” here shares the exact same lineage as the electronic switches in the software article. It traces back to the mechanical track switch of 19th century railways, which diverted trains, and the electrical keys that diverted currents. In networking, it came via the telephone operator’s switchboard, which physically connected caller circuits. In processors, it came via mechanical toggles and vacuum tubes, eventually shrinking to the microscopic transistor acting as an ON/OFF gate. Today, a network switch routes packets using an ASIC (Application-Specific Integrated Circuit) built from millions of transistor switches.
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.
Remembering Names Instead of Numbers
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.
Where Routes Come From, and Who Carries Your Packets
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.
Note
The simulator shows one narrow link for clarity. A real path can have more than one, PMTUD’s correction isn’t necessarily one-shot, if a later hop turns out even tighter, the sender simply gets told again and shrinks further, converging on the path’s actual minimum over however many rounds it takes.
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:
Note
The simulator sums byte values for clarity. Real protocols run a specific arithmetic function, one’s-comp