Introduction

Before the web became something you scroll, it was something you asked.

Not in the sense of search engines or forms or feeds, but in a much simpler way. One computer asked another computer for a document. The other computer sent it back. That was the whole exchange. If you understand that much, you already understand the most important part of the web.

Everything else came later.

In 1989, at CERN, this simplicity mattered. CERN was, and still is, a place where people from all over the world come together to work on complex ideas. They brought different machines, different operating systems, different ways of storing information. People joined projects, contributed for a while, and then moved on. Their knowledge often stayed behind in files that were hard to find or harder to understand.

Picture a shared office where everyone uses their own filing system. Some label folders carefully. Others scribble notes on loose paper. After a few years, no one quite knows where anything is anymore. Important things still exist—you just can’t reliably find them.

That was the problem.

To address it, Tim Berners-Lee did not propose a grand redesign of computing. He didn’t try to standardize every system or replace them with something new. Instead, he suggested something almost modest to the point of being unremarkable: a way to link documents together, and a simple protocol that any computer could use to ask for one of those documents.

Think of it like writing down clear directions instead of rearranging the entire city.

The result was the web. Not a product. Not a company. Not a platform. Just a shared way of asking for information and receiving it. If two machines followed the same rules, they could talk to each other. If a document existed somewhere, it could point to another document somewhere else. Over time, those links formed a web—not because anyone planned it, but because that is what happens when connections are easy to make.

At its core, the web is still just this exchange. A request goes out. A response comes back. You can imagine it as a letter and a reply, or a knock on a door and someone answering. The rules are simple enough that they can be written down clearly, implemented by anyone, and explained without special equipment or insider knowledge.

That simplicity was not an accident. It was a choice.

Because the web was easy to implement, people tried it. Because it did not require permission, people experimented. Because it was open, people extended it in directions no one had anticipated. A personal homepage, a research archive, a small business site—these were all built on the same basic idea. The web did not care what you were publishing, only that you followed the rules of the conversation.

Success, however, brings new problems.

As more people joined the conversation, new needs appeared. Conversations needed privacy, so encryption was added. Popular sites needed help handling many visitors at once, so intermediaries appeared to spread the load. Some doors needed locks, others needed guards, and some needed someone to politely say, “Not this way.”

These additions were sensible. They solved real problems. In many ways, they made the web safer and more reliable. But they also added layers. And layers have a habit of hiding the simple thing they were built to protect.

Over time, the web began to feel less like a conversation you could join and more like a machine you were expected to use correctly. Hosting a website started to sound like a specialist skill. Words like “infrastructure” and “edge” and “security posture” replaced the earlier, friendlier language of pages and links. The web still worked—but it no longer felt close at hand.

If you’ve ever felt that distance, you’re not alone.

This book is an invitation to step closer again.

We will move slowly and start from the beginning. We will look at what a request actually is, the way you might look at a postcard before thinking about the postal system that delivers it. We will meet web servers as simple, patient programs that answer questions. We will meet reverse proxies as helpful intermediaries—like reception desks or doormen—whose job is to guide traffic, not to dominate it.

Along the way, we’ll use comparisons, small diagrams, and everyday images. Not to oversimplify, but to give your intuition something to hold onto. You don’t need to memorize specifications or learn new tools right away. Understanding comes first. Confidence follows naturally.

The web was built by people trying to make their work easier to share. It grew because that goal resonated with others. Beneath all the layers, it is still doing the same thing it did at the beginning: helping one machine ask another machine for something useful.

Once you see that clearly, the rest stops being intimidating.

Let’s take a breath, start with a single request, and see where it leads.