# Les réseaux et Internet : client-serveur, adresses, protocoles et le voyage d'une requête<no value>

## Dans cette leçon

Cette leçon se compose de quelques chapitres courts, dans le même ordre que les diapositives :

1. **Chapitre 1** — les réseaux informatiques, le LAN, Internet, le client et le serveur
2. **Chapitre 2** — l'adresse IP, le port, le domaine et le DNS
3. **Chapitre 3** — requête, réponse et protocoles : HTTP, HTTPS, TCP et UDP
4. **Chapitre 4** — ce qui se passe entre la saisie d'une adresse et l'affichage du site

## Chapitre 1 : Les réseaux informatiques, le LAN, Internet, le client et le serveur

### Qu'allons-nous apprendre ?

- Ce qu'est un **réseau informatique**.
- Le **LAN** (réseau local) face à **Internet**.
- Le **routeur**, l'appareil qui relie les réseaux.
- Le modèle **client-serveur**, la base de chaque site web, de chaque application et de chaque serveur que nous construirons dans les thèmes backend et bases de données.

### Pourquoi en avons-nous besoin ?

Chaque application moderne communique avec le réseau : WhatsApp, les sites web, les jeux, et dans les thèmes backend et bases de données aussi le serveur que vous écrirez. Les développeurs backend écrivent précisément le côté **serveur**. Les développeurs frontend écrivent le côté **client**. Sans comprendre ce modèle, vous ne pouvez pas comprendre ce que fait votre code.

### Explication à partir des bases

#### Qu'est-ce qu'un réseau ?

Un **réseau informatique** est formé de deux appareils ou plus, reliés afin de pouvoir **échanger de l'information**. La liaison peut se faire par câble (Ethernet), par les ondes (Wi-Fi) ou par fibre optique.

Pourquoi relier des ordinateurs ?

- **Partager de l'information** — des messages, des fichiers, des sites web.
- **Partager des ressources** — une imprimante pour tout le bureau, une connexion Internet pour toute la maison.
- **Répartir le travail** — l'information est conservée à un seul endroit (un serveur), et tout le monde y accède.

#### LAN — Local Area Network

Un **LAN** est un réseau **local** : les appareils de la maison, du bureau ou de la salle de classe. Chez vous, le LAN comprend l'ordinateur, le téléphone, la télévision connectée et l'imprimante, tous reliés au même **routeur**.

- Tous les appareils du LAN peuvent communiquer entre eux **directement**, sans sortir sur Internet.
- Très rapide, et sous votre contrôle.

#### Internet — un réseau de réseaux

**Internet** est un **réseau de réseaux** : des millions de réseaux locaux dans le monde entier, reliés entre eux par des fournisseurs d'accès (FAI, en anglais ISP) et des câbles sous-marins entre les continents.

#### Le routeur — la passerelle entre les réseaux

Le **routeur** est l'appareil qui relie votre LAN à Internet. Il sait si un paquet d'information doit rester à la maison (par exemple de l'ordinateur vers l'imprimante) ou sortir (par exemple vers un site web).

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

{{< box "analogy" "Analogie : le système postal" >}}
Un **LAN** est un appartement avec plusieurs habitants, qui se passent des mots à la main. Le **routeur** est la boîte aux lettres à l'entrée de l'immeuble : une lettre pour les voisins de l'appartement reste à l'intérieur, une lettre pour une autre ville part à la poste. **Internet** est tout le système postal mondial : bureaux, camions, avions, qui relient tous les immeubles du monde.
{{< /box >}}

#### Le modèle client-serveur

Presque toute la communication sur un réseau suit un seul modèle :

- **Client** — le programme qui **prend l'initiative** et envoie une **requête**. « Donne-moi la page d'accueil », « enregistre ce message ».
- **Serveur** — le programme qui **attend** des requêtes, les traite et renvoie une **réponse**.

| | Client | Serveur |
|---|---|---|
| Qui commence ? | **Lui** | Attend qu'on le contacte |
| Combien ? | De nombreux clients | En général un seul serveur (ou quelques-uns) les sert tous |
| Exemples | Un navigateur, une application mobile, `curl` | Un serveur web, un serveur de base de données, un serveur de messagerie |
| Durée de fonctionnement | Démarre quand on en a besoin puis se ferme | Tourne en permanence (24/7) |

**Très important :** client et serveur sont des **rôles de programmes**, pas des types d'ordinateurs. Le même ordinateur portable peut faire tourner un navigateur (client) et un serveur FastAPI (serveur) en même temps. Dans les thèmes backend et bases de données, c'est exactement ce que vous ferez : le serveur et le client tourneront sur le même ordinateur.

{{< box "analogy" "Analogie : un restaurant" >}}
Le **client** est le convive : il commande (une requête) et reçoit un plat (une réponse). Le **serveur** est la cuisine : elle attend les commandes, prépare et renvoie. Une seule cuisine sert de nombreux convives, et elle est ouverte même quand personne ne commande.
{{< /box >}}

### Requête et réponse — un exemple

Quand vous naviguez vers un site web, le navigateur est le **client** et le site est le **serveur** :

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

1. Le navigateur **prend l'initiative** — il envoie une requête : « donne-moi la page principale ».
2. Le serveur, qui **attend** toujours des requêtes, trouve la page.
3. Le serveur renvoie une **réponse** : un code de succès (`200`) et le contenu de la page.
4. Le navigateur **affiche** ce qu'il a reçu.

Le même schéma se répète dans chaque application : WhatsApp envoie un message au serveur, une application météo demande des prévisions, et plus tard dans le cours — un serveur que vous écrirez recevra des requêtes et renverra des réponses.

### Erreur courante

**L'erreur : « un serveur est un énorme ordinateur dans une salle climatisée », donc « on ne peut pas faire tourner un serveur sur un portable ».**

- Un serveur est **un programme qui attend des requêtes** — pas un type d'ordinateur particulier.
- N'importe quel portable peut faire tourner un logiciel serveur. Plus tard dans le cours, vous ferez tourner un serveur sur votre propre ordinateur.
- Le même ordinateur peut être **client et serveur en même temps** : votre navigateur (client) peut contacter un serveur qui tourne sur le même portable.
- Les salles serveurs font simplement tourner de nombreux programmes serveurs de ce genre, sur des ordinateurs puissants toujours allumés.

**Deuxième erreur :** croire qu'un site web « se trouve dans le navigateur ». Le navigateur ne fait que **demander et afficher**. Le site, c'est-à-dire les fichiers et la logique, se trouve sur le serveur.

### Résumé

- **Réseau** = des appareils reliés qui échangent de l'information. **LAN** = un réseau local. **Internet** = un réseau de réseaux.
- Le **routeur** relie le LAN à Internet et décide de ce qui reste à l'intérieur et de ce qui sort.
- Le **client** prend l'initiative d'une requête. Le **serveur** attend, la traite et renvoie une réponse.
- Client et serveur sont des **rôles de programmes**. Le même ordinateur, et même le même programme, peut remplir les deux.
- Chaque page que vous consultez est une **requête** du client et une **réponse** du serveur.

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

### Documentation officielle

- [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 -->

## Chapitre 2 : L'adresse IP, le port, le domaine et le DNS

### Qu'allons-nous apprendre ?

Trois questions auxquelles chaque message sur un réseau doit répondre :

1. **Vers quel ordinateur ?** — l'**adresse IP**.
2. **Vers quel programme sur cet ordinateur ?** — le **port**.
3. **Comment connaître l'adresse si je ne me souviens que d'un nom ?** — le **domaine** et le **DNS**.

### Pourquoi en avons-nous besoin ?

- Dans les thèmes backend et bases de données, vous lancerez un serveur sur `http://127.0.0.1:8000`. Aujourd'hui, vous comprendrez chaque partie de cette adresse.
- Une erreur comme `Address already in use` (le port est occupé) ou `Name or service not known` (le DNS a échoué) est courante dans le travail backend.
- Quand vous connectez une application à une base de données, vous devez lui donner un **hôte** (host) et un **port**.

### Explication à partir des bases

#### L'adresse IP — l'adresse de l'ordinateur

Une **adresse IP** (Internet Protocol address) est une **adresse numérique** qui identifie un appareil sur le réseau. Sans adresse, on ne peut pas lui envoyer d'information, exactement comme une lettre sans adresse.

Le format courant, **IPv4**, se compose de quatre nombres entre 0 et 255, séparés par des points :

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

Il existe aussi **IPv6**, un format plus récent et plus long (`2001:db8::1`), créé parce qu'il n'y avait pas assez d'adresses IPv4 pour tous les appareils du monde. Le principe est le même.

#### Trois types d'adresses à connaître

| Type | Exemple | Ce que c'est |
|---|---|---|
| **IP privée** | `192.168.x.x`, `10.x.x.x` | Une adresse **à l'intérieur du LAN**. C'est le routeur qui l'attribue. La même adresse peut apparaître dans des milliers de foyers différents. |
| **IP publique** | `84.229.15.7` | L'adresse de la maison/du bureau **sur Internet**. Tous les appareils de la maison sortent par elle, via le routeur. |
| **localhost / loopback** | `127.0.0.1` | **« Cet ordinateur lui-même »**. Les données envoyées là ne quittent jamais l'ordinateur. |

{{< box "analogy" "Analogie : un immeuble de bureaux" >}}
**IP publique** = l'adresse postale de l'immeuble (« 10 rue Herzl »). **IP privée** = le numéro du bureau dans l'immeuble (« pièce 23 »). Chaque immeuble a une « pièce 23 », ce n'est donc pas suffisant depuis l'extérieur, mais à l'intérieur c'est un identifiant exact. **localhost** = « ma propre pièce » : quand j'envoie là, je m'envoie à moi-même.
{{< /box >}}

#### Le port — la porte vers le bon programme

Une adresse IP amène l'information **jusqu'à l'ordinateur**. Mais de nombreux programmes de l'ordinateur utilisent le réseau : un navigateur, Spotify, Zoom, un serveur que vous avez écrit. Comment l'information arrive-t-elle **au bon programme** ?

Un **port** est **un nombre entre 0 et 65535** qui identifie un programme précis sur l'ordinateur. Un serveur « **écoute** » sur un port précis, et chaque requête qui arrive sur ce port lui est transmise.

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

Des ports connus :

| Port | Usage |
|---|---|
| `80` | HTTP — sites web (non chiffré) |
| `443` | HTTPS — sites web (chiffré) |
| `22` | SSH — connexion à distance à un serveur |
| `5432` | PostgreSQL — une base de données |
| `8000` / `8080` | Courants pour les serveurs de développement (comme le nôtre dans les thèmes backend et bases de données) |

**Une règle importante :** sur chaque port (à chaque adresse), un **seul programme** peut écouter à un instant donné.

#### Le domaine et le DNS — des noms à la place des nombres

Les gens ne retiennent pas `142.250.75.14`. Nous retenons `google.com`.

- Un **domaine** est un **nom lisible** qui représente une adresse : `google.com`, `ynet.co.il`.
- Le **DNS** (Domain Name System) est **« l'annuaire d'Internet »** : un système mondial de serveurs qui traduit un domaine en adresse IP.

La structure d'un domaine (se lit **de droite à gauche**, du général au particulier) :

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

**Ce qui se passe lors d'une traduction DNS (en bref) :**

1. L'ordinateur vérifie s'il connaît déjà la réponse (le **cache**, une mémoire des réponses précédentes).
2. Sinon, il interroge le **serveur DNS** avec lequel il a été configuré (en général celui du fournisseur d'accès, ou le `8.8.8.8` de Google).
3. Le serveur DNS trouve la réponse (en interrogeant d'autres serveurs de la hiérarchie si nécessaire) et renvoie une adresse IP.
4. Ce n'est **qu'après** que l'ordinateur envoie la requête elle-même à l'adresse reçue.

### La résolution DNS — étape par étape

```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. Vous tapez un **nom** — `example.com`.
2. L'ordinateur demande à un serveur **DNS** : « quelle est l'IP de ce nom ? » (il vérifie d'abord si la réponse est déjà enregistrée depuis la dernière fois — le **cache**).
3. Une **adresse IP** revient.
4. Ce n'est que maintenant que le navigateur se connecte — à l'**IP** et au **port** (443 pour HTTPS).

Quelques exemples de réponses :

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

- `localhost` est toujours traduit en `127.0.0.1` — l'ordinateur lui-même.
- Un nom qui n'existe pas — le DNS ne trouve aucune adresse pour lui, et le navigateur affiche une erreur avant même **d'avoir** tenté de se connecter.

### Erreur courante

**L'erreur : lancer un second serveur sur un port déjà occupé.**

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

Address already in use
```

**Pourquoi ?** Un **seul** programme peut écouter sur un port à un instant donné. Le premier programme a « pris » le 8000.

**La correction :** arrêter le premier programme, ou lancer le second sur un autre port, par exemple 8001.

{{< box "warn" "Surtout dans le thème backend" >}}
« J'ai fermé la fenêtre du terminal mais le serveur occupe toujours le port » : parfois le processus continue de tourner en arrière-plan. Trouvez-le (`Get-Process python` / `ps aux | grep python`) et arrêtez-le par son PID, exactement comme nous l'avons appris dans le thème sur l'ordinateur et le système d'exploitation.
{{< /box >}}

**Deuxième erreur :** confondre `localhost` avec l'IP sur le LAN. `127.0.0.1` n'est accessible **que depuis le même ordinateur**. Si un ami essaie de naviguer depuis son téléphone vers `127.0.0.1:8000`, il arrivera sur **son propre téléphone**.

### Résumé

- Une **IP** identifie un **ordinateur** sur le réseau. Privée (`192.168.x.x`) à l'intérieur du LAN, publique sur Internet.
- **`127.0.0.1` / localhost** = cet ordinateur lui-même. Inaccessible depuis d'autres ordinateurs.
- Un **port** identifie un **programme** à l'intérieur de l'ordinateur. Un seul programme écoute sur chaque port. 80 = HTTP, 443 = HTTPS.
- Un **domaine** est un nom lisible. Le **DNS** le traduit en IP **avant** l'envoi de la requête.
- Une adresse complète : `protocol://host:port/path`, par exemple `http://127.0.0.1:8000/students`.

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

### Documentation officielle

- [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 -->

## Chapitre 3 : Requête, réponse et protocoles : HTTP, HTTPS, TCP et UDP

### Qu'allons-nous apprendre ?

- Ce qu'est un **protocole**.
- La **requête** et la **réponse** : ce qui est envoyé et ce qui revient.
- **HTTP** et **HTTPS** : la langue du web.
- **TCP** et **UDP** : comment l'information elle-même est transportée.

### Pourquoi en avons-nous besoin ?

Tout le thème backend repose sur HTTP : vous écrirez un serveur qui reçoit des **requêtes** et renvoie des **réponses**, et vous choisirez une **méthode** (GET/POST/PUT/DELETE) et un **code d'état** (200, 404...). Aujourd'hui, nous voyons à quoi cela ressemble « de l'intérieur ». Une fois que vous l'aurez compris, FastAPI ressemblera à un raccourci, pas à de la magie.

### Explication à partir des bases

#### Qu'est-ce qu'un protocole ?

Un **protocole** est **un ensemble de règles convenues** pour communiquer : quoi envoyer, dans quel ordre, dans quel format, et quoi répondre. Si deux parties ne parlent pas le même protocole, elles ne se comprennent pas, même si la connexion elle-même fonctionne.

{{< box "analogy" "Analogie : un appel téléphonique" >}}
Un appel téléphonique est un « protocole » : vous appelez, l'autre côté répond « allô », vous dites qui parle, vous transmettez le message, et vous dites « au revoir ». Si quelqu'un répond et se met à parler une langue que vous ne connaissez pas, la connexion fonctionne, mais pas la communication.
{{< /box >}}

Sur un réseau, il y a des **couches** de protocoles, et chaque couche traite un problème différent :

```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
```

#### Requête et réponse

Toute communication HTTP est une paire :

- **Requête** (request) — le client envoie : **ce** qu'il veut et **où**.
- **Réponse** (response) — le serveur renvoie : **si cela a réussi**, et **le contenu**.

C'est toujours le client qui commence. Un serveur HTTP n'envoie rien de sa propre initiative.

#### HTTP — HyperText Transfer Protocol

HTTP est un protocole **textuel** : la requête et la réponse sont vraiment du texte que l'on peut lire.

**La structure d'une requête :**

```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)
```

| Partie | Explication |
|---|---|
| **Méthode** | **Ce** que nous voulons faire. `GET` = obtenir. `POST` = créer. `PUT` = mettre à jour. `DELETE` = supprimer. |
| **Chemin** (path) | **Quelle ressource** : `/`, `/students`, `/students/7`. |
| **En-têtes** (headers) | Des informations d'accompagnement : quel site (`Host`), qui envoie, quel format est accepté. |
| **Corps** (body) | Les données elles-mêmes, par exemple les informations d'un nouvel étudiant dans un POST. |

**La structure d'une réponse :**

```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
```

**Les codes d'état**, selon leur premier chiffre :

| Plage | Signification | Exemples |
|---|---|---|
| `2xx` | Succès | `200 OK`, `201 Created` |
| `3xx` | Redirection ailleurs | `301 Moved Permanently` |
| `4xx` | Le **client** s'est trompé | `400 Bad Request`, `404 Not Found` |
| `5xx` | Le **serveur** a échoué | `500 Internal Server Error` |

#### HTTPS — HTTP sécurisé

En HTTP simple, le texte circule sur le réseau **en clair**. Toute personne placée sur le chemin (par exemple sur un Wi-Fi public) peut lire les mots de passe et les numéros de carte bancaire.

**HTTPS** = HTTP + **chiffrement** (avec un protocole appelé **TLS**). Il ajoute deux choses :

1. **Le chiffrement** — seuls le serveur et le client peuvent lire le contenu.
2. **La vérification d'identité** — un **certificat numérique** prouve que vous parlez vraiment à `bank.co.il` et non à un imposteur.

Le HTTP à l'intérieur du chiffrement est exactement le même. Port : HTTP = `80`, HTTPS = `443`. L'icône du cadenas 🔒 dans le navigateur indique que la connexion est en HTTPS.

#### TCP et UDP — comment l'information circule

L'information sur un réseau est découpée en petits **paquets**. IP amène chaque paquet à la bonne adresse, mais des paquets peuvent se perdre ou arriver dans le désordre. C'est là qu'interviennent TCP et UDP :

| | **TCP** | **UDP** |
|---|---|---|
| Fiabilité | **Garantie** : un paquet perdu est renvoyé | **Non garantie** : ce qui est perdu est perdu |
| Ordre | Arrive **dans le bon ordre** | Peut arriver dans un autre ordre |
| Connexion | Ouvre une **connexion** avant d'envoyer (handshake) | Envoie tout de suite, sans connexion |
| Vitesse | Plus lent (à cause des vérifications) | **Rapide** |
| Usages | Sites web (HTTP/HTTPS), e-mail, transfert de fichiers, bases de données | Appels vidéo, jeux en ligne, DNS, diffusion en direct |

{{< box "analogy" "Analogie" >}}
**TCP** = un envoi recommandé : il y a un accusé de réception, et si la lettre se perd, elle est renvoyée. Fiable mais prend du temps. **UDP** = crier un message au mégaphone : rapide, mais si quelqu'un a manqué un mot, personne ne le répète. Dans un appel vidéo, mieux vaut perdre une image que voir l'appel se figer pendant qu'on la renvoie.
{{< /box >}}

**HTTP fonctionne au-dessus de TCP.** Quand le navigateur demande une page, une connexion TCP vers le serveur est d'abord ouverte (sur le port 80 ou 443), et ce n'est qu'ensuite que le texte de la requête y est envoyé.

### Codes de réponse courants

Chaque réponse HTTP commence par un **code d'état** — un nombre à trois chiffres qui dit ce qui s'est passé. Le premier chiffre indique la « famille » :

| Code | Signification | Exemple |
|---|---|---|
| **200 OK** | La requête a réussi | La page s'est chargée |
| **301** | L'adresse a été déplacée ailleurs | Un site qui a déménagé à une nouvelle adresse |
| **404 Not Found** | Le chemin n'existe pas | Une faute de frappe dans l'adresse |
| **500 Internal Server Error** | Une erreur côté serveur | Le code du serveur a planté |

- `2xx` — succès. `3xx` — redirection. `4xx` — l'erreur du **client**. `5xx` — l'erreur du **serveur**.

### Erreur courante

**L'erreur : croire que 404 signifie « Internet ne fonctionne pas » ou « le serveur est en panne ».**

- `404` est une **réponse valide du serveur** : « j'ai reçu la requête, mais je n'ai aucune ressource à ce chemin ». Le serveur **fonctionne parfaitement**. Le problème est dans la requête, c'est-à-dire le chemin.
- Si le serveur n'est **pas du tout disponible**, vous ne recevez aucun code d'état. Vous obtenez une erreur de connexion, comme `Connection refused` ou `timed out`.
- `500` = le serveur a reçu la requête et **a planté** en la traitant. Dans le thème backend, quand vous voyez 500, le bug est dans le code de votre serveur.

| Ce que vous avez reçu | Où est le problème |
|---|---|
| `200` | Aucun problème |
| `404` | Le chemin est faux (côté client) |
| `500` | Un bug dans le code du serveur (côté serveur) |
| Connection refused | Aucun serveur n'écoute à cette adresse/ce port |

**Deuxième erreur : croire que HTTPS « cache » le site que vous consultez.** Le chiffrement protège le **contenu** — les mots de passe, les formulaires, la page elle-même — mais le domaine auquel vous vous connectez reste visible sur le réseau.

### Résumé

- **Protocole** = des règles convenues pour communiquer. Il y a des couches : HTTP (ce que l'on dit), TCP/UDP (comment cela circule), IP (vers où).
- **Requête HTTP** = méthode + chemin + en-têtes + corps. **Réponse HTTP** = code d'état + en-têtes + corps.
- Codes d'état : `2xx` succès, `4xx` erreur du client, `5xx` erreur du serveur.
- **HTTPS** = HTTP + chiffrement et vérification d'identité (TLS). Port 443.
- **TCP** est fiable et ordonné (sites web, fichiers). **UDP** est rapide et non garanti (vidéo, jeux, DNS).

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

### Documentation officielle

- [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 -->

## Chapitre 4 : Ce qui se passe entre la saisie d'une adresse et l'affichage du site

### Qu'allons-nous apprendre ?

C'est une question d'entretien classique : **« Que se passe-t-il quand vous tapez `https://www.example.com/about` dans le navigateur et appuyez sur Entrée ? »** Dans ce chapitre, nous construirons une réponse complète, étape par étape, et relierons tous les termes du jour : URL, DNS, IP, port, TCP, HTTPS, requête, réponse.

### Pourquoi en avons-nous besoin ?

- C'est la question la plus fréquente dans les entretiens pour débutants. Elle vérifie que vous voyez la « vue d'ensemble ».
- Quand un site « ne marche pas », celui qui connaît les étapes sait **où** chercher : le DNS ? la connexion ? le serveur ? le contenu ?
- Dans les thèmes backend et bases de données, vous écrirez **l'étape 6**, le traitement sur le serveur. Il est bon de comprendre ce qui se passe avant et après.

### Explication à partir des bases

#### Étape 0 — décomposer l'URL

Une **URL** (Uniform Resource Locator) est « l'adresse complète » d'une ressource sur Internet :

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

| Partie | Signification |
|---|---|
| **Protocole** (scheme) | `https` : quel protocole parler. |
| **Domaine** (host) | `www.example.com` : quel serveur. Il sera traduit en IP. |
| **Port** | `443` : généralement non écrit. `https` = 443, `http` = 80. |
| **Chemin** (path) | `/about` : quelle ressource sur le serveur. |
| **Query** | `?lang=he` : des paramètres supplémentaires, au format `key=value`. Plusieurs paramètres sont reliés par `&`. |

#### Les huit étapes

**1. Le navigateur décompose l'URL** — il comprend que le protocole est HTTPS (donc le port 443), que le domaine est `www.example.com` et que le chemin est `/about`.

**2. Résolution DNS — nom → adresse IP.** Le navigateur a besoin d'une IP, pas d'un nom. Il vérifie dans l'ordre : le cache du navigateur, le cache du système d'exploitation, et s'il n'y a pas de réponse — il interroge le serveur DNS. Il reçoit, par exemple, `93.184.215.14`.

**3. Connexion TCP — la poignée de main en trois temps.** Le navigateur ouvre une connexion TCP vers l'adresse `93.184.215.14:443`. La connexion s'ouvre par une « poignée de main » (handshake) de trois 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. Poignée de main TLS — le chiffrement.** Parce que c'est du HTTPS : le serveur envoie un **certificat**, le navigateur vérifie qu'il est authentique et qu'il appartient à `www.example.com`, et les deux parties se mettent d'accord sur une clé de chiffrement. À partir de là, tout est chiffré. (Avec `http://`, il n'y a pas cette étape.)

**5. Envoi de la requête HTTP :**

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

**6. Le serveur traite la requête.** Le logiciel serveur reçoit la requête, comprend ce qui est demandé (`GET /about`) et prépare une réponse. Parfois c'est juste un fichier fixe, et parfois beaucoup de travail : exécuter du code, une requête à une **base de données**, construire du HTML. **C'est la partie que vous écrirez dans les thèmes backend et bases de données.**

**7. Le serveur envoie la réponse HTTP :**

```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. Le navigateur l'affiche (rendu).** Le navigateur lit le HTML et construit la page à partir de lui. Quand il tombe sur d'autres fichiers (CSS, images, JavaScript), il envoie **d'autres requêtes**, une par fichier, en répétant les étapes 5 à 7. Une page moyenne fait des dizaines de requêtes ! (La connexion TCP et le chiffrement existent déjà, donc les étapes 2 à 4 ne sont généralement pas répétées.)

{{< box "analogy" "Analogie : commander une livraison" >}}
1. Vous savez que vous voulez « une pizza de ce restaurant » (URL). 2. Vous cherchez son adresse dans l'application (DNS). 3. Vous appelez et il répond (poignée de main TCP). 4. Vous vous assurez que c'est vraiment le restaurant et non un imposteur, et vous parlez dans un code secret (TLS). 5. Vous commandez (requête). 6. La cuisine prépare, en prenant peut-être des ingrédients dans la réserve (traitement + base de données). 7. Le livreur apporte le plat (réponse). 8. Vous déballez et servez, et vous découvrez qu'il manque les sauces, alors vous en recommandez (requêtes pour le CSS et les images).
{{< /box >}}

### Combien de temps prend chaque étape

Tout ce voyage prend généralement moins d'une seconde. Un exemple de mesure d'une requête :

```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
```

Vous pouvez voir les mêmes durées dans n'importe quel navigateur : **F12** → l'onglet **Network** → cliquez sur une requête → **Timing**. Le formateur le montrera à l'écran. Vous pourrez aussi y voir combien de requêtes envoie une seule page — parfois des dizaines.

### Erreur courante

**L'erreur : sauter le DNS ou le placer après la connexion** (« le navigateur se connecte à google.com »). On ne peut pas se connecter à un nom. Une connexion TCP a besoin d'une **IP**, donc le DNS vient toujours en premier.

**Deuxième erreur : croire que toute la page arrive en une seule requête.** Le HTML arrive en premier, et à partir de lui le navigateur découvre des dizaines d'autres fichiers et demande chacun séparément. Dans l'onglet Network des DevTools, on le voit tout de suite.

**Troisième erreur — mal diagnostiquer une panne :**

| Le symptôme | L'étape qui a échoué |
|---|---|
| « DNS_PROBE_FINISHED_NXDOMAIN » / « server IP address could not be found » | **2** — DNS : ce domaine n'existe pas, ou un problème de DNS |
| « Connection refused » / « timed out » | **3** — aucun serveur n'écoute, ou le serveur est inaccessible |
| « Your connection is not private » | **4** — un problème de certificat dans TLS |
| Une page « 404 Not Found » | **6–7** — le serveur fonctionne, mais le chemin n'existe pas |
| Une page « 500 Internal Server Error » | **6** — le code du serveur a planté |

### Résumé

- **URL** = protocole + domaine + port + chemin + query.
- L'ordre : **décomposer l'URL → DNS → poignée de main TCP → TLS → requête HTTP → traitement sur le serveur → réponse HTTP → rendu**.
- Le DNS vient toujours **avant** la connexion, car on se connecte à une IP et non à un nom.
- Une page = des dizaines de requêtes : d'abord le HTML, puis le CSS, les images et le JS.
- Chaque type de panne appartient à une étape précise, et c'est ainsi qu'on la diagnostique.

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

### Documentation officielle

- [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/ -->
## Exercices

Questions de compréhension sur le contenu de la leçon — sans code.

### Exercice 1: Client ou serveur ?

Dans chaque scénario — qui est le client et qui est le serveur ?

1. Naviguer depuis votre téléphone vers le site d'une banque.
2. Une application météo demande des prévisions.
3. Dana lance sur son portable un programme qui attend des requêtes, et l'ouvre dans le navigateur du même portable.

{{< solution >}}
1. **Client :** le navigateur du téléphone. **Serveur :** le programme qui fait tourner le site de la banque.
2. **Client :** l'application. **Serveur :** le service qui renvoie les prévisions.
3. **Les deux sur le même portable :** le navigateur est le client, et le programme qui attend des requêtes est le serveur. Client et serveur sont des **rôles de programmes**, pas des types d'ordinateurs.
{{< /solution >}}

### Exercice 2: IP, port et DNS

1. Qu'identifie une adresse IP, et qu'identifie un port ?
2. Que signifie l'adresse `127.0.0.1:8000` ?
3. Un ami essaie d'ouvrir `127.0.0.1:8000` sur son téléphone pour voir un serveur qui tourne sur votre ordinateur. Pourquoi cela ne fonctionnera-t-il pas ?

{{< solution >}}
1. Une **IP** identifie un **ordinateur** sur le réseau (quel immeuble). Un **port** identifie un **programme** à l'intérieur de l'ordinateur (quel appartement).
2. **`127.0.0.1`** est **localhost** — l'ordinateur lui-même. **`8000`** est le port sur lequel le programme écoute. Ensemble : le programme qui écoute sur le port 8000 de cet ordinateur.
3. Sur le téléphone de l'ami, `127.0.0.1` est **le téléphone lui-même** — pas votre ordinateur. localhost n'est accessible que depuis le même ordinateur.
{{< /solution >}}

### Exercice 3: Décomposer une URL

Décomposez l'adresse en ses parties — protocole, domaine, port, chemin et query :

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

Et quel serait le port si `:443` n'était pas écrit dans l'adresse ?

{{< solution >}}
| Partie | Valeur |
|---|---|
| Protocole | `https` |
| Domaine | `shop.example.com` |
| Port | `443` |
| Chemin | `/cart` |
| Query | `coupon=SALE10` |

Quand le port n'est pas écrit, le navigateur utilise le port par défaut du protocole : **443 pour HTTPS** (et 80 pour HTTP).
{{< /solution >}}

### Exercice 4: Codes de réponse

Que signifie chaque code, et où est le problème — chez le client ou chez le serveur ?

```text
200   301   404   500
```

Et que recevra le navigateur si le serveur ne tourne pas du tout ?

{{< solution >}}
| Code | Signification | Où est le problème |
|---|---|---|
| `200` | La requête a réussi | Aucun problème |
| `301` | L'adresse a été déplacée ailleurs | Aucun problème — une redirection |
| `404` | Le chemin est introuvable | Le **client** — une mauvaise adresse |
| `500` | Une erreur dans le code du serveur | Le **serveur** |

Si le serveur ne tourne pas du tout — **aucun code d'état ne revient**. Vous obtenez une erreur de connexion, comme `Connection refused` ou `timed out`.
{{< /solution >}}

### Exercice 5: Le voyage d'une requête

Remettez les étapes dans l'ordre — de la saisie d'une adresse jusqu'à l'affichage du site :

- (a) Connexion TCP — la poignée de main en trois temps
- (b) DNS — traduire le nom en adresse IP
- (c) Le navigateur affiche la page (rendu)
- (d) Envoi de la requête HTTP
- (e) Mise en place du chiffrement (TLS)
- (f) Décomposition de l'URL
- (g) Le serveur renvoie la réponse HTTP

Et pourquoi le DNS doit-il venir avant la connexion TCP ?

{{< solution >}}
L'ordre : **(f), (b), (a), (e), (d), (g), (c)**

1. Décomposition de l'URL.
2. DNS — nom → adresse IP.
3. Connexion TCP (SYN, SYN-ACK, ACK).
4. TLS — chiffrement (à cause de HTTPS).
5. Requête HTTP.
6. (Le serveur traite la requête.)
7. Réponse HTTP.
8. Rendu — et le navigateur demande d'autres fichiers (CSS, images).

Le DNS vient en premier parce qu'**une connexion TCP a besoin d'une adresse IP** — on ne peut pas se connecter à un nom.
{{< /solution >}}

<!-- exercises:end -->