How Computer Networks Work

Before networks, moving data between computers meant carrying it. Physically. On tape, on floppy disks, in boxes. People called it “sneakernet” – the bandwidth of a station wagon full of backup tapes is hard to beat, but the latency is terrible.

From disconnected to connected

The story of computer networking begins, like so many good stories, with the military worrying about getting blown up.

In the early 1960s, the US Department of Defense was concerned about the vulnerability of its communications infrastructure. The telephone network was circuit-switched – when you made a call, a dedicated electrical path was established between you and the other person, and it stayed open for the duration. This was fine for voice calls, but it meant that a well-placed bomb could sever the circuit and take out communications for an entire region.

Paul Baran at RAND Corporation and, independently, Donald Davies at the National Physical Laboratory in the UK proposed a radical alternative: packet switching. Instead of a dedicated circuit, you’d chop your message into small packets, each labelled with its destination, and let the network figure out how to get them there. Different packets from the same message might take different routes. If one path was destroyed, the packets would find another way. The network would be resilient by design.

ARPANET, funded by the US Department of Defense’s Advanced Research Projects Agency, went live in October 1969. The first message was supposed to be “LOGIN”, sent from UCLA to Stanford Research Institute. The system crashed after the first two letters. The first message ever sent on the precursor to the internet was “LO” – which, as first words go, has a certain inadvertent poetry.

Through the 1970s, ARPANET grew. Other networks appeared: CYCLADES in France, the NPL network in the UK, various corporate and academic networks. The problem was that they all spoke different protocols. Connecting them required translation, and translation is where things get messy.

Vint Cerf and Bob Kahn published their landmark paper “A Protocol for Packet Network Intercommunication” in 1974, proposing what would become TCP/IP – a protocol suite designed specifically to interconnect different networks. The key insight was layering: TCP handled reliable delivery (making sure all the packets arrived, in order), while IP handled addressing and routing (making sure each packet got to the right place). By separating these concerns, you could connect any network to any other network, as long as both understood IP.

The protocol wars of the late 1970s and early 1980s pitted TCP/IP against the OSI protocol suite (backed by European governments and ISO), DECnet, and others. TCP/IP won, largely because it was simpler, it worked, and it was already running on a growing network of real machines. The IETF’s philosophy of “rough consensus and running code” beat design-by-committee.

On January 1, 1983 – “flag day” – ARPANET switched entirely to TCP/IP. Every connected machine had to cut over on the same day. It worked, barely, and the internet as we know it was born.

Then Tim Berners-Lee, a physicist at CERN, invented the World Wide Web in 1991 – a system of hyperlinked documents accessible via HTTP. The web was not the internet (the internet is the network; the web is one application running on it), but it was the thing that made the internet matter to everyone. Within a few years, the network went from an academic tool to cat gifs everywhere.

The layers: theory and reality

Networks are complicated. To manage that complexity, we use layered models – each layer handles one aspect of communication and presents a clean interface to the layers above and below.

The theoretical model is the OSI model, defined by the International Organisation for Standardisation. It has seven layers:

Layers 5 and 6 – Session and Presentation – are largely theoretical. In practice, most protocols don’t implement them as distinct layers. They’re the awkward middle children of the OSI model, important in a classroom and largely invisible in production.

The TCP/IP model, which is what the internet actually runs on, compresses this into four layers: Link (roughly OSI 1-2), Internet (OSI 3), Transport (OSI 4), and Application (roughly OSI 5-7). It’s less elegant but more honest. The IETF has always preferred working systems to beautiful diagrams. (If you want to go deeper, Computer Networks by Tanenbaum and Wetherall covers both models thoroughly, and Stevens’s TCP/IP Illustrated remains the canonical reference for understanding the protocols at the packet level.)

Packets: what actually travels the wire

When you load a web page, your browser doesn’t send the request as one long stream. It gets chopped into packets – small, self-contained units that can be routed independently through the network.

Each packet is like a letter in an envelope inside another envelope. This is called encapsulation. Your HTTP request becomes a TCP segment (with source and destination ports, sequence numbers, and flags), which becomes an IP packet (with source and destination addresses, a time-to-live counter, and a protocol identifier), which becomes an Ethernet frame (with source and destination MAC addresses). Each layer wraps the layer above.

A few things in those headers are worth knowing about. The TTL (time to live) in the IP header starts at some number (often 64 or 128) and decreases by one at every router. When it hits zero, the packet is discarded. This prevents packets from circling the network forever if there’s a routing loop.

TCP’s sequence numbers are how the receiving end puts packets back in order and detects missing ones. The famous three-way handshake – SYN, SYN-ACK, ACK – establishes a connection by exchanging initial sequence numbers. It’s the network equivalent of “Hello” / “Hello, I heard you” / “Good, I heard that you heard me, let’s talk.”

MTU (Maximum Transmission Unit) is the largest packet size a network link can carry – typically 1,500 bytes on Ethernet. If a packet is larger than the MTU, it must be fragmented into smaller pieces. This fragmentation is expensive and sometimes breaks things, which is why most modern systems use Path MTU Discovery to figure out the smallest MTU along the entire route and size their packets accordingly.

How data gets there: DNS and routing

When you type “barkingiguana.com” into a browser, your computer doesn’t know where that is. It needs to translate the human-readable name into an IP address – a number that routers can work with. This is the job of the Domain Name System (DNS), defined in RFC 1035 and often called the phone book of the internet.

Your computer asks a recursive resolver (usually provided by your ISP or a service like 1.1.1.1 or 8.8.8.8). The resolver, if it doesn’t have the answer cached, walks the DNS hierarchy: it asks a root server, which points to the .com authoritative servers, which point to the authoritative server for barkingiguana.com, which returns the IP address. All of this usually happens in milliseconds.

DNS responses are cached at every level, controlled by TTL (time to live) values set by the domain owner. A short TTL means changes propagate quickly but DNS gets hammered with queries. A long TTL means changes take time to reach everyone. Getting this balance right is one of those deceptively simple operational decisions.

Once your computer has the IP address, routing takes over. Your packet needs to get from your machine to the destination, potentially crossing dozens of intermediate networks. Each router along the way makes a next-hop decision: it looks at the destination IP address, consults its routing table, and forwards the packet to the next router that’s closer to the destination.

The routing tables of the internet’s core routers are maintained by BGP (Border Gateway Protocol), sometimes called the protocol that holds the internet together (RFC 4271). BGP is how autonomous systems – large networks operated by ISPs, universities, and corporations – announce which IP addresses they’re responsible for and exchange routing information. It’s built entirely on trust, which is both its strength and its vulnerability. When a network announces routes it shouldn’t (whether by accident or malice), traffic can be misdirected on a massive scale. Pakistan accidentally took YouTube offline worldwide for two hours in 2008 by announcing an overly specific BGP route.

NAT (Network Address Translation) is the hack that saved IPv4. The original design gave every device its own globally unique IP address, but with only about 4.3 billion addresses in IPv4 and far more devices than that, we ran out. NAT lets an entire household share a single public IP address: your router translates between the private addresses on your local network and the single public address the rest of the internet sees. It works, but it broke the end-to-end principle that the internet was designed around. IPv6, with its vastly larger address space (roughly 340 undecillion addresses), was supposed to fix this. We’ve been “about to switch to IPv6” for about twenty years now.

Firewalls and trust

The early internet was built on trust. Everyone on ARPANET was a researcher or government employee. You didn’t need firewalls because you knew everyone on the network.

That assumption didn’t survive the 1990s.

A firewall examines network traffic and decides what to allow and what to block. The simplest kind – packet filtering – looks at IP addresses and port numbers. “Allow incoming connections to port 443 (HTTPS) from anywhere. Block everything else.” More sophisticated stateful firewalls track connections: they know that an incoming packet on port 54321 is a reply to an outgoing request you made, so they let it through. Application-layer firewalls inspect the actual content of the traffic – they can tell the difference between legitimate HTTP and something pretending to be HTTP.

On a Linux system, firewall rules are managed through iptables or its successor nftables. The rules look something like this:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

Translation: accept TCP connections to ports 443 and 80, drop everything else.

Network segmentation takes firewalling further. Instead of one flat network where every device can talk to every other device, you divide the network into zones with controlled access between them. A DMZ (demilitarised zone) sits between the public internet and your internal network, holding servers that need to be publicly accessible without exposing everything else. This matters enormously in practice – the GreenBox team’s threat modelling work is exactly the kind of systematic thinking that leads to good network segmentation decisions.

The deeper story of how we secure traffic on these networks – TLS, certificates, the whole trust infrastructure – is its own fascinating tale, covered in the next post in this series on how TLS works.

Capturing and debugging

When something goes wrong on a network – and something always goes wrong – you need tools to see what’s actually happening on the wire.

tcpdump is the Swiss army knife. It captures packets and prints their contents. A simple command like tcpdump -i eth0 port 443 -n shows you all HTTPS traffic on the eth0 interface, with IP addresses instead of hostnames. When a service isn’t responding and you don’t know why, tcpdump tells you whether packets are arriving at all, whether they’re being acknowledged, or whether they’re vanishing into the void.

Wireshark does the same thing but with a graphical interface that can decode hundreds of protocols and colour-code them. When you need to understand a complex exchange – a TLS handshake, a DNS resolution chain, a misbehaving WebSocket connection – Wireshark’s protocol dissectors save hours of manual decoding.

traceroute (or mtr, which combines traceroute with ping for continuous monitoring) shows you the path packets take from your machine to the destination. Each line is a router along the way, with its IP address and latency. When a website is slow, traceroute tells you where it’s slow – is it your ISP, the transit network, or the destination’s hosting?

dig (or nslookup) queries DNS directly. dig barkingiguana.com A asks for the IPv4 address. dig barkingiguana.com MX asks who handles email. When a domain isn’t resolving, dig tells you whether the problem is in your resolver, the authoritative server, or somewhere in between.

And curl -v shows you the full HTTP conversation – the request headers your client sent, the response headers the server returned, the TLS negotiation, the redirects. When an API isn’t behaving, curl -v is where you start.

The real-world debugging workflow usually goes something like: “the website is slow” leads to curl -v (is it connecting at all?), then dig (is DNS resolving?), then traceroute (where’s the latency?), then tcpdump (what’s actually on the wire?). You work from the application layer down until you find where things break.

Common attacks and why they work

Every attack illuminates a design decision. Understanding how attacks work teaches you how the network works – and each one reveals a place where the original designers chose to trust.

ARP spoofing exploits trust at the link layer. On a local Ethernet network, devices use ARP (Address Resolution Protocol) to map IP addresses to MAC addresses. ARP has no authentication – if a device says “I’m 192.168.1.1”, everyone believes it. An attacker can claim to be the gateway and intercept all traffic on the network. The fix: 802.1X authentication, or just accept that local networks are not safe.

DNS poisoning exploits trust in the phone book. If an attacker can inject false records into a DNS cache, they can redirect traffic for any domain to any IP address. DNSSEC adds cryptographic signatures to DNS records, but adoption has been slow because it’s complex to deploy.

SYN floods abuse the three-way handshake. An attacker sends thousands of SYN packets with forged source addresses. The server allocates resources for each half-open connection and waits for the ACK that will never come. Eventually, it runs out of memory for new connections and stops responding to legitimate traffic. SYN cookies and rate limiting help, but massive floods still require upstream filtering.

Man-in-the-middle attacks – sitting between two parties and relaying (or modifying) their traffic – are why HTTPS matters. Without encryption, anyone on the network path can read and alter your data. With properly implemented TLS, they can see that you’re communicating but not what you’re saying.

BGP hijacking exploits trust between networks. Because BGP announcements are not authenticated by default, a malicious (or misconfigured) network can announce routes for IP addresses it doesn’t own, redirecting traffic through its infrastructure. RPKI (Resource Public Key Infrastructure) adds cryptographic validation to BGP, but like DNSSEC, deployment is gradual.

DDoS (Distributed Denial of Service) is the brute-force approach: overwhelm a target with so much traffic that it can’t serve legitimate users. The traffic can come from millions of compromised devices (botnets) and can target any layer of the stack. Defence requires a combination of upstream filtering, CDN distribution, and capacity planning.

The pattern is clear: almost every attack exploits trust that was originally granted because the network started small and collegial. As the network grew, that trust became a vulnerability. The history of network security is the story of adding authentication and encryption to systems that were designed without them.

Networks are trust between strangers

Computer networks are, at their core, a cooperation problem. Billions of devices, operated by millions of organisations, agreeing to forward each other’s packets. There’s no central authority that makes it all work. There’s no single point of control. It’s a system built on conventions, standards, and the assumption that most participants will play nice most of the time.

From “LO” – that accidental first message – to cat gifs, video calls, and global commerce, the distance travelled is extraordinary. But the core principle hasn’t changed. Networks work because people and machines choose to cooperate, choose to forward packets they don’t own, choose to follow protocols they didn’t write.

The miracle isn’t the technology. The miracle is the trust. The first message on ARPANET was two letters long and crashed the system. Now billions of packets cross the planet every second, arriving intact, in order, at the right destination – because strangers agreed to cooperate. The bandwidth of that cooperation is hard to beat. And the latency, for once, is pretty good too.