Network Protocols in Practice

If you want to understand networking, you could read the RFCs. But RFCs describe what protocols should do, not what they actually do in the wild, where NATs rewrite your packets, firewalls drop anything unfamiliar, and the "end-to-end principle" is more of a fond memory than a design constraint. The most useful networking knowledge is about what happens when the clean layered model meets the mess of real deployment.

The Stack, Honestly

The Network Protocols Compendium walks through the full stack — physical layer through application — in the way a practitioner actually encounters it. The key insight that most networking education buries: the OSI model is a pedagogical convenience, not a description of reality. Real protocols blur layer boundaries constantly. TCP's congestion control is a transport-layer mechanism that makes decisions about the physical network. HTTP/2's multiplexing solves a problem caused by TCP's head-of-line blocking. TLS sits awkwardly between transport and application.¹

What matters in practice is understanding the constraints at each layer, not the layer labels. At the physical layer, the constraint is bandwidth and latency — how many bits per second, and how long until the first bit arrives. At the link layer, it's addressing and framing — who's talking to whom on this local segment. At the network layer, it's routing — finding a path through a graph of interconnected networks. At the transport layer, it's reliability and ordering — do you need every byte to arrive, and in order? At the application layer, it's semantics — what does this data mean?

Each layer's constraints shape what the layers above can do. The most common networking bugs come from misunderstanding these constraints: assuming TCP guarantees message boundaries (it doesn't — it's a byte stream), assuming UDP packets arrive in order (they don't), assuming DNS is instant (it's not), assuming your path through the network is symmetric (it often isn't).

NAT Traversal: The Real Problem

Tailscale's architecture document is the best explanation I've seen of why peer-to-peer networking is hard in 2020s-era internet and what you can do about it. The core protocol is WireGuard — a modern VPN that's dramatically simpler than IPsec or OpenVPN, with a total codebase under 4,000 lines. WireGuard provides encrypted point-to-point tunnels between machines that know each other's public keys. What Tailscale adds on top is everything needed to make those tunnels actually work in the real world.²

The real world means NATs. Most devices are behind one or more layers of Network Address Translation, which means they don't have publicly routable IP addresses. Two devices behind different NATs can't directly connect to each other without help. The standard solution is STUN (Session Traversal Utilities for NAT): each device sends a packet to a known public server, which tells the device what its externally-visible IP and port are. If both devices do this, and the NATs are well-behaved, they can punch through by sending packets to each other's external addresses simultaneously.²

But NATs are not always well-behaved. The taxonomy of NAT types — full cone, restricted cone, port-restricted cone, symmetric — describes how aggressively the NAT restricts inbound connections. Symmetric NATs assign different external ports for different destinations, which makes hole-punching impossible because you can't predict what port the NAT will assign for traffic to a peer you haven't talked to yet. Tailscale falls back to DERP (Designated Encrypted Relay for Packets) servers in this case — encrypted relays that forward traffic between devices that can't connect directly. DERP is a last resort, and Tailscale's goal is to minimize its use, but having it as a fallback means the network always works even through the worst corporate firewalls.²

The coordination layer is where Tailscale's real engineering is. A central coordination server distributes public keys, endpoint information, and ACLs to all nodes. Nodes use this to establish direct WireGuard tunnels with their peers, upgrading from relayed to direct connections as NAT traversal succeeds. The result is a mesh network where every node can reach every other node, encrypted end-to-end, without any of the configuration burden of traditional VPNs.

The Sound of Negotiation

Oona Raisanen's analysis of the dialup modem handshake is networking at its most physical. When you dialed up to the internet in the 1990s, those familiar screeching sounds were two modems negotiating a communication protocol in real time, and each phase of the sound corresponds to a specific step in the negotiation.³

First, the calling modem dials using DTMF tones — the same dual-tone multi-frequency signaling a telephone uses. The remote modem answers with a distinct tone. Then comes the V.8 bis transaction: short bursts of binary data to assess which protocol both modems support.

The next phase is echo suppression. The telephone network is designed for half-duplex human conversation and actively suppresses the return channel to prevent echoes. Modems need full-duplex, so the answering modem sends a special tone with periodic 180-degree phase transitions that disables the echo suppression and cancellation circuits on the line.

Then the modems probe the line. They send test tones at different frequencies and measure how the line attenuates and distorts each one. They exchange their test results and agree on a modulation speed that the line can support. Only then do they switch to scrambled data — passing everything through a scrambling formula to even out the power distribution — and begin actual communication.³

What's remarkable is how much intelligence is embedded in this process. The modems are performing real-time channel estimation, adaptive equalization, and protocol negotiation — the same problems that modern wireless protocols like 5G solve with far more computation but conceptually identical logic. The modem handshake is audible network engineering.

TUHS and the Protocol That Wasn't

The TUHS (The Unix Heritage Society) mailing list contains a thread about an audio compression system developed at Bell Labs that predated and was reportedly superior to MP3. Rob Pike's account: Ken Thompson and Sean Dorward developed audio compression that could fit hours of music on a CD-ROM. They obtained permission from bands (the Residents, Wire, Lou Reed) and even had Debbie Harry record an original song. The Plan 9 CD-ROM distribution was going to include all of it. Then an AT&T lawyer killed the project, refusing to accept the releases because he didn't know who these "assholes" were.⁴

Pike's punchline: "and that, my friends, is why MP-3 took off instead of the far better follow-on system we were on the cusp of getting out the door." It's a protocol story — not a technical protocol, but an institutional one. The compression technology existed. The content existed. The distribution mechanism existed. But the protocol for getting permission through a corporate legal department failed, and a technically inferior standard won because its institutional pathway was clearer. The best technology doesn't always win; sometimes the technology that can navigate the bureaucracy wins.