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

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

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

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.

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.

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 :

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.

Documentation officielle#

• MDN — How does the Internet work?
• MDN Glossary — Server

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 :

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#

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.

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

Des ports connus :

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

   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#

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 :

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é.

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.

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.

Documentation officielle#

• MDN Glossary — IP Address
• MDN Glossary — Port
• MDN Glossary — DNS

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.

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

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 :

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)

La structure d’une réponse :

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 :

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 :

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 » :

• 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.

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

Documentation officielle#

• MDN — Overview of HTTP
• MDN Glossary — HTTPS
• MDN Glossary — TCP
• MDN Glossary — UDP

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 :

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

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 :

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 :

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 :

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

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 :

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 :

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.

Documentation officielle#

• MDN — How the web works

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.

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 ?

Exercice 3: Décomposer une URL#

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

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

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

Exercice 4: Codes de réponse#

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

200   301   404   500

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

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 ?