Computer Networks

"The network is the computer." — John Gage, Sun Microsystems

The device in your hand is powerful, but almost nothing you value about it lives inside it. The message, the video call, the certificate you just earned — all of it arrives from somewhere else, carried across wires, radio, and glass you will never see. A computer network is the machinery that makes "somewhere else" feel like "right here." Understanding it is the difference between a programmer who ships features and an engineer who understands where their code actually runs.

Core Concepts

A network is simply two or more devices that can exchange data. That is the entire definition, and it is worth taking literally. Two laptops joined by a cable are a network. A phone talking to a nearby speaker over Bluetooth is a network. The scale is not what makes it interesting — the agreement is. For two devices to exchange data, they must agree, in advance and in exhaustive detail, on how the data is packaged, addressed, and interpreted. Those agreements are called protocols, and they are the real subject of this entire Part.

The internet is a network of networks — that is what the name literally says: inter-net, "between networks." Your home Wi-Fi is one small network. Your university, your bank, and chika.ng's server each sit on their own. The internet is the set of agreements that lets all of those separate networks pass data to one another. Crucially, no one owns it. There is no central computer, no master switchboard, no company you could call to "turn it off." It works entirely by voluntary adherence to shared protocols — which is exactly why it has survived companies, governments, and technologies that were supposed to replace it.

LANs, WANs, and the machines that connect them

Networks come in two broad sizes, and the distinction shapes everything above it.

A LAN (Local Area Network) covers a small area under one administrative roof — your home, an office floor, a single building. A WAN (Wide Area Network) spans cities, countries, or continents by stitching many LANs together over long-distance links. The internet is the largest WAN there is.

Inside a LAN, the device that ties everything together is a switch. A switch forwards data between machines on the same local network using their MAC addresses — a permanent hardware identifier burned into every network adapter at the factory. The switch keeps a small table of "which device is on which port" and delivers each frame only to the port it belongs to. That is all a switch does, and it does it very fast, because its job is deliberately narrow: move data within one network.

To move data between networks you need a router. A router speaks a higher, more portable language — the IP address — and its job is to decide which neighbouring network to hand a packet to so that it gets one hop closer to its destination. Your home router is the seam between your LAN and your internet provider's WAN; it is the single door through which everything you send leaves the building.

Why keep the two jobs separate? Because they solve genuinely different problems. MAC addresses are permanent and flat — perfect for a small local group where everyone can shout and be heard, useless for finding one machine among billions. IP addresses are hierarchical and assignable — perfect for routing across the globe, but overkill inside your living room. Switches optimise for local speed; routers optimise for global reach. Collapsing them into one device would make each worse at its job.

Packet switching: why the internet doesn't break

Here is the idea that made the modern internet possible, and it is easy to miss because it is now invisible.

When you send data across a network, it is not sent as one continuous stream down a reserved wire. Instead it is chopped into small chunks called packets. Each packet carries a piece of your data plus a header — the destination address, a sequence number, and other bookkeeping. Each packet is then released into the network to find its own way, and here is the surprising part: two packets from the same message may take completely different routes and arrive out of order. The receiving end uses the sequence numbers to reassemble them correctly. This is packet switching.

The older approach, inherited from the telephone system, was circuit switching: before any data flowed, the network reserved a dedicated end-to-end path — a physical circuit — held open for the whole conversation, whether you were speaking or silent. It was simple and gave predictable quality, but it was brittle and wasteful. Brittle because if any link on that reserved path failed, the whole call dropped. Wasteful because the reserved capacity sat idle during every pause.

Packet switching won decisively, for two reasons that were design goals, not happy accidents:

• Resilience. ARPANET, the internet's ancestor, was built to keep working even if parts of the network were destroyed. Because packets route independently and hunt for any available path, losing a link doesn't kill a conversation — traffic simply flows around the damage. There is no single circuit to sever.
• Sharing. One physical link can carry packets from thousands of unrelated conversations, interleaved. Nobody reserves the line, so nobody wastes it during their silences. This is why a single fibre can serve a whole neighbourhood.

Resilience and sharing are the entire reason the internet scales to billions of devices on infrastructure no one fully controls.

Why we build networks in layers

A working internet has to solve a staggering range of problems at once: turning bits into radio waves, finding a machine across the planet, resending data that got lost, and rendering a web page — all in the same instant. If one giant program had to handle all of it, no one could build it, debug it, or improve any part without breaking the rest.

The answer is layering. We stack the responsibilities so that each layer trusts the layer below it and offers one clean service to the layer above. A layer does its own job and hands off — it neither knows nor cares how the layers beneath it work, only that they deliver on their promise. This is the same discipline as a well-designed function that hides its internals behind a signature, applied to an entire planet's plumbing.

The model everyone actually uses is the TCP/IP stack, four layers deep. Read it from the bottom up, because that is the order a bit travels:

The beauty of the split is that each layer can change independently. Fibre replaced copper at the Link layer without the Application layer noticing. HTTP evolved without IP changing a line. That independence — bought entirely by layering — is why the internet can be upgraded piece by piece while never once being switched off.

You will also hear about the OSI seven-layer model. It is an older, more academic reference that splits the same ideas into seven layers instead of four. It is worth recognising the names in an interview, but in working practice engineers speak TCP/IP. Treat OSI as the textbook and TCP/IP as the field.

Bandwidth and latency: two numbers, often confused

When people say a connection is "fast," they usually mean one of two very different things, and mixing them up leads to real engineering mistakes.

Bandwidth is how much data you can move per unit of time — the width of the pipe. It is measured in bits per second (Mbps, Gbps). Latency is how long a single trip takes — the delay before the first bit arrives. It is measured in milliseconds.

These are independent, and the classic illustration makes it stick: a truck loaded with hard drives driving across the country has enormous bandwidth — it can carry petabytes — and terrible latency, because you wait days for it to arrive. A fibre link might have far less bandwidth but deliver its first bit in milliseconds. A big pipe does not make a short trip, and a short trip does not make a big pipe.

Why does the distinction matter to you as an engineer? Because you fix them differently. If a large file download is slow, you need more bandwidth. If a game feels laggy or an app stutters on every click, more bandwidth won't help at all — the enemy is latency, often set by physical distance and the number of hops. Latency has a floor that money cannot lower: nothing travels faster than light, so a round trip across the planet has a minimum delay no upgrade can beat. Recognising which of the two numbers is actually hurting you is a senior instinct.

Common Mistakes

• Thinking the internet is "in the cloud" somewhere. It is physical: cables, routers, and radio. The "cloud" is someone else's computers in a building, reached over the network you just learned.
• Confusing bandwidth with latency. "I upgraded to gigabit and the game still lags." Of course it does — lag is latency, and a wider pipe doesn't shorten the trip.
• Believing packets travel together in order. They are independent and may arrive scrambled; reassembly is a separate job the receiver does using sequence numbers.
• Blurring switches and routers. A switch moves data within a network by MAC address; a router moves it between networks by IP. Same shape of box, different universe of responsibility.
• Assuming someone is in charge. There is no central internet computer. It is agreements — protocols — honoured by independent networks, and nothing more.

Interview Corner

Chapter Summary

• A network is two or more devices that can exchange data; the internet is a network of networks, owned by no one and held together by shared protocols.
• Switches move data within a LAN by MAC address; routers move it between networks by IP. Both exist because local speed and global reach are different problems.
• Packet switching — chopping data into independently routed packets — beat circuit switching because it is resilient (reroutes around failures) and efficient (shares links), both original design goals.
• We build networks in layers so each layer trusts the one below and offers a clean service above; the working model is the four-layer TCP/IP stack (Link, Internet, Transport, Application), with OSI as the academic reference.
• Bandwidth (data per second) and latency (delay per trip) are independent; a truck of hard drives has huge bandwidth and awful latency. Diagnose which one is hurting before you "fix" it.
• Protocols are the shared agreements that make all of this work — the rest of this Part is a tour of the most important ones.

Editorial reflection — the internet is the most complex machine humanity has ever built, and no one is driving it. That should be terrifying, and instead it is the source of its strength. Every idea in this chapter — packets over circuits, routers over switchboards, layers over monoliths, protocols over ownership — is the same instinct expressed again: decentralise, agree on the interface, and let the system heal itself. Learn to see that instinct, and you will recognise it far beyond networking — in good code, good teams, and good institutions.