# Networks and the Internet: Client-Server, Addresses, Protocols and the Journey of a Request<no value>

## In this lesson

This lesson is built from a few short chapters, in the same order as the slides:

1. **Chapter 1** — computer networks, LAN, the internet, client and server
2. **Chapter 2** — IP address, port, domain and DNS
3. **Chapter 3** — request, response and protocols: HTTP, HTTPS, TCP and UDP
4. **Chapter 4** — what happens from the moment you type an address until the site is shown

## Chapter 1: Computer Networks, LAN, the Internet, Client and Server

### What will we learn?

- What a **computer network** is.
- **LAN** (local network) versus the **internet**.
- The **router**, the device that connects networks.
- The **client-server** model, the basis of every website, app and server we will build in the backend and databases topics.

### Why do we need this?

Every modern app talks to the network: WhatsApp, websites, games, and in the backend and databases topics also the server you will write. Backend developers write exactly the **server** side. Frontend developers write the **client** side. Without understanding this model, you cannot understand what your code does.

### Explanation from the basics

#### What is a network?

A **computer network** is two or more devices connected so that they can **pass information** between them. The connection can be by cable (Ethernet), through the air (Wi-Fi), or by optical fiber.

Why do we connect computers?

- **Sharing information** — messages, files, websites.
- **Sharing resources** — one printer for the whole office, one internet connection for the whole home.
- **Dividing the work** — the information is kept in one place (a server), and everyone accesses it.

#### LAN — Local Area Network

A **LAN** is a **local** network: the devices at home, in the office or in the classroom. In your home, the LAN includes the computer, the phone, the smart TV and the printer, all connected to the same **router**.

- All the devices on the LAN can talk to each other **directly**, without going out to the internet.
- Very fast, and under your control.

#### The internet — a network of networks

The **internet** is a **network of networks**: millions of local networks all over the world, connected to each other through internet providers (ISPs) and undersea cables between continents.

#### Router — the gateway between networks

The **router** is the device that connects your LAN to the internet. It knows whether a packet of information should stay at home (for example from the computer to the printer) or go out (for example to a website).

```text
          Your home (LAN)
   ┌──────────────────────────┐
   │ Laptop   Phone   Printer │
   │    \       |       /     │
   │         Router ──────────┼───► ISP ───► Internet ───► Google's network
   └──────────────────────────┘                           (another LAN)
```

{{< box "analogy" "Analogy: the postal system" >}}
A **LAN** is an apartment with several residents, who pass notes to each other by hand. The **router** is the mailbox at the building's entrance: a letter to the neighbors in the apartment stays inside, a letter to another city goes out to the post office. The **internet** is the whole worldwide postal system: branches, trucks, planes, connecting all the buildings in the world.
{{< /box >}}

#### The client-server model

Almost all communication on a network follows one model:

- **Client** — the program that **initiates** and sends a **request**. "Give me the home page", "save this message".
- **Server** — the program that **waits** for requests, handles them and returns a **response**.

| | Client | Server |
|---|---|---|
| Who starts? | **It does** | Waits to be contacted |
| How many? | Many clients | Usually one server (or a few) serves them all |
| Examples | A browser, a mobile app, `curl` | A web server, a database server, a mail server |
| Running time | Starts when needed and closes | Runs all the time (24/7) |

**Very important:** client and server are **roles of programs**, not kinds of computers. The same laptop can run a browser (client) and a FastAPI server (server) at the same time. In the backend and databases topics that is exactly what you will do: the server and the client will run on the same computer.

{{< box "analogy" "Analogy: a restaurant" >}}
The **client** is the diner: orders (a request) and gets a dish (a response). The **server** is the kitchen: waits for orders, prepares and returns. One kitchen serves many diners, and it is open even when nobody is ordering.
{{< /box >}}

### Request and response — an example

When you browse to a website, the browser is the **client** and the website is the **server**:

```text
Browser (Client)                  Server (example.com)
   │                                   │
   │ ──── Request: GET /  ──────────►  │
   │                                   │  finds the page
   │ ◄──── Response: 200 + HTML  ────  │
   ▼                                   │
shows the page
```

1. The browser **initiates** — sends a request: "give me the main page".
2. The server, which is always **waiting** for requests, finds the page.
3. The server returns a **response**: a success code (`200`) and the page content.
4. The browser **shows** what it received.

The very same pattern repeats in every app: WhatsApp sends a message to the server, a weather app asks for a forecast, and later in the course — a server you write will receive requests and return responses.

### Common mistake

**The mistake: "a server is a huge computer in an air-conditioned room", so "you can't run a server on a laptop".**

- A server is **a program that waits for requests** — not a special kind of computer.
- Any laptop can run server software. Later in the course you will run a server on your own computer.
- The same computer can be **a client and a server at the same time**: your browser (client) can contact a server running on the same laptop.
- Server rooms simply run many such server programs, on powerful computers that are always on.

**Second mistake:** thinking that a website "sits in the browser". The browser only **requests and shows**. The website, meaning the files and the logic, sits on the server.

### Summary

- **Network** = connected devices that pass information. **LAN** = a local network. **The internet** = a network of networks.
- The **router** connects the LAN to the internet and decides what stays inside and what goes out.
- The **client** initiates a request. The **server** waits, handles it and returns a response.
- Client and server are **roles of programs**. The same computer, and even the same program, can fill both.
- Every page you browse is a **request** from the client and a **response** from the server.

<!-- docs:start — generated by scripts/intro6/site_docs.py; edit the links there -->

### Official documentation

- [MDN — How does the Internet work?](https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/How_does_the_Internet_work)
- [MDN Glossary — Server](https://developer.mozilla.org/en-US/docs/Glossary/Server)

<!-- docs:end -->

## Chapter 2: IP Address, Port, Domain and DNS

### What will we learn?

Three questions every message on a network has to answer:

1. **To which computer?** — the **IP address**.
2. **To which program on that computer?** — the **port**.
3. **How do I know the address if I only remember a name?** — the **domain** and **DNS**.

### Why do we need this?

- In the backend and databases topics you will run a server on `http://127.0.0.1:8000`. Today you will understand every part of that address.
- An error like `Address already in use` (the port is taken) or `Name or service not known` (DNS failed) is routine in backend work.
- When you connect an app to a database, you need to give it a **host** and a **port**.

### Explanation from the basics

#### IP address — the computer's address

An **IP address** (Internet Protocol address) is a **numeric address** that identifies a device on the network. Without an address you cannot send it information, exactly like a letter without an address.

The common format, **IPv4**, is four numbers between 0 and 255, separated by dots:

```text
192.168.1.23
 │   │  │  │
 └───┴──┴──┴── four numbers, each 0–255
```

There is also **IPv6**, a newer and longer format (`2001:db8::1`), created because there were not enough IPv4 addresses for all the devices in the world. The principle is the same.

#### Three kinds of addresses worth knowing

| Kind | Example | What it is |
|---|---|---|
| **Private IP** | `192.168.x.x`, `10.x.x.x` | An address **inside the LAN**. The router gives it out. The same address can appear in thousands of different homes. |
| **Public IP** | `84.229.15.7` | The home's/office's address **on the internet**. All the devices at home go out through it, via the router. |
| **localhost / loopback** | `127.0.0.1` | **"This computer itself"**. Data sent there never leaves the computer. |

{{< box "analogy" "Analogy: an office building" >}}
**Public IP** = the building's street address ("10 Herzl Street"). **Private IP** = the office number inside the building ("room 23"). Every building has a "room 23", so it is not enough from the outside, but inside it is an exact identifier. **localhost** = "my own room": when I send there, I send to myself.
{{< /box >}}

#### Port — the door to the right program

An IP address brings the information **to the computer**. But many programs on the computer use the network: a browser, Spotify, Zoom, a server you wrote. How does the information reach **the right program**?

A **port** is **a number between 0 and 65535** that identifies a particular program on the computer. A server "**listens**" on a particular port, and every request that arrives at that port is passed to it.

```text
IP   = which building    →  192.168.1.23
Port = which apartment   →  8000
Full address             →  192.168.1.23:8000
```

Well-known ports:

| Port | Use |
|---|---|
| `80` | HTTP — websites (not encrypted) |
| `443` | HTTPS — websites (encrypted) |
| `22` | SSH — remote login to a server |
| `5432` | PostgreSQL — a database |
| `8000` / `8080` | Common for development servers (like ours in the backend and databases topics) |

**An important rule:** on each port (on each address) only **one program** can listen at any moment.

#### Domain and DNS — names instead of numbers

People don't remember `142.250.75.14`. We remember `google.com`.

- A **domain** is a **readable name** that stands for an address: `google.com`, `ynet.co.il`.
- **DNS** (Domain Name System) is **"the internet's phone book"**: a worldwide system of servers that translates a domain into an IP address.

The structure of a domain (read **from right to left**, from the general to the specific):

```text
   www   .   ynet   .   co   .   il
    │         │          │        │
subdomain   name      second    TLD (top-level domain: country/type)
```

**What happens in a DNS translation (in short):**

1. The computer checks whether it already knows the answer (the **cache**, a memory of previous answers).
2. If not, it asks the **DNS server** it was configured with (usually the internet provider's, or Google's `8.8.8.8`).
3. The DNS server finds the answer (asking other servers in the hierarchy if needed) and returns an IP address.
4. Only **after** that does the computer send the request itself to the address it received.

### DNS lookup — step by step

```text
You type:     example.com
     │  "What is the IP of example.com?"
     ▼
DNS server:   93.184.215.14
     │
     ▼
Browser connects to 93.184.215.14:443
```

1. You type a **name** — `example.com`.
2. The computer asks a **DNS** server: "what is the IP of this name?" (first it checks whether the answer is already saved from last time — the **cache**).
3. An **IP address** comes back.
4. Only now does the browser connect — to the **IP** and the **port** (443 for HTTPS).

A few example answers:

```text
google.com              ->  142.250.75.14
localhost               ->  127.0.0.1
no-such-domain-123.com  ->  lookup failed
```

- `localhost` is always translated to `127.0.0.1` — the computer itself.
- A name that does not exist — DNS finds no address for it, and the browser shows an error even **before** it tried to connect.

### Common mistake

**The mistake: running a second server on a port that is already taken.**

```text
Program A listens on port 8000   -> OK
Program B tries port 8000        -> ERROR

Address already in use
```

**Why?** Only **one** program can listen on a port at any moment. The first program "took" 8000.

**The fix:** stop the first program, or start the second one on another port, for example 8001.

{{< box "warn" "Especially in the backend topic" >}}
"I closed the terminal window but the server still holds the port": sometimes the process keeps running in the background. Find it (`Get-Process python` / `ps aux | grep python`) and stop it by PID, exactly as we learned in the topic on the computer and the operating system.
{{< /box >}}

**Second mistake:** confusing `localhost` with the IP on the LAN. `127.0.0.1` is reachable **only from the same computer**. If a friend tries to browse from their phone to `127.0.0.1:8000`, they will reach **their own phone**.

### Summary

- An **IP** identifies a **computer** on the network. Private (`192.168.x.x`) inside the LAN, public on the internet.
- **`127.0.0.1` / localhost** = this computer itself. Not reachable from other computers.
- A **port** identifies a **program** inside the computer. Only one program listens on each port. 80 = HTTP, 443 = HTTPS.
- A **domain** is a readable name. **DNS** translates it to an IP **before** the request is sent.
- A full address: `protocol://host:port/path`, for example `http://127.0.0.1:8000/students`.

<!-- docs:start — generated by scripts/intro6/site_docs.py; edit the links there -->

### Official documentation

- [MDN Glossary — IP Address](https://developer.mozilla.org/en-US/docs/Glossary/IP_Address)
- [MDN Glossary — Port](https://developer.mozilla.org/en-US/docs/Glossary/Port)
- [MDN Glossary — DNS](https://developer.mozilla.org/en-US/docs/Glossary/DNS)

<!-- docs:end -->

## Chapter 3: Request, Response and Protocols: HTTP, HTTPS, TCP and UDP

### What will we learn?

- What a **protocol** is.
- **Request** and **response**: what is sent and what comes back.
- **HTTP** and **HTTPS**: the language of the web.
- **TCP** and **UDP**: how the information itself is carried.

### Why do we need this?

The whole backend topic is built on HTTP: you will write a server that receives **requests** and returns **responses**, and you will choose a **method** (GET/POST/PUT/DELETE) and a **status code** (200, 404...). Today we see what it looks like "from the inside". Once you understand it, FastAPI will look like a shortcut, not like magic.

### Explanation from the basics

#### What is a protocol?

A **protocol** is **an agreed set of rules** for communication: what to send, in which order, in which format, and what to answer. If two sides do not speak the same protocol, they do not understand each other, even if the connection itself works.

{{< box "analogy" "Analogy: a phone call" >}}
A phone call is a "protocol": you call, the other side answers "hello", you say who is speaking, pass on the message, and say "bye". If someone answers and starts speaking a language you do not know, the connection works, but the communication does not.
{{< /box >}}

On a network there are **layers** of protocols, and each layer handles a different problem:

```text
HTTP / HTTPS   ← WHAT we say      (application: "give me /index.html")
TCP  / UDP     ← HOW it travels   (transport: reliable or fast)
IP             ← WHERE it goes    (addressing: 93.184.215.14)
Wi-Fi/Ethernet ← the physical link
```

#### Request and response

All HTTP communication is a pair:

- **Request** — the client sends: **what** it wants and **where**.
- **Response** — the server returns: **whether it succeeded**, and **the content**.

It is always the client that starts. An HTTP server sends nothing on its own initiative.

#### HTTP — HyperText Transfer Protocol

HTTP is a **text-based** protocol: the request and the response really are text you can read.

**The structure of a request:**

```text
GET /index.html HTTP/1.1          ← request line: METHOD  PATH  VERSION
Host: example.com                 ← headers: extra info, "Name: value"
User-Agent: Mozilla/5.0
Accept: text/html
                                  ← empty line = end of headers
(body — empty for GET)            ← body: data we send (used in POST/PUT)
```

| Part | Explanation |
|---|---|
| **Method** | **What** we want to do. `GET` = get. `POST` = create. `PUT` = update. `DELETE` = delete. |
| **Path** | **Which resource**: `/`, `/students`, `/students/7`. |
| **Headers** | Accompanying information: which site (`Host`), who is sending, which format is accepted. |
| **Body** | The data itself, for example a new student's details in a POST. |

**The structure of a response:**

```text
HTTP/1.1 200 OK                   ← status line: VERSION  STATUS CODE  REASON
Content-Type: text/html           ← headers
Content-Length: 1256
                                  ← empty line
<!doctype html><html>...          ← body: the content itself
```

**Status codes**, by their first digit:

| Range | Meaning | Examples |
|---|---|---|
| `2xx` | Success | `200 OK`, `201 Created` |
| `3xx` | Redirect elsewhere | `301 Moved Permanently` |
| `4xx` | The **client** made a mistake | `400 Bad Request`, `404 Not Found` |
| `5xx` | The **server** failed | `500 Internal Server Error` |

#### HTTPS — secure HTTP

In plain HTTP, the text travels the network **in the open**. Anyone sitting along the way (for example on public Wi-Fi) can read passwords and credit-card numbers.

**HTTPS** = HTTP + **encryption** (using a protocol called **TLS**). It adds two things:

1. **Encryption** — only the server and the client can read the content.
2. **Identity verification** — a **digital certificate** proves that you really are talking to `bank.co.il` and not to an impostor.

The HTTP inside the encryption is exactly the same. Port: HTTP = `80`, HTTPS = `443`. The lock icon 🔒 in the browser says the connection is HTTPS.

#### TCP and UDP — how the information travels

Information on a network is split into small **packets**. IP brings each packet to the right address, but packets can get lost or arrive in the wrong order. This is where TCP and UDP come in:

| | **TCP** | **UDP** |
|---|---|---|
| Reliability | **Guaranteed**: a lost packet is sent again | **Not guaranteed**: what is lost, is lost |
| Order | Arrives **in the right order** | Can arrive in a different order |
| Connection | Opens a **connection** before sending (handshake) | Sends right away, no connection |
| Speed | Slower (because of the checks) | **Fast** |
| Uses | Websites (HTTP/HTTPS), email, file transfer, databases | Video calls, online games, DNS, live streaming |

{{< box "analogy" "Analogy" >}}
**TCP** = registered mail: there is a delivery confirmation, and if the letter is lost, it is sent again. Reliable but takes time. **UDP** = shouting a message through a megaphone: fast, but if someone missed a word, nobody repeats it. In a video call it is better to lose one frame than to have the call freeze while it is sent again.
{{< /box >}}

**HTTP runs on top of TCP.** When the browser asks for a page, a TCP connection to the server is opened first (on port 80 or 443), and only then is the request text sent inside it.

### Common response codes

Every HTTP response starts with a **status code** — a three-digit number that says what happened. The first digit tells the "family":

| Code | Meaning | Example |
|---|---|---|
| **200 OK** | The request succeeded | The page loaded |
| **301** | The address moved elsewhere | A site that moved to a new address |
| **404 Not Found** | The path does not exist | A typo in the address |
| **500 Internal Server Error** | An error on the server side | The server code crashed |

- `2xx` — success. `3xx` — redirect. `4xx` — the **client's** mistake. `5xx` — the **server's** mistake.

### Common mistake

**The mistake: thinking that 404 means "the internet isn't working" or "the server is down".**

- `404` is a **valid response from the server**: "I got the request, but I have no resource at this path". The server **works perfectly**. The problem is in the request, that is, the path.
- If the server is **not available** at all, you get no status code. You get a connection error, such as `Connection refused` or `timed out`.
- `500` = the server got the request and **crashed** while handling it. In the backend topic, when you see 500, the bug is in your server code.

| What you got | Where the problem is |
|---|---|
| `200` | No problem |
| `404` | The path is wrong (client side) |
| `500` | A bug in the server code (server side) |
| Connection refused | No server is listening at this address/port |

**Second mistake: thinking HTTPS "hides" which site you are browsing.** The encryption protects the **content** — passwords, forms, the page itself — but the domain you connect to is still visible on the network.

### Summary

- **Protocol** = agreed rules for communication. There are layers: HTTP (what we say), TCP/UDP (how it travels), IP (where to).
- **HTTP request** = method + path + headers + body. **HTTP response** = status code + headers + body.
- Status codes: `2xx` success, `4xx` the client's mistake, `5xx` the server's mistake.
- **HTTPS** = HTTP + encryption and identity verification (TLS). Port 443.
- **TCP** is reliable and ordered (websites, files). **UDP** is fast and not guaranteed (video, games, DNS).

<!-- docs:start — generated by scripts/intro6/site_docs.py; edit the links there -->

### Official documentation

- [MDN — Overview of HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview)
- [MDN Glossary — HTTPS](https://developer.mozilla.org/en-US/docs/Glossary/HTTPS)
- [MDN Glossary — TCP](https://developer.mozilla.org/en-US/docs/Glossary/TCP)
- [MDN Glossary — UDP](https://developer.mozilla.org/en-US/docs/Glossary/UDP)

<!-- docs:end -->

## Chapter 4: What Happens from the Moment You Type an Address Until the Site Is Shown

### What will we learn?

This is a classic interview question: **"What happens when you type `https://www.example.com/about` in the browser and press Enter?"** In this chapter we will build a full answer, step by step, and connect all the terms from today: URL, DNS, IP, port, TCP, HTTPS, request, response.

### Why do we need this?

- It is the most common question in junior interviews. It checks whether you see the "big picture".
- When a site "doesn't work", someone who knows the steps knows **where** to look: DNS? the connection? the server? the content?
- In the backend and databases topics you will write **step 6**, the processing on the server. It is good to understand what happens before and after it.

### Explanation from the basics

#### Step 0 — breaking down the URL

A **URL** (Uniform Resource Locator) is the "full address" of a resource on the internet:

```text
https://www.example.com:443/about?lang=he
└─┬─┘   └──────┬──────┘ └┬┘ └─┬─┘ └──┬──┘
protocol     domain     port  path   query
```

| Part | Meaning |
|---|---|
| **Protocol (scheme)** | `https`: which protocol to speak. |
| **Domain (host)** | `www.example.com`: which server. It will be translated into an IP. |
| **Port** | `443`: usually not written. `https` = 443, `http` = 80. |
| **Path** | `/about`: which resource inside the server. |
| **Query** | `?lang=he`: extra parameters, in `key=value` format. Several parameters are joined with `&`. |

#### The eight steps

**1. The browser breaks down the URL** — it understands that the protocol is HTTPS (so port 443), that the domain is `www.example.com` and that the path is `/about`.

**2. DNS lookup — name → IP address.** The browser needs an IP, not a name. It checks in order: the browser's cache, the operating system's cache, and if there is no answer — it asks the DNS server. It gets, for example, `93.184.215.14`.

**3. TCP connection — the three-way handshake.** The browser opens a TCP connection to the address `93.184.215.14:443`. The connection opens with a "handshake" of three messages:

```text
Client ──── SYN ────────►  Server     "Can we talk?"
Client ◄─── SYN-ACK ─────  Server     "Yes, can you hear me?"
Client ──── ACK ────────►  Server     "Yes. Let's start."
```

**4. TLS handshake — encryption.** Because it is HTTPS: the server sends a **certificate**, the browser checks that it is genuine and belongs to `www.example.com`, and both sides agree on an encryption key. From here on everything is encrypted. (With `http://` there is no such step.)

**5. Sending the HTTP request:**

```text
GET /about?lang=he HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
```

**6. The server processes the request.** The server software receives the request, understands what was asked (`GET /about`), and prepares a response. Sometimes it is just a fixed file, and sometimes a lot of work: running code, a query to a **database**, building HTML. **This is the part you will write in the backend and databases topics.**

**7. The server sends the HTTP response:**

```text
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<!doctype html><html> ... <link href="/style.css"> <img src="/logo.png"> ...
```

**8. The browser displays it (rendering).** The browser reads the HTML and builds the page from it. When it comes across more files (CSS, images, JavaScript), it sends **more requests**, one per file, repeating steps 5–7. An average page makes dozens of requests! (The TCP connection and the encryption already exist, so steps 2–4 are usually not repeated.)

{{< box "analogy" "Analogy: ordering a delivery" >}}
1. You know you want "pizza from that restaurant" (URL). 2. You look up its address in the app (DNS). 3. You call and it answers (TCP handshake). 4. You make sure it really is the restaurant and not an impostor, and talk in a secret code (TLS). 5. You order (request). 6. The kitchen prepares it, maybe taking ingredients from the storeroom (processing + database). 7. The courier brings the dish (response). 8. You unpack and serve, and find that the sauces are missing, so you order more (requests for CSS and images).
{{< /box >}}

### How long each step takes

This whole journey usually takes less than a second. An example measurement of one request:

```text
Step 2 - DNS: example.com -> 93.184.215.14 | ms: 21
Step 3 - TCP connected to 93.184.215.14 443 | ms: 64
Step 4 - TLS version: TLSv1.3 | ms: 71
Steps 5-7 - first line: HTTP/1.1 200 OK | ms: 66
```

You can see the same timings in any browser: **F12** → the **Network** tab → click a request → **Timing**. The instructor will show it on the screen. There you can also see how many requests one page sends — sometimes dozens.

### Common mistake

**The mistake: skipping DNS or putting it after the connection** ("the browser connects to google.com"). You cannot connect to a name. A TCP connection needs an **IP**, so DNS always comes first.

**Second mistake: thinking the whole page arrives in one request.** The HTML arrives first, and from it the browser discovers dozens more files and requests each one separately. In the Network tab of DevTools you see this right away.

**Third mistake — diagnosing a failure wrongly:**

| The symptom | The step that failed |
|---|---|
| "DNS_PROBE_FINISHED_NXDOMAIN" / "server IP address could not be found" | **2** — DNS: no such domain, or a DNS problem |
| "Connection refused" / "timed out" | **3** — no server is listening, or the server is not reachable |
| "Your connection is not private" | **4** — a certificate problem in TLS |
| A "404 Not Found" page | **6–7** — the server works, but the path does not exist |
| A "500 Internal Server Error" page | **6** — the server code crashed |

### Summary

- **URL** = protocol + domain + port + path + query.
- The order: **break down the URL → DNS → TCP handshake → TLS → HTTP request → processing on the server → HTTP response → rendering**.
- DNS always comes **before** the connection, because you connect to an IP and not to a name.
- One page = dozens of requests: HTML first, then CSS, images and JS.
- Every kind of failure belongs to a particular step, and that is how you diagnose it.

<!-- docs:start — generated by scripts/intro6/site_docs.py; edit the links there -->

### Official documentation

- [MDN — How the web works](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works)

<!-- docs:end -->

<!-- exercises:start — generated by scripts/intro6/sync_site_exercises.py; edit scripts/intro6/exercises/ -->
## Practice

Comprehension questions on the lesson material — no code.

### Exercise 1: Client or Server?

In each scenario — who is the Client and who is the Server?

1. Browsing from your phone to a bank's website.
2. A weather app asks for a forecast.
3. Dana runs a program on her laptop that waits for requests, and opens it in the browser on the same laptop.

{{< solution >}}
1. **Client:** the browser on the phone. **Server:** the program that runs the bank's website.
2. **Client:** the app. **Server:** the service that returns forecasts.
3. **Both on the same laptop:** the browser is the Client, and the program that waits for requests is the Server. Client and Server are **roles of programs**, not kinds of computers.
{{< /solution >}}

### Exercise 2: IP, Port and DNS

1. What does an IP address identify, and what does a Port identify?
2. What does the address `127.0.0.1:8000` mean?
3. A friend tries to open `127.0.0.1:8000` on their phone to see a server running on your computer. Why won't it work?

{{< solution >}}
1. An **IP** identifies a **computer** on the network (which building). A **Port** identifies a **program** inside the computer (which apartment).
2. **`127.0.0.1`** is **localhost** — the computer itself. **`8000`** is the port the program listens on. Together: the program listening on port 8000 on this computer.
3. On the friend's phone, `127.0.0.1` is **the phone itself** — not your computer. localhost is reachable only from the same computer.
{{< /solution >}}

### Exercise 3: Breaking down a URL

Break the address into its parts — Protocol, Domain, Port, Path and Query:

```text
https://shop.example.com:443/cart?coupon=SALE10
```

And what would the port be if `:443` were not written in the address?

{{< solution >}}
| Part | Value |
|---|---|
| Protocol | `https` |
| Domain | `shop.example.com` |
| Port | `443` |
| Path | `/cart` |
| Query | `coupon=SALE10` |

When the port is not written, the browser uses the protocol's default port: **443 for HTTPS** (and 80 for HTTP).
{{< /solution >}}

### Exercise 4: Response codes

What does each code mean, and where is the problem — the Client or the Server?

```text
200   301   404   500
```

And what will the browser get if the server is not running at all?

{{< solution >}}
| Code | Meaning | Where the problem is |
|---|---|---|
| `200` | The request succeeded | No problem |
| `301` | The address moved elsewhere | No problem — a redirect |
| `404` | The path was not found | The **Client** — a wrong address |
| `500` | An error in the server code | The **Server** |

If the server is not running at all — **no Status Code comes back**. You get a connection error, such as `Connection refused` or `timed out`.
{{< /solution >}}

### Exercise 5: The journey of a request

Put the steps in order — from typing an address until the site is shown:

- (a) TCP connection — the three-way handshake
- (b) DNS — translating the name into an IP address
- (c) The browser displays the page (Rendering)
- (d) Sending the HTTP Request
- (e) Setting up encryption (TLS)
- (f) Breaking down the URL
- (g) The server returns the HTTP Response

And why must DNS come before the TCP connection?

{{< solution >}}
The order: **(f), (b), (a), (e), (d), (g), (c)**

1. Breaking down the URL.
2. DNS — name → IP address.
3. TCP connection (SYN, SYN-ACK, ACK).
4. TLS — encryption (because of HTTPS).
5. HTTP Request.
6. (The server processes the request.)
7. HTTP Response.
8. Rendering — and the browser requests more files (CSS, images).

DNS comes first because **a TCP connection needs an IP address** — you cannot connect to a name.
{{< /solution >}}

<!-- exercises:end -->