The reference textbook, now open source, that explains why the Internet is shaped the way it is and why it holds up.
Why this book
The twin note to High Performance Browser Networking. HPBN tells you what the network costs your pages; this one tells you why the network is built the way it is. It's the textbook generations of network engineers learned from, written by Larry Peterson and Bruce Davie, two heavyweights of the field, and it did something rare for an academic textbook: its sixth edition went open source, with the text maintained on GitHub, free to read online, updated as the field moves.
A web developer doesn't need the whole book. But it holds a handful of mental models that nothing else delivers as well, models that suddenly explain why HTTP, TCP and the cloud behave the way they do.
The ideas that stick
1The systems approach: judge the whole, not the boxes
The thesis gives the book its name: the key to the systems approach is the big picture, "you need to look at how the components of a system interact with each other to achieve an overall result", rather than stacking up layers each studied in isolation. The book applies its own rule to itself: congestion, which cuts across every layer, gets its own chapter instead of being filed away in the "TCP" box.
The lens carries beyond networking: it's the same one software architecture demands (judge the boundaries and the interactions, not the modules one by one). A network is a distributed system before it is a stack of protocols.
2The hourglass: everything over IP, IP over everything
Draw the protocols in tiers: at the top, dozens of applications (web, mail, video calls, games); at the bottom, dozens of physical media (fiber, copper, radio, satellite). In the middle, the waist of the hourglass: IP, alone. Everything above speaks IP, everything below carries IP. The book pushes it to a deliberate absurdity: "in principle, IP can run over a network that transports messages using carrier pigeons".
This single waist is THE architectural choice of the Internet: a minimal contract in the middle, and free innovation at both ends. You can invent an application or a physical medium without asking anyone's permission, as long as you speak IP. It's the opposite of a proprietary platform.
3Best effort: the network promises little, on purpose
IP promises almost nothing: a datagram leaves, it may arrive, maybe out of order, maybe twice. This bareness isn't laziness, it's the end-to-end argument, the most influential sentence in the book: a function "should not be provided in the lower levels of the system unless it can be completely and correctly implemented at that level". Perfect reliability is impossible in the middle of the network (only the two ends know what actually arrived), so it isn't promised in the middle: it's built at the endpoints, in TCP, on your machine.
Simple network, smart endpoints. That choice is what makes the Internet extensible, and it's the same argument that resurfaces in every architecture debate: where should the intelligence live?
4The pipe has a volume: bandwidth × delay
The most counter-intuitive number in the textbook. A link is described by two figures: its bandwidth (how much per second) and its round-trip delay. Their product gives the pipe's volume: how many bytes are "in flight" between the two ends at any instant. A transcontinental link at 1 Gbps with a 100 ms RTT holds ~400 Mb in flight.
Consequence: if the sender is only allowed to push 64 KB before waiting for an acknowledgment (the old default TCP window), it fills a crumb of the pipe and then waits. The book's math: on that 1 Gbps link, effective throughput drops to 74.1 Mbps. You pay for a gigabit, the window leaves you 7% of it. The whole engineering of "long fat networks" (bigger windows via the window scaling extension) follows from this one product.
5TCP builds reliability out of chaos
Below TCP, the network may lose, duplicate, reorder, delay. Above it, your code reads a perfect byte stream. In between: sequence numbers, acknowledgments, retransmissions, and a sliding window that pipelines it all. The textbook shows what this magic trick costs in dark corners: a closed connection stays quarantined for 240 seconds (TIME_WAIT, the time it takes the last ghost packets to die), and the 32-bit sequence numbers, sized for 1981 bandwidths, wrap around in 3 seconds on a 10 Gbps link (hence the modern extensions).
The transferable lesson: reliability doesn't exist in nature, it gets manufactured, and it's paid for in state to manage, at both ends.
6Congestion: TCP must create losses to find the room
Late 1980s, the Internet collapses under its own load (the congestion collapse, which Van Jacobson diagnoses and repairs). His fix still runs on your machine: AIMD. Additive Increase, Multiplicative Decrease: as long as it gets through, I go up one notch per round trip; at the first loss, I cut in half. The throughput curve draws a sawtooth, and that's deliberate: TCP "needs to create losses to find the available bandwidth of the connection". Loss isn't an accident, it's the probe.
Modern evolutions refine without renouncing: CUBIC (the Linux default) climbs back faster on big pipes, BBR (Google) probes delay rather than loss. The book notes an awkward number in passing: competing with BBR, CUBIC flows can get 100 times less bandwidth. Fairness between algorithms is an open question, not a settled one.
7The Internet scales by hierarchy, and BGP by economics
How do you route between billions of machines without every router knowing each one? By aggregating: addresses group into prefixes (CIDR), networks into autonomous systems (an AS: an ISP, a university, a cloud provider), and routing runs at two levels: fine-grained inside an AS, coarse between ASes.
Between ASes, the protocol is BGP, and its true nature comes as a surprise: it does NOT look for the shortest path. It looks for a path that honors the contracts: a provider routes for its customers, peers exchange their traffic, and nobody carries anyone else's traffic for free. Global routing is an economic system disguised as a protocol. When "the Internet is slow" between two continents, the cause is sometimes a contract, not a cable.
8Applications all reinvent the same pattern
The last chapter surveys mail, the web, video calls, CDNs, and one pattern keeps repeating: a hierarchy of names (DNS, which underpins everything else), a request-response dialogue, and caching as close to the user as possible. CDNs get their cleanest explanation here: servers everywhere, and consistent hashing to decide, with no central coordination, which server holds what.
And the history of HTTP is told in three acts you know by heart once you've read HPBN: 13 TCP connections for a page and its 12 icons in HTTP/1.0, persistent connections in 1.1, multiplexing in HTTP/2, QUIC under HTTP/3. The two books answer each other exactly here.
« We reject kings, presidents, and voting. We believe in rough consensus and running code. » (David Clark, IETF). The textbook quotes the motto while explaining how the Internet governs itself: no committee voting standards on paper, but implementations that run and a rough consensus. It's the engineering culture that produced everything else in the book.
My take, honestly
Let me say it up front: I'm a web developer, not a network engineer, and I don't have the level to judge this textbook as an expert. Here is what the book did to me: things I had endured for years (the lingering TIME_WAIT, throughput capping below what I pay for, the "magic" CDN) stopped being superstitions. The hourglass, the end-to-end argument and the bandwidth × delay product are three images I will not unlearn.
The honest reproach: it's a university textbook, with the density and dryness of the genre. You'll cross CRC calculations and state machines nobody will ever ask me about. Reading it cover to cover is a misuse for a web developer: chapters 1, 5, 6, the start of 3-4 and chapter 9, the rest as reference. And the authors' own irony deserves quoting: on the IPv6 transition, meant to be temporary, "it is doubtful they anticipated that transition period would be approaching its 30th anniversary".
In the duo with HPBN: read HPBN first, it starts from your pages and works down. This one climbs up from the cables, and it answers the "why" questions HPBN leaves open. Its free sixth edition, maintained on GitHub with Netflix examples and chapters on CUBIC and BBR, is a gift to the craft: the reference textbook has become a commons.
Odilon
Who is it for?
Read it if
- You enjoyed HPBN and want the "why" beneath the "how much"
- You touch infrastructure (cloud, CDN, VPN) and networking vocabulary is still folklore to you
- You like understanding systems through their design choices, not their commands
- You want ONE reference networking textbook, free and up to date
Skip it if
- You haven't read HPBN yet: start with it, it speaks your web-developer language
- You want something directly applicable tomorrow morning: this book explains, it doesn't equip
- Academic textbooks slip from your hands: the density is real
Going further
The twin note, on the web-pages side: High Performance Browser Networking, which starts from your pages and measures what the network costs them, where this book explains why the network is built that way.
And to see these layers at work in your own requests: the free HTTP course, plus the web security course for the TLS side.
Comments (0)