What Is the Web?

Table of Contents

1. The Internet and the Web Are Different Things
2. Clients and Servers
3. The Browser Is Just a Client
4. A Server Is Just a Program
5. What Happens When You Open a Page
6. The Words You'll Hear
7. Your Two Tools
8. Try It Yourself

1. The Internet and the Web Are Different Things

People use "the internet" and "the web" as if they mean the same thing. They don't, and the difference matters once you start building things.

• The internet is the network: billions of computers, phones, and servers connected by cables, Wi-Fi, mobile towers, and undersea fibre, all able to send data to each other. It's the roads.
• The web is one service that runs on top of the internet: pages and files, linked together, fetched with a language called HTTP. It's one kind of traffic on those roads.

Plenty of other things use the internet without being the web. Email uses its own protocols. Online games, video calls, and logging in to a server with ssh send data across the internet too, but they don't use HTTP.

The web was invented in 1989–1991 by Tim Berners-Lee, about twenty years after the internet started. His idea was simple: documents that live on different computers, with links that let you jump from one to another. Everything you'll learn in this series grew out of that idea.

2. Clients and Servers

Almost everything on the web follows one pattern:

• A client asks for something.
• A server answers.

  Client                             Server
 (your browser)                (a computer somewhere)

   "Please send me /about"  ───────▶
                            ◀───────  "Here it is: <html>…"

The question is called a request, and the answer is called a response. One request, one response — that's the heartbeat of the web. A single page you open might involve fifty of them, but each one follows the same pattern.

The client always starts the conversation. A server doesn't send you pages you didn't ask for; it waits for requests and answers them. (Some newer technologies let a server push data over a connection the client already opened — you'll meet them later — but the client still opens it first.)

3. The Browser Is Just a Client

Chrome, Edge, Firefox, and Safari are clients. Their job is to:

1. Turn what you type into a request.
2. Send it to the right server.
3. Receive the response.
4. Turn the response — usually HTML, CSS, JavaScript, and images — into the page you see.

But a browser isn't the only possible client. A mobile app asking a server for your messages is a client. A terminal command that downloads a file is a client. A backend calling a payment provider (like the ABA PayWay and Bakong KHQR tutorials on this site) is a client too. They all speak the same language — HTTP — so once you understand one, you understand them all.

4. A Server Is Just a Program

The word "server" means two things, and people switch between them without warning:

• A server program: software that waits for requests and sends responses. Nginx, Apache, and a Node.js or NestJS app are all server programs.
• A server computer: the machine that runs it — often a rented computer in a data centre, with no screen or keyboard.

Remember from How Computers Work that a running program is a process. A web server is a process that spends almost all its time waiting for network input, exactly like the I/O chapter described. When a request arrives, it wakes up, prepares a response, sends it, and goes back to waiting.

There's nothing magical about the computer either. Your own laptop can be a server: when you run a development server and open http://localhost:3000, your browser (the client) and the server program are on the same machine.

5. What Happens When You Open a Page

Here's the whole series on one page. When you type an address and press Enter, roughly this happens:

 1. You type      https://dara-sok.github.io/my-site/
 2. URL           The browser splits it into parts: which protocol,
                  which server, which page.               (Chapter 2)
 3. DNS           It looks up the server's name to get a number —
                  an IP address.                          (Chapter 3)
 4. Connection    It opens a connection to that address and
                  encrypts it with TLS.                   (Chapter 4)
 5. Request       It sends an HTTP request: "GET /my-site/". (Chapter 5)
 6. Response      The server answers: "200 OK", plus the HTML. (Chapter 6)
 7. Rendering     The browser reads the HTML, requests the CSS,
                  images, and scripts it mentions, and paints
                  the page.                               (Chapter 7)

All of that usually takes less than a second. The rest of the series zooms in on one step at a time, then adds the things that make the web remember you (cookies, chapter 8) and feel fast (caching, chapter 9), and the different kinds of things you can build on it (chapter 10).

6. The Words You'll Hear

Don't try to memorise these now. Each one gets its own section, and by chapter 11 you'll use them without thinking.

7. Your Two Tools

You'll look at real traffic throughout this series, with two tools you already have.

1. Browser DevTools. Every major browser has built-in developer tools. Open them with F12, or Ctrl+Shift+I (Cmd+Option+I on macOS), or right-click a page and choose Inspect. The tab you'll use most is Network, which lists every request the page makes.

2. curl. A command-line client that sends one request and shows you the response — no rendering, no hidden extras. It's already installed on macOS, Linux, WSL, and Git Bash. Try it now in the terminal you set up in Command Line Basics:

curl https://example.com

You should see a short page of HTML printed in your terminal. That's exactly what a browser receives from that address — before it turns it into a page. This is the single most important idea in the series: a web page is just text that a server sends back. Everything else is the browser being clever with it.

Windows note: In PowerShell, curl can be an alias for a different command with different options. Use your WSL or Git Bash terminal for this series, just like in Command Line Basics.

8. Try It Yourself

1. Open the Network tab. Visit your GitHub Pages site from the Git series (something like https://<your-username>.github.io/my-site/), or any website you like. Open DevTools → Network, then reload the page (F5 or Cmd+R). Watch the list fill up. How many requests did one page need? You'll see the number at the bottom of the panel.
2. Click the first request. It's usually the page itself. Look at the Headers tab on the right. Don't worry about understanding it yet — just notice that there's a Request section and a Response section. That's the client and the server talking.
3. Compare with curl. Run curl on the same address. The HTML you see in the terminal is the same as the Response tab of that first request in DevTools.
4. Find a non-web internet app. Think of three things on your phone or computer that use the internet. Which ones do you think use the web (HTTP), and which might not?

In the next chapter, we'll take a URL apart and look at every piece.