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.
sending a message over the Internet
Connection:
t = 0 ms1/6 · send message
You tap send. The message becomes a few hundred bytes.
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.
telegraph relaydiscrete symbols, regenerated at each relay
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.
relays
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 and latency in signal propagationdrag to seek
Tx (Sender)Rx (Receiver)10110010replayTOTAL DELIVERY TIME · REAL PROPORTIONS30.01 mspropagation (latency): 30 mstransmission: 8 μs
Status:Idle.
Analysis:The propagation delay dominates here, latency dwarfs how long sending actually takes.
bandwidth1 Mbps · early broadband
distance6,000 km · transatlantic cable
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:
modemmodulation / demodulation, one byte
sending ′
A
′ as bits
01000001
0
1
0
0
0
0
0
1
higher-frequency tone (mark) = 1, lower-frequency tone (space) = 0
received
·
·
·
·
·
·
·
·
Sending bit 0, the modem plays the lower “space” tone for this bit’s whole duration.
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?
audio recording of a dial-up handshake
solid: downstream (ISP → you) · dashed: upstream (you → ISP), simultaneous, full duplex
A real handshake between two dial-up modems, sped through six phases in under thirty seconds. Press play to hear it, and watch which phase is making that sound.
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.
SWITCHING MODE:
Two clients, two servers, a dozen routers between them, every packet routed hop by hop.
best-effort delivery0 arrived0 dropped
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.
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.
Manufacturer (OUI)
00:1A:2B
Identifies the hardware vendor (e.g., Apple, Intel, Cisco)
Serial Number (NIC)
3C:4D:5E
Unique identifier assigned to this specific chip