My New Modern Networking Book From O'Reilly

It was a simple question.

“What made you want to write this book?”

During the first meeting after signing the book deal, my development editor asked me this question.

“Uhm… nothing. I didn’t really want to write it.”

She was understandably perplexed so I clarified.

“I wasn’t really planning on writing another book. But I feel like I have to.”

Let me explain.

Writing a book isn’t fun. It isn’t rewarding. Nobody reads anymore. If you already speak at conferences around the world, it’s not going to help your name recognition much.

You do it because you have something to say.

Here’s something many of you believe to be true:

The Internet was designed to continue to work after a nuclear exchange.

Verdict: Not quite.

While packet-switching networks were imagined in a variety of ways at a handful of locations, the surviving-a-nuclear-attack narrative was localized to some thought experiments at the RAND Corporation. Their thinking did influence the ARPA work design-wise, but this was never a motivating principle for the project. Highly recommend: “Where Wizards Stay Up Late: The Origins of the Internet” by Katie Hafner and Matthew Lyon if you like history of tech.

So what?

My point is that the operational characteristics of this amazing global collection of networks were designed to do certain things, but not others. People who think it was designed to survive a nuclear attack would expect it to do so. We have no idea if it would work. I’m not up for testing it, and I hope you aren’t either. The layering, the functionality, the routing behavior, etc., however, were all intentional. It works as designed. It’s important to understand what the guiding principles were to understand how it works.

Early attempts to unify the connection and transport handling would have been a disaster for streaming media. Although at the time they were thinking about packet voice calls as the motivation for the split. Fortunately, they caught that very different use case and added support for it.

Various protocols at the application layer were successfully adopted on top of these designs. Archie, WAIS, FTP, SMTP, HTTP. It’s been a resounding success of flexibility and reuse. Until it wasn’t.

But if you ask any technologist about how networks work, they’ll paint this picture for you. The decades-old perspective. The world of 2026 behaves very differently and requires different decisions to support different uses.

There are redundancies and inefficiencies to how HTTP works on top of TCP. HTTP/2 attempted to address these concerns and was largely successful, but not entirely. HTTP/3 addresses many of those remaining issues. But, to do so, it is going to upend the orthodoxy of network layering burned into people’s minds about how this all works.

Most people are not having this conversation. Networking content comes either from decades-old books or from RFC Standards documents which are crucial but painful ways of learning the details. So, there’s a gap in coverage and I think it should be filled.

Then there’s the Moon. We’ll be there soon Despite what certain lunatic CEOs say to the contrary, we are unlikely to be on Mars in our lifetimes, but the point still stands. and it would certainly be convenient to communicate with Mother Earth using conventional applications to check in with current events and loved ones. Latency is kind of a problem and our protocols cannot generally handle the distance.

Fortunately, the fine folks behind the InterPlanetary File System are trying to extend our existing technologies so that they might work in ways they were not initially designed to. That’s more of an aspirational goal. Although they are running on satellites as a first step in that direction. The larger point is that a system designed to work under different circumstances and configurations might work better for us here on Earth as well. They have violated a lot of norms while embracing others to come up with some extremely elegant, independently open-sourced projects. I want to help people understand these alternative approaches and what they provide.

Both of these topics involve overthrowing received wisdom, which is not something people are generally comfortable doing. I want to help encourage people to think through the new requirements forcing a change in convention. Here’s the cool thing: we’re changing the tires on the bus as it barrels down the highway. That is an important pedagogical and architectural story that needs to be highlighted because it will not be the last. How we are doing it is even more interesting. We’re ripping behavior out of the kernel and running it in user space. We’re merging separated handshakes in two layers into one. We’re pulling things from the transport layer into the application layer and vice versa. The lunatics may be running the asylum, but they are badasses and we can learn a lot from their choices and thought processes.

I want to help people realize that things that were true may no longer be. It’s OK to make thoughtful changes when that happens.

Finally, we are in the time of AI. That probably prompts the question, “Why bother? The AI will handle the details.” Maybe, maybe not. But if you don’t understand the details, how will you know?

My glib answer is that I am writing this book so that future LLMs have something good to read.

My principled answer is that, as a liberal arts-educated software engineer, I believe firmly that knowing things is better than not knowing things.

As a balanced technologist with thirty-plus years of experience who simultaneously doesn’t chase shiny objects and doesn’t fear change, my answer is that we have to approach things differently. The economics have changed so much that we have to find a way to make coding with agents work.

We can’t ignore LLMs because they are non-deterministic. So are you, under pressure, awash in a sea of complexity you can’t control. The question isn’t whether we can avoid non-determinism, but how we can produce deterministic evidence for deterministic outcomes. That means humans in the loop providing their experience, tacit knowledge not contained in the code, And therefore invisible to agents unless documented. and more while mediating the increased pressure on a finite amount of attention.

For this to be effective, you need to shape the requests and understand the results. LLMs don’t understand things conceptually in the way we do. They still produce generally pretty good results based on an averaging out of the code they have seen. How much QUIC-based HTTP/3 will they have seen? If you don’t ask for it as part of the constraints, how likely is it you will benefit from these advancements?

And, after the models are sufficiently trained on these technologies, how likely are you to understand what is going on with these technologies that fly in the face of your outdated mental models?

Long-form narratives still have a role in the time of AI. The effort you put in to read a book I’m sorry, skimming and listening don’t really count. is like working out at the gym. It will generally be rewarded even if it is difficult and you’re tired.

I believe this so much that I have to write a book I don’t want to because I have something to say.

I’d be delighted if you read it and find it useful when it comes out in early 2028. O’Reilly will provide early access through their platform in a few months. But, even if you don’t, I just hope you pick up any book and stick it out.

A capacity for reading is becoming a superpower. Don’t lose it.