You don't need a CS degree to debug a slow API or figure out why your video call keeps dropping. You need a working mental model of how packets actually move from your laptop to a server and back. Most networking primers drown you in acronyms or skip the parts that matter when you're shipping software. This is the version I wish I'd had.
The four building blocks of any network
A network is just a chain of devices connected so they can talk to each other. That's the whole thing. Every other concept is a refinement of that idea.
- Node. Any device on the network. Your laptop, a router, a phone.
- Link. The thing connecting two nodes. A cable, Wi-Fi signal, Bluetooth.
- Host. A node that can send or receive data. Most nodes you care about are hosts.
- IP address. The identifier that lets other devices find yours on the network.
If nothing else sticks, remember that everything else is a mechanism for moving bytes from one host to another.
There are two versions of IP. The reason why is a story about scale.
An IP address is a unique identifier for a node on a network. There are two versions, and the gap between them tells you everything about how the internet grew.
IPv4 is 32 bits. That gives you about 4.3 billion addresses. When the internet was small, that felt like infinite room. It wasn't. There are roughly 8 billion people on the planet, most of them online, and many of them have more than one device. We ran out a while ago.
IPv6 is the fix. It uses 128 bits, which gives you enough addresses to assign one to every atom on Earth's surface and still have room. The trade-off: v6 addresses look intimidating. Instead of 192.168.1.42 you get 2001:0db8:85a3:0000:0000:8a2e:0370:7334. You get used to it.
The four network sizes you actually encounter
These four show up in docs, configs, and incident postmortems. Know them so you don't have to look them up every time.
| Type | Full name | Coverage | Example |
|---|---|---|---|
| PAN | Personal Area Network | Around one person | Bluetooth, phone hotspot |
| LAN | Local Area Network | Home or office | Your Wi-Fi |
| MAN | Metropolitan Area Network | A city | City-wide fiber |
| WAN | Wide Area Network | Continent or globe | The internet |
When developers say "the network," they usually mean a WAN. When they say "local network," they mean a LAN. Knowing which one you're in changes how you debug. If the problem is across a WAN, latency and packet loss are the first suspects. If it's on a LAN, start with the switch or the cable.
Topology: how the nodes are wired together
Topology is the shape of the connections. It determines what breaks and what doesn't when something fails.
Bus. Every node shares a single backbone cable. Cheap and simple. One break in the backbone and the whole network dies.
Star. Every node connects to a central device — usually a switch or router. Your home Wi-Fi is a star. If the router dies, everything stops. If one device dies, nothing else is affected.
Ring. Each node connects to exactly two neighbors forming a loop. Traffic can flow either direction, which gives you some fault tolerance. But a dead node in the ring cuts the loop.
Mesh. Nodes have multiple connections to multiple other nodes. This is what the internet runs on. If one path fails, packets reroute. Mesh comes in two flavors:
- Partial mesh. Most nodes have a few connections, critical nodes have many. This is what production networks actually look like.
- Full mesh. Every node connects to every other node. Maximum redundancy, maximum cost. Reserved for small clusters where downtime is not an option.
The vocabulary that comes up in every incident
These four terms will appear every time someone says "the network is slow." Knowing them precisely saves you from guessing in a war room.
Bandwidth. The maximum capacity of a link. If your connection is 100 Mbps, that's the ceiling. "We don't have enough bandwidth" means the pipe is full.
Latency. The delay between sending a packet and it arriving. Usually measured as round-trip time. 20 ms is good. 200 ms is noticeable. 500 ms+ and users will complain.
Jitter. The variation in latency over time. Bouncing between 10 ms and 200 ms is high jitter. Jitter is what makes video calls feel choppy even when your average latency looks fine on a speed test.
Packet loss. The fraction of packets that never arrive. Above 1% and most applications visibly degrade. Above 5% and things start breaking.
Here's a shortcut: bandwidth is the size of the pipe. Latency is the length of the pipe. You want both small.
Why everything is sent in packets
Nobody sends a 10 MB file as one massive blob. The network chops it into packets, sends each one independently, and reassembles them on the other side. Three reasons:
- A single giant transmission would block the link. Nothing else could send until it finished.
- If one bit of a giant transmission got corrupted, you'd resend everything. With packets, you only resend the ones that went missing.
- Routers make forwarding decisions per packet, not per file. They're optimized for small, independent units.
A packet has a header (source, destination, sequence number, protocol) and a payload (a chunk of your data). That's it.
TCP vs UDP: the transport layer trade-off
Packets ride on transport-layer protocols. Two dominate. Their difference is a single trade-off.
TCP is the careful one. It does a three-way handshake before sending anything. It numbers every packet, waits for acknowledgments, and retransmits anything that goes missing. If the network is congested, it slows itself down. The result: lossless, in-order delivery. The cost: latency.
UDP does none of that. It sends packets without asking permission, does not check if they arrived, and does not care what order they show up in. It's the fastest option because it skips every check TCP insists on.
The decision rule: use TCP when every byte must arrive correctly — file transfers, API calls, database queries. Use UDP when keeping up with real time matters more than perfect delivery — video calls, live streams, online games.
The OSI model: a map of how data moves
The OSI model is seven layers representing how data travels from one application to another. You mostly care about three of them.
| Layer | Name | What it does | Examples |
|---|---|---|---|
| 7 | Application | What your app does | HTTP, DNS, SMTP |
| 6 | Presentation | Encoding, encryption | TLS, JPEG |
| 5 | Session | Connection lifecycle | Sessions, tokens |
| 4 | Transport | End-to-end delivery, ports | TCP, UDP |
| 3 | Network | Routing between networks | IP, routers |
| 2 | Data Link | Node-to-node delivery | MAC, Ethernet, Wi-Fi |
| 1 | Physical | Cables, signals, radio | Fiber, copper |
As a developer, you mostly live in layers 7, 4, and 3. Layer 7 is your HTTP request. Layer 4 is your TCP or UDP socket. Layer 3 is the IP address you're sending to.
When you make an HTTPS request, your code thinks it's sending JSON. In reality, that JSON gets encrypted at layer 6, split into TCP segments at layer 4, wrapped in IP packets at layer 3, framed at layer 2, and turned into radio waves at layer 1. On the receiving end, the layers unstack in reverse.
One thing people miss: TCP is full-duplex. Both sides can send and receive simultaneously. That's why a single TCP connection carries a request and a response without either side waiting.
Most of this is not complicated. It's just hard to learn because networking content is either too shallow ("packets are like letters!") or too deep ("let's discuss the flag bits in the TCP header"). The layer model gives you a shortcut: when something breaks, the layer tells you where to look. If your API is timing out, check layer 4. If DNS isn't resolving, check layer 7. If packets aren't reaching the next hop, check layer 3.
Next post is about IP addresses, DNS, TCP in practice, proxies, load balancers, and CDNs.