Comprendre le modèle Client-Serveur, le protocole HTTP, les DNS et le fonctionnement des requêtes.
PHASE 1.2 : ARCHITECTURE DU WEB
Version Ultra-Détaillée
🎯 1. LE MODÈLE CLIENT-SERVEUR
La Métaphore Fondamentale
Imagine un restaurant gastronomique :
-
▹
Le client = Toi (tu commandes un plat).
-
▹
Le serveur = Le cuisinier (il prépare le plat).
-
▹
La commande = La requête HTTP (tu demandes une page web).
-
▹
Le plat = La réponse HTTP (la page web servie).
-
▹
La carte = L'URL (tu choisis ce que tu veux).
Définition Technique
Client-Serveur est un modèle d'architecture où :
- Le client (navigateur, application mobile) envoie des requêtes.
- Le serveur (ordinateur distant) traite les requêtes et renvoie des réponses.
- La communication se fait via des protocoles (HTTP, HTTPS, FTP, etc.).
Les Types de Clients
| Type | Exemples | Caractéristiques |
|---|---|---|
| Navigateur Web | Chrome, Firefox, Safari | Interface graphique, rendu HTML/CSS/JS |
| Application Mobile | iOS, Android | Native ou hybride (React Native, Flutter) |
| API Client | Postman, curl, SDK | Requêtes programmatiques (CLI) |
| IoT Device | Capteurs, montres connectées | Ressources limitées, protocoles légers |
| Web Scraper | Python (Requests), Puppeteer | Récupération automatisée de données |
Les Types de Serveurs
| Type | Exemples | Rôle |
|---|---|---|
| Serveur Web | Nginx, Apache, Express | Servir des pages HTML, fichiers statiques |
| Serveur d'Application | Node.js, Django, Spring Boot | Logique métier, API, calculs |
| Serveur de Base de Données | PostgreSQL, MongoDB, Redis | Stockage et gestion des données |
| Serveur Proxy | HAProxy, Squid | Cache, équilibrage de charge, sécurité |
| Serveur de Fichiers | FTP, S3, NFS | Stockage et distribution de fichiers |
| Serveur DNS | Cloudflare, Google DNS | Résolution de noms de domaine |
Le Cycle de Vie d'une Requête
Client → [1] Résolution DNS → [2] Connexion TCP → [3] Envoi Requête HTTP
Client ← [6] Affichage Page ← [5] Réception Réponse ← [4] Traitement Serveur
Détail technique : Chaque étape est chronométrée. Le TTFB (Time To First Byte) mesure le temps entre la requête et le premier octet reçu.
🌐 2. LES PROTOCOLES : LE CŒUR DU WEB
2.1 HTTP (HyperText Transfer Protocol)
HTTP est le protocole de communication qui permet aux clients et aux serveurs d'échanger des données sur le Web.
Historique des Versions
| Version | Année | Caractéristiques | Problèmes Résolus |
|---|---|---|---|
| HTTP/0.9 | 1991 | Une seule méthode (GET), pas d'en-têtes | Très basique, limité |
| HTTP/1.0 | 1996 | Ajout des en-têtes, méthodes POST, HEAD | Communication plus riche |
| HTTP/1.1 | 1997 | Persistent connections, pipelining, chunked transfer | Réduction de la latence |
| HTTP/2 | 2015 | Multiplexage, compression des en-têtes, server push | Performance massive |
| HTTP/3 | 2022 | Basé sur QUIC (UDP), pas de TCP | Réduction de la latence, meilleure mobilité |
Détail méconnu : HTTP/1.1 a été la version la plus longue (1997-2015) et est toujours utilisée par environ 30% des sites en 2026.
Méthodes HTTP (Verbes)
| Méthode | Rôle | Idempotent ? | Sûr ? | Exemple |
|---|---|---|---|---|
| GET | Récupérer une ressource | ✅ Oui | ✅ Oui | GET /users/123 |
| POST | Créer une ressource | ❌ Non | ❌ Non | POST /users |
| PUT | Remplacer une ressource | ✅ Oui | ❌ Non | PUT /users/123 |
| PATCH | Mettre à jour partiellement | ❌ Non | ❌ Non | PATCH /users/123 |
| DELETE | Supprimer une ressource | ✅ Oui | ❌ Non | DELETE /users/123 |
| HEAD | Récupérer les en-têtes uniquement | ✅ Oui | ✅ Oui | HEAD /users/123 |
| OPTIONS | Décrire les options disponibles | ✅ Oui | ✅ Oui | OPTIONS /users |
Détail méconnu : PATCH n'est pas idempotent car deux patches différents peuvent donner des résultats différents sur le même état initial.
Codes de Statut HTTP (Familles)
| Famille | Signification | Exemples |
|---|---|---|
| 1xx | Informational (Requête en cours) | 100 (Continue), 101 (Switching Protocols) |
| 2xx | Success (Requête réussie) | 200 (OK), 201 (Created), 204 (No Content) |
| 3xx | Redirection | 301 (Moved Permanently), 302 (Found), 304 (Not Modified) |
| 4xx | Client Error (Erreur client) | 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found) |
| 5xx | Server Error (Erreur serveur) | 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable) |
Détail méconnu : Le code 418 (I'm a teapot) est un easter egg d'HTTP, créé comme blague pour April Fools' Day 1998.
En-têtes HTTP (Headers)
En-têtes de Requête (Request Headers) :
GET /users/123 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Chrome 120)
Accept: application/json
Authorization: Bearer <token>
Content-Type: application/json
En-têtes de Réponse (Response Headers) :
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234
Cache-Control: max-age=3600
Set-Cookie: session_id=abc123
En-têtes Courants :
| Header | Rôle | Exemple |
|---|---|---|
| Host | Nom de domaine cible | Host: api.example.com |
| User-Agent | Identifie le client | Mozilla/5.0 (Chrome 120) |
| Accept | Formats acceptés | application/json |
| Authorization | Authentification | Bearer <token> |
| Content-Type | Format des données | application/json |
| Cookie | Session client | session_id=abc123 |
| Cache-Control | Stratégie de cache | max-age=3600 |
| CORS | Cross-Origin | Access-Control-Allow-Origin: * |
Détail méconnu : Le header User-Agent est souvent falsifié par les bots et les scrapers pour éviter le blocage.
2.2 HTTPS (HTTP Sécurisé)
Définition : HTTPS = HTTP + SSL/TLS (chiffrement). Les données échangées sont cryptées.
Comment ça fonctionne ?
1. Client → Serveur : "Bonjour, je veux une connexion sécurisée"
2. Serveur → Client : "Voici mon certificat (public key)"
3. Client vérifie le certificat (autorité de certification)
4. Client → Serveur : "Voici une clé de session (chiffrée avec ta clé publique)"
5. Communication chiffrée via la clé de session
Pourquoi HTTPS est essentiel ?
| Risque | Sans HTTPS | Avec HTTPS |
|---|---|---|
| Écoute (Eavesdropping) | Tout le monde peut lire les données | Seul le client/serveur peut les déchiffrer |
| Man-in-the-Middle | Attaque possible | Certificat empêche l'usurpation |
| Modification | Les données peuvent être altérées en route | Intégrité préservée |
| Identité | Qui es-tu vraiment ? | Certificat vérifie l'identité du serveur |
Détail méconnu : Let's Encrypt (2014) a démocratisé le HTTPS en offrant des certificats gratuits, automatisés et valides pour 90 jours.
2.3 TCP/IP (Transmission Control Protocol / Internet Protocol)
La Suite Protocolaire
┌─────────────────────────────────┐
│ Application (HTTP, FTP) │ ← Couche 7
├─────────────────────────────────┤
│ Transport (TCP, UDP) │ ← Couche 4
├─────────────────────────────────┤
│ Internet (IP) │ ← Couche 3
├─────────────────────────────────┤
│ Link (Ethernet, WiFi) │ ← Couche 2
├─────────────────────────────────┤
│ Physical (Câble, Fibre) │ ← Couche 1
└─────────────────────────────────┘
TCP vs UDP
| Caractéristique | TCP | UDP |
|---|---|---|
| Fiabilité | ✅ Garantie (retransmission) | ❌ Non garanti |
| Ordre | ✅ Garanti | ❌ Non garanti |
| Connexion | ✅ Orienté connexion (3-way handshake) | ❌ Sans connexion |
| Vitesse | Plus lent (overhead) | Plus rapide |
| Utilisation | HTTP, HTTPS, FTP, SSH, SMTP | DNS, VoIP, Streaming, Jeux |
Le Handshake TCP (3-way handshake) :
Client → Serveur : SYN (Je veux me connecter)
Serveur → Client : SYN-ACK (OK, je te réponds)
Client → Serveur : ACK (Je confirme)
Détail méconnu : Une connexion TCP peut rester ouverte pendant des heures, même si aucun paquet n'est échangé. C'est comme un appel téléphonique en attente.
📡 3. DNS (DOMAIN NAME SYSTEM)
Définition : Le DNS est l'annuaire téléphonique d'Internet. Il convertit les noms de domaine (ex: google.com) en adresses IP (ex: 142.250.185.46).
Comment ça fonctionne ?
1. Tu tapes google.com dans ton navigateur
2. Ton navigateur demande à son résolveur DNS local
3. Le résolveur interroge les serveurs DNS récursifs
4. → Serveur racine (Root) : "Qui gère .com ?"
5. → Serveur TLD (.com) : "Qui gère google.com ?"
6. → Serveur Autoritaire : "Voici l'IP de google.com"
7. → Résolveur DNS : "Merci, voici l'IP pour google.com"
Hiérarchie du DNS
Root Servers (13 clusters mondiaux)
│
├── .com TLD (Verisign)
│ ├── google.com (Autoritaire)
│ │ ├── A record (IPv4)
│ │ ├── AAAA record (IPv6)
│ │ ├── MX record (Email)
│ │ ├── CNAME record (Alias)
│ │ └── TXT record (SPF, DKIM)
│ ├── facebook.com
│ └── ...
│
├── .org TLD
│ ├── mozilla.org
│ └── ...
│
├── .fr TLD (France)
│ ├── gouvernement.fr
│ └── ...
│
└── ...
Types d'Enregistrements DNS
| Type | Rôle | Exemple |
|---|---|---|
| A | IPv4 Address | google.com → 142.250.185.46 |
| AAAA | IPv6 Address | google.com → 2a00:1450:4007:80c::2004 |
| CNAME | Alias (Canonical Name) | www.google.com → google.com |
| MX | Mail Exchange | google.com → aspmx.l.google.com |
| TXT | Texte (SPF, DKIM) | "v=spf1 include:_spf.google.com ~all" |
| NS | Name Server | google.com → ns1.google.com |
Détail méconnu : Les Root Servers sont gérés par 13 organisations (dont Verisign, NASA, ICANN) et sont distribués dans le monde entier pour garantir la résilience.
⚡ 4. CDN (CONTENT DELIVERY NETWORK)
Définition : Un CDN est un réseau de serveurs distribués géographiquement pour accélérer la livraison de contenus web.
Problème Résolu
-
▹
Sans CDN : Tous les utilisateurs doivent se connecter au même serveur (ex: à Paris). Un utilisateur en Australie aura une latence de 200-300 ms.
-
▹
Avec CDN : Les contenus sont copiés (cachés) sur des serveurs près des utilisateurs. Un utilisateur en Australie sera servi par un serveur à Sydney (latence 10-30 ms).
Architecture d'un CDN
┌─────────────────┐
│ Serveur Source │
│ (Paris, FR) │
└────────┬────────┘
│ (Origin Push)
┌──────┼──────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ CDN #1 │ │ CDN #2 │ │ CDN #3 │
│ (Paris, FR) │ │ (New York) │ │ (Tokyo, JP) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
Utilisateurs Utilisateurs Utilisateurs
(Europe) (Amérique) (Asie)
Stratégies de Cache CDN
| Stratégie | Description | Use Case |
|---|---|---|
| Cache Static | Images, CSS, JS (longue durée) | Assets rarement modifiés |
| Cache Dynamic | Pages HTML (courte durée) | Actualités, blogs |
| Cache Invalidation | Purge à la demande | Mise à jour de contenu |
| Edge Computing | Code exécuté à la périphérie | Personnalisation, A/B testing |
Les CDN Majeurs
| CDN | Part de Marché | Caractéristiques |
|---|---|---|
| Cloudflare | 20%+ | Gratuit, DDoS protection, Workers |
| Akamai | 15%+ | Historique, entreprise, sécurisé |
| Fastly | 10%+ | Haute performance, purges instantanées |
| Amazon CloudFront | 10%+ | Intégration AWS |
Pourquoi utiliser un CDN ?
-
▹
Performance : Latence réduite jusqu'à 70%.
-
▹
Scalabilité : Absorbe les pics de trafic.
-
▹
Sécurité : DDoS protection, WAF (Web Application Firewall).
-
▹
Disponibilité : Redondance mondiale.
-
▹
Économie : Réduction des coûts de bande passante.
Détail méconnu : Le plus ancien CDN est Akamai (1998), créé pour distribuer les jeux vidéo et les applications de streaming.
🔄 5. LE CYCLE DE VIE D'UNE REQUÊTE WEB
Scénario Complet
1. Tu tapes "https://www.example.com" dans ton navigateur
↓
2. Résolution DNS (0.1-0.5s)
↓
3. Connexion TCP (3-way handshake) + TLS (0.1-0.3s)
↓
4. Requête HTTP (GET / HTTP/1.1)
↓
5. Serveur reçoit la requête (Nginx/Apache)
↓
6. Traitement application (Node.js, PHP, Python, Java)
↓
7. Accès à la base de données (MySQL, PostgreSQL, MongoDB)
↓
8. Génération de la réponse (HTML, JSON)
↓
9. Envoi de la réponse (HTTP 200 OK)
↓
10. Navigateur reçoit la réponse
↓
11. Parsing HTML (DOM Tree)
↓
12. Parsing CSS (CSSOM Tree)
↓
13. Exécution JavaScript (V8)
↓
14. Layout & Painting (Rendu visuel)
↓
15. Page affichée ! 🎉
Les Goulots d'Étranglement (Bottlenecks)
| Étape | Problème | Solution |
|---|---|---|
| DNS | Résolution lente | Cache DNS, DNS pré-résolu |
| TCP/TLS | Handshake coûteux | HTTP/3 (QUIC), Keep-Alive |
| Réseau | Latence, bande passante | CDN, Compression (gzip/brotli) |
| Serveur | Temps de réponse | Cache, Load Balancing, Microservices |
| Base de données | Requêtes lentes | Index, Cache (Redis), Sharding |
| Frontend | JavaScript lourd | Code Splitting, Lazy Loading, Tree Shaking |
| Rendu | Layout complexe | CSS optimisé, GPU acceleration |
🔧 6. LES TECHNOLOGIES & TOOLS
Outils de Test et Debugging
| Outil | Rôle | Exemple d'utilisation |
|---|---|---|
| Chrome DevTools | Debugging navigateur | Network, Performance, Console |
| Postman | Test d'API | Requêtes HTTP, collections |
| curl | CLI HTTP | curl -I https://example.com |
| Wireshark | Analyse réseau | Capturer les paquets TCP/IP |
| Pingdom | Monitoring performance | TTFB, temps de chargement |
Commandes Utiles
# Résolution DNS
nslookup google.com
dig google.com
# Traceroute (chemin réseau)
traceroute google.com
tracert google.com (Windows)
# Ping (latence)
ping google.com
# Tester une requête HTTP
curl -I https://example.com
curl -X POST https://api.example.com/users -H "Content-Type: application/json" -d '{"name":"Jean"}'
curl -v https://example.com
# Voir les en-têtes
curl -v https://example.com
📊 RÉSUMÉ (À RETENIR)
| Composant | Rôle | Exemple |
|---|---|---|
| Client | Demande des ressources | Navigateur, Application mobile |
| Serveur | Fournit des ressources | Nginx, Node.js, Django |
| HTTP/HTTPS | Protocole de communication | Transfert de pages, API |
| TCP/IP | Transport fiable des données | Paquets réseau |
| DNS | Résolution de noms | google.com → 142.250.185.46 |
| CDN | Distribution de contenu | Accélération mondiale |
| Cache | Stockage temporaire | Réduit la charge serveur |
🧠 CE QUE PEU DE GENS SAVENT
- ▹ HTTP/0.9 (1991) n'avait ni en-têtes, ni statut de réponse. La réponse était juste le contenu HTML brut.
- ▹ Internet Explorer a été le premier navigateur à supporter les en-têtes HTTP personnalisés, ce qui a permis de briser la compatibilité avec Netscape.
- ▹ Le CDN le plus utilisé est Cloudflare, qui protège environ 20% des sites web mondiaux (2026).
- ▹ Le protocole QUIC (base d'HTTP/3) a été développé par Google en 2012, inspiré par la latence des applications mobiles.
- ▹ Les Root DNS sont physiquement des serveurs dans 13 clusters mondiaux, mais certains sont gérés par des organisations militaires (ex: US Army).
- ▹ Le cache DNS est essentiel : sans cache, chaque requête prendrait 1-2 secondes en moyenne.
- ▹ Les cookies ont été inventés par Netscape en 1994 pour résoudre le problème de l'état (les serveurs HTTP étant stateless).
- ▹ Le navigateur peut faire jusqu'à 6 requêtes HTTP simultanées en HTTP/1.1, mais en HTTP/2, il peut en faire des centaines.
🔬 EXERCICES PRATIQUES
Exercice 1 : Observer une Requête
- Ouvre Chrome DevTools (F12)
- Va sur un site (ex: google.com)
- Regarde l'onglet Network
-
Observe :
- La méthode HTTP (GET)
- Les en-têtes (Host, User-Agent)
- Le statut (200 OK)
- Le temps de chargement
Questions :
- Combien de requêtes sont faites ?
- Quels sont les types de fichiers (HTML, CSS, JS, Images) ?
- Le TTFB (Time To First Byte) est-il élevé ?
Exercice 2 : DNS et Ping
# 1. Résoudre un nom de domaine
nslookup google.com
# 2. Voir le chemin réseau
traceroute google.com
# 3. Tester la latence
ping -c 5 google.com
# 4. Tester une requête HTTP
curl -I https://google.com
Questions :
- Quelle est l'adresse IP de google.com ?
- Combien de ms pour une réponse ?
- Quels en-têtes renvoie le serveur ?
Exercice 3 : Comprendre les Statuts HTTP
# 1. Requête réussie (200)
curl -I https://httpbin.org/status/200
# 2. Page non trouvée (404)
curl -I https://httpbin.org/status/404
# 3. Redirection (301)
curl -I https://httpbin.org/redirect/1
# 4. Erreur serveur (500)
curl -I https://httpbin.org/status/500
Questions :
- Quelle est la différence entre 301 et 302 ?
- Pourquoi 404 apparaît-il souvent ?
- Que signifie 500 ?
Exercice 4 : Analyse des En-têtes
# Afficher les en-têtes de requête
curl -v https://httpbin.org/headers
# Ajouter un header personnalisé
curl -H "X-Custom-Header: Hello" https://httpbin.org/headers
# Envoyer des données JSON
curl -X POST https://httpbin.org/post -H "Content-Type: application/json" -d '{"name":"Jean"}'
Questions :
- Quels sont les en-têtes par défaut ?
- Comment ajouter un en-tête personnalisé ?
- Comment envoyer des données en POST ?
Exercice 5 : Timing et Performance
# Tester le temps de réponse
time curl -s https://google.com > /dev/null
# Tester avec différents CDN
curl -s -w "DNS: %{time_namelookup}s, TCP: %{time_connect}s, Total: %{time_total}s\n" https://cloudflare.com
Questions :
- Combien de temps pour une requête ?
- Quelle est la latence réseau ?
- Le CDN améliore-t-il les performances ?
🎯 SYNTHÈSE FINALE
L'architecture du Web repose sur un modèle client-serveur où :
Le client demande des ressources (HTTP).
Le serveur les fournit après traitement.
DNS permet de trouver le serveur.
CDN accélère la distribution.
HTTP/HTTPS assure la communication.
TCP/IP garantit la livraison.
Cette architecture est simple, ouverte et scalable, ce qui a permis l'expansion du Web à l'échelle mondiale.
Prochaine étape
Phase 1.3 - Technologies du Web
Frontend, Backend, API, Sécurité, Performances...