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 - 2000+ Lignes
🎯 1. LE MODÈLE CLIENT-SERVEUR
La Métaphore Fondamentale
Pour comprendre le modèle client-serveur, imagine un restaurant gastronomique :
- ▹
Le client = Toi (tu commandes un plat). Tu es actif, tu décides ce que tu veux.
- ▹
Le serveur = Le cuisinier (il prépare le plat). Il est passif, il attend les commandes.
- ▹
La commande = La requête HTTP (tu demandes une page web). C'est un message structuré.
- ▹
Le plat = La réponse HTTP (la page web servie). C'est le résultat de la requête.
- ▹
La carte = L'URL (tu choisis ce que tu veux). C'est l'adresse de la ressource.
- ▹
Le ticket de caisse = Les en-têtes HTTP (métadonnées de la requête/réponse).
Définition Technique Approfondie
Le modèle Client-Serveur est un paradigme d'architecture réseau où :
-
▹
Le client est un acteur actif qui initie la communication. Il envoie des requêtes et attend des réponses.
Exemples : Navigateur web, application mobile, application desktop, IoT device, script Python, etc. -
▹
Le serveur est un acteur passif qui écoute les requêtes entrantes. Il les traite et renvoie des réponses.
Exemples : Serveur web (Nginx), serveur d'application (Node.js), serveur de base de données (PostgreSQL). -
▹
La communication se fait via des protocoles standardisés (HTTP, HTTPS, FTP, WebSocket, etc.).
Le protocole définit la syntaxe, la sémantique et la synchronisation des messages. -
▹
Le modèle est asymétrique : le client connaît l'adresse du serveur, mais le serveur ne connaît pas nécessairement l'adresse du client.
C'est pourquoi le client doit toujours initier la communication.
Schéma Complet du Modèle Client-Serveur
┌────────────────────────────────────────────────────────────────────────────────────┐
│ 🌍 CLIENT (Navigateur) │
│ │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ Interface utilisateur (UI) ←→ Moteur de rendu ←→ JavaScript Engine (V8) │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ HTTP Client (XMLHttpRequest / Fetch API) │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────┬─────────────────────────────────────────────────┘
│
│ Requête HTTP (GET /index.html)
│ Méthode: GET
│ Headers: Host, User-Agent, Accept
▼
┌────────────────────────────────────────────────────────────────────────────────────┐
│ 🖥️ SERVEUR WEB │
│ │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ Reverse Proxy (Nginx) → Routing → Application Logic (Node.js/PHP/Python) │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ Database (MySQL/PostgreSQL/MongoDB) → Cache (Redis/Memcached) │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────┬─────────────────────────────────────────────────┘
│
│ Réponse HTTP (200 OK + HTML)
│ Status: 200 OK
│ Headers: Content-Type, Cache-Control
▼
┌────────────────────────────────────────────────────────────────────────────────────┐
│ 🌍 CLIENT (Navigateur) │
│ (Affiche la page web avec HTML/CSS/JS) │
└────────────────────────────────────────────────────────────────────────────────────┘
Les Types de Clients - Analyse Détaillée
| Type de Client | Exemples | Caractéristiques Techniques | Protocoles Supportés | Cas d'Usage |
|---|---|---|---|---|
| Navigateur Web | Chrome, Firefox, Safari, Edge | Moteur de rendu (Blink/Gecko/WebKit), JavaScript Engine (V8/SpiderMonkey/JSC), support HTML5/CSS3, DevTools intégrés | HTTP/1.1, HTTP/2, HTTP/3, WebSocket, WebRTC | Navigation web, applications SPA/PWA, streaming vidéo |
| Application Mobile | iOS (Swift), Android (Kotlin), React Native, Flutter | Accès aux capteurs, notifications push, stockage local (SQLite, Realm), interface native | HTTP/HTTPS, WebSocket, gRPC (via HTTP/2) | Applications bancaires, réseaux sociaux, jeux, e-commerce |
| API Client | Postman, Insomnia, curl, SDKs (Python Requests, Axios) | Programmatique, support des méthodes HTTP, gestion des cookies, authentification (OAuth, JWT) | HTTP/1.1, HTTP/2, GraphQL (via HTTP) | Tests d'API, intégrations CI/CD, scripts automatisés |
| IoT Device | Capteurs, montres connectées, ampoules connectées, thermostats | Ressources limitées (CPU/RAM), batterie faible, protocoles légers (MQTT, CoAP) | HTTP léger, MQTT, CoAP, WebSocket | Domotique, santé connectée, industrie 4.0, agriculture intelligente |
| Web Scraper | Python (Requests, Scrapy), Puppeteer, Selenium | Tête de ligne, gestion des cookies, JavaScript rendering (headless browser), rotation d'IP | HTTP/HTTPS, WebSocket (pour les sites dynamiques) | Extraction de données, monitoring de prix, analyse concurrentielle |
| Terminal/CLI | curl, wget, httpie, telnet, nc (netcat) | Léger, scriptable, utilisable dans des pipelines Unix | HTTP, HTTPS, FTP, SMTP, SSH | Administration système, débogage réseau, scripting |
Les Types de Serveurs - Analyse Détaillée
| Type de Serveur | Exemples | Rôle Détaillé | Ports Typiques | Cas d'Usage |
|---|---|---|---|---|
| Serveur Web | Nginx, Apache, Caddy, IIS | Servir des fichiers statiques (HTML, CSS, JS, images), reverse proxy, load balancing, gestion des connexions SSL/TLS | 80 (HTTP), 443 (HTTPS) | Hébergement de sites web, déploiement d'applications SPA |
| Serveur d'Application | Node.js (Express), Django (Python), Spring Boot (Java), Ruby on Rails | Logique métier, traitement des requêtes, calculs, accès aux bases de données, génération de réponses dynamiques (HTML/JSON/XML) | 3000, 5000, 8080 (varie) | APIs REST, applications web dynamiques, microservices |
| Serveur de Base de Données | PostgreSQL, MySQL, MongoDB, Redis, Cassandra | Stockage persistant des données, requêtes SQL/NoSQL, transactions ACID (pour les bases relationnelles), scalabilité horizontale | 5432 (PostgreSQL), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis) | Stockage des données utilisateurs, gestion de contenu, cache (Redis) |
| Serveur Proxy | HAProxy, Squid, nginx (en mode proxy), Envoy | Cache des réponses, équilibrage de charge (load balancing), terminaison SSL, filtrage des requêtes, protection contre les attaques DDoS | 3128 (Squid), 8080 (HAProxy) | Reverse proxy pour les applications, cache CDN, proxy d'entreprise |
| Serveur de Fichiers | FTP/SFTP, Amazon S3, NFS, SMB | Stockage et distribution de fichiers volumineux, gestion des permissions, versioning (pour S3) | 21 (FTP), 22 (SFTP), 443 (S3 via HTTPS) | Hébergement de médias, partage de fichiers, sauvegardes |
| Serveur DNS | Cloudflare DNS, Google Public DNS, AWS Route 53, BIND | Résolution de noms de domaine en adresses IP, cache DNS, équilibrage de charge (round-robin), protection contre les attaques | 53 (UDP/TCP) | Résolution DNS, gestion des domaines, routage global |
| Serveur de Messagerie | Postfix, Sendmail, Microsoft Exchange | Envoi et réception d'emails, gestion des queues, spam filtering, authentification (SPF, DKIM, DMARC) | 25 (SMTP), 587 (SMTP TLS), 993 (IMAP SSL), 995 (POP3 SSL) | Gestion des emails, newsletters, notifications |
Le Cycle de Vie d'une Requête - Explication Détaillée
Étape 1 : Résolution DNS (0.1 - 0.5 secondes)
Le navigateur demande l'adresse IP du domaine au résolveur DNS. Il vérifie d'abord le cache local, puis interroge les serveurs DNS récursifs.
Étape 2 : Connexion TCP (0.1 - 0.3 secondes)
Le client établit une connexion TCP avec le serveur via un 3-way handshake (SYN → SYN-ACK → ACK). Si HTTPS, une négociation TLS est ajoutée.
Étape 3 : Envoi de la Requête HTTP
Le client envoie la requête HTTP (méthode, URL, en-têtes, corps si présent).
Étape 4 : Traitement Serveur
Le serveur reçoit la requête, la route vers le bon handler, exécute la logique métier, accède à la base de données si nécessaire et génère la réponse.
Étape 5 : Envoi de la Réponse
Le serveur renvoie la réponse HTTP (statut, en-têtes, corps).
Étape 6 : Traitement Client
Le navigateur reçoit la réponse, parse le HTML, construit le DOM, parse le CSS, exécute le JavaScript et rend la page à l'écran.
Détail technique : Le TTFB (Time To First Byte) mesure le temps entre l'envoi de la requête et la réception du premier octet de la réponse. Il est critique pour la performance perçue par l'utilisateur. Un TTFB idéal est inférieur à 200ms.
🌐 2. LES PROTOCOLES : LE CŒUR DU WEB
2.1 HTTP (HyperText Transfer Protocol)
Définition complète : HTTP est un protocole de communication stateless (sans état) de la couche application. Il permet l'échange de données entre un client et un serveur. Il est orienté texte (lisible par un humain) et fonctionne sur le modèle requête-réponse.
Historique des Versions - Analyse Approfondie
| Version | Année | Caractéristiques | Problèmes Résolus | Limites |
|---|---|---|---|---|
| HTTP/0.9 | 1991 | Une seule méthode (GET), pas d'en-têtes, réponse uniquement HTML brut, pas de codes de statut | Premier protocole pour le web | Extrêmement limité, pas de métadonnées |
| HTTP/1.0 | 1996 | Ajout des en-têtes, méthodes POST et HEAD, codes de statut (200, 404), Content-Type | Communication enrichie, support des métadonnées | Connexion fermée après chaque requête (lent) |
| HTTP/1.1 | 1997 | Persistent connections (keep-alive), pipelining, chunked transfer encoding, nouvelles méthodes (PUT, DELETE, OPTIONS), en-tête Host | Réduction de la latence, permet l'hébergement virtuel | Head-of-line blocking, en-têtes non compressés |
| HTTP/2 | 2015 | Multiplexage (plusieurs requêtes simultanées), compression des en-têtes (HPACK), server push, binaire (non textuel), priorisation des flux | Performance massive, réduction de la latence | Toujours sur TCP, vulnérable au head-of-line blocking au niveau TCP |
| HTTP/3 | 2022 | Basé sur QUIC (UDP), pas de TCP, réduit la latence de connexion, amélioration de la mobilité, congestion control moderne | Élimine le head-of-line blocking, connexion plus rapide | Adoption encore partielle, complexité accrue |
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. La transition vers HTTP/2 a pris près de 10 ans.
Méthodes HTTP - Guide Complet des Verbes
| Méthode | Rôle Détaillé | Idempotent ? | Sûr ? | Corps de Requête | Exemple d'Utilisation |
|---|---|---|---|---|---|
| GET | Récupère une ressource. Ne doit pas modifier l'état du serveur. Peut être mis en cache. | ✅ Oui | ✅ Oui | ❌ Non | GET /users/123 |
| POST | Crée une nouvelle ressource. Le serveur assigne un ID unique. Non-idempotent : deux requêtes identiques créent deux ressources. | ❌ Non | ❌ Non | ✅ Oui | POST /users (body: {"name":"Jean"}) |
| PUT | Remplace intégralement une ressource existante. Idempotent : plusieurs requêtes identiques produisent le même résultat. | ✅ Oui | ❌ Non | ✅ Oui | PUT /users/123 (body: {"name":"Jean"}) |
| PATCH | Met à jour partiellement une ressource. Non-idempotent car l'effet dépend de la ressource existante. | ❌ Non | ❌ Non | ✅ Oui | PATCH /users/123 (body: {"name":"Jean"}) |
| DELETE | Supprime une ressource. Idempotent : la première requête supprime, les suivantes ne font rien (404). | ✅ Oui | ❌ Non | ❌ Non | DELETE /users/123 |
| HEAD | Récupère les en-têtes d'une ressource sans le corps. Utile pour vérifier l'existence ou la taille. | ✅ Oui | ✅ Oui | ❌ Non | HEAD /users/123 |
| OPTIONS | Décrit les méthodes HTTP autorisées sur une ressource. Utilisé pour le CORS (preflight). | ✅ Oui | ✅ Oui | ❌ Non | OPTIONS /users |
| TRACE | Echo la requête reçue. Utilisé pour le débogage (souvent désactivé pour sécurité). | ✅ Oui | ✅ Oui | ❌ Non | TRACE / |
| CONNECT | Établit un tunnel TCP vers le serveur. Utilisé pour les proxies HTTPS (SSL tunneling). | ❌ Non | ❌ Non | ❌ Non | CONNECT example.com:443 |
Définition :
Idempotent = Une opération qui peut être répétée plusieurs fois sans changer
le résultat au-delà de la première application.
Safe = Une opération qui ne modifie pas l'état du serveur (lecture
seule).
Stateless = Le serveur ne garde pas de mémoire des requêtes précédentes.
Chaque requête est indépendante.
Codes de Statut HTTP - Détail des 5 Familles et Tous les Codes Courants
1xx - Informational
| Code | Nom | Explication Détaillée |
|---|---|---|
| 100 | Continue | Le client peut continuer à envoyer le corps de la requête. Utilisé pour les requêtes volumineuses. |
| 101 | Switching Protocols | Le serveur accepte le changement de protocole (ex: Upgrade vers WebSocket). |
| 102 | Processing | Le serveur traite la requête mais n'a pas encore de réponse (WebDAV). |
| 103 | Early Hints | Indique au client de précharger des ressources avant la réponse finale. |
2xx - Success
| Code | Nom | Explication Détaillée |
|---|---|---|
| 200 | OK | La requête a réussi. Le corps contient la ressource demandée (GET) ou le résultat de l'action (POST/PUT). |
| 201 | Created | La ressource a été créée avec succès. L'en-tête Location contient l'URL de la nouvelle ressource. |
| 202 | Accepted | La requête a été acceptée pour traitement mais n'est pas encore terminée (traitement asynchrone). |
| 203 | Non-Authoritative Information | Les métadonnées proviennent d'une source tierce (proxy). |
| 204 | No Content | La requête a réussi mais le corps est vide. Utilisé pour les DELETE ou les mises à jour sans retour. |
| 205 | Reset Content | Le client doit réinitialiser la vue du document. |
| 206 | Partial Content | Renvoie une partie de la ressource (requête avec Range). Utilisé pour le streaming et le téléchargement résumable. |
3xx - Redirection
| Code | Nom | Explication Détaillée |
|---|---|---|
| 300 | Multiple Choices | Plusieurs réponses possibles. Le client doit choisir. |
| 301 | Moved Permanently | La ressource a définitivement changé d'URL. Les clients doivent mettre à jour leurs liens. Le cache est mis à jour. |
| 302 | Found | Redirection temporaire. L'URL originale doit être conservée pour les futures requêtes. |
| 303 | See Other | La réponse se trouve à une autre URL. Utilisé après un POST pour rediriger vers une page de confirmation (PRG pattern). |
| 304 | Not Modified | La ressource n'a pas changé depuis la dernière requête. Utilise le cache (If-Modified-Since). |
| 307 | Temporary Redirect | Redirection temporaire avec conservation de la méthode HTTP (contrairement à 302). |
| 308 | Permanent Redirect | Redirection permanente avec conservation de la méthode HTTP. |
4xx - Client Errors
| Code | Nom | Explication Détaillée |
|---|---|---|
| 400 | Bad Request | La requête est mal formée (syntaxe invalide, paramètres manquants, corps mal encodé). |
| 401 | Unauthorized | Authentification requise. Le client doit fournir des identifiants valides (Basic Auth, Bearer Token). |
| 403 | Forbidden | Le client est authentifié mais n'a pas les permissions nécessaires pour accéder à la ressource. |
| 404 | Not Found | La ressource demandée n'existe pas sur le serveur. C'est l'erreur la plus courante. |
| 405 | Method Not Allowed | La méthode HTTP utilisée n'est pas supportée par la ressource (ex: POST sur une ressource en lecture seule). |
| 406 | Not Acceptable | Le serveur ne peut pas fournir une réponse dans le format Accept demandé par le client. |
| 407 | Proxy Authentication Required | Authentification requise par le proxy. |
| 408 | Request Timeout | Le serveur a abandonné l'attente de la requête complète. |
| 409 | Conflict | La requête est en conflit avec l'état actuel du serveur (ex: tentative de création d'une ressource qui existe déjà). |
| 410 | Gone | La ressource a été définitivement supprimée et ne sera plus disponible. Similaire à 404 mais permanent. |
| 411 | Length Required | L'en-tête Content-Length est requis mais absent. |
| 412 | Precondition Failed | Une précondition (If-Match, If-None-Match) n'est pas satisfaite. |
| 413 | Payload Too Large | Le corps de la requête est trop volumineux. |
| 414 | URI Too Long | L'URL est trop longue pour être traitée par le serveur. |
| 415 | Unsupported Media Type | Le format du contenu (Content-Type) n'est pas supporté. |
| 416 | Range Not Satisfiable | La plage demandée (Range) est invalide ou non satisfiable. |
| 417 | Expectation Failed | L'en-tête Expect (ex: 100-Continue) ne peut pas être satisfait. |
| 418 | I'm a teapot | Easter egg HTTP (RFC 2324). Le serveur est une théière et ne peut pas préparer de café. |
| 422 | Unprocessable Entity | Le corps de la requête est syntaxiquement correct mais sémantiquement invalide (ex: validation métier). |
| 429 | Too Many Requests | Le client a envoyé trop de requêtes dans un laps de temps (rate limiting). |
| 431 | Request Header Fields Too Large | Les en-têtes de la requête sont trop volumineux. |
5xx - Server Errors
| Code | Nom | Explication Détaillée |
|---|---|---|
| 500 | Internal Server Error | Erreur générique du serveur. Le serveur a rencontré une condition inattendue. |
| 501 | Not Implemented | La méthode HTTP n'est pas supportée par le serveur. |
| 502 | Bad Gateway | Le serveur (qui agit comme proxy) a reçu une réponse invalide du serveur en amont. |
| 503 | Service Unavailable | Le serveur est temporairement indisponible (maintenance, surcharge). Le client doit réessayer plus tard. |
| 504 | Gateway Timeout | Le serveur (proxy) n'a pas reçu de réponse du serveur en amont dans le délai imparti. |
| 505 | HTTP Version Not Supported | La version HTTP utilisée n'est pas supportée par le serveur. |
| 507 | Insufficient Storage | Le serveur n'a pas assez d'espace de stockage pour traiter la requête. |
| 508 | Loop Detected | Le serveur a détecté une boucle infinie lors du traitement de la requête. |
| 511 | Network Authentication Required | Le client doit s'authentifier sur le réseau (ex: portail captif Wi-Fi). |
En-têtes HTTP - Guide Complet
Les en-têtes HTTP sont des métadonnées qui accompagnent les requêtes et les réponses. Ils fournissent des informations sur la requête, la réponse, ou le contenu.
En-têtes de Requête (Request Headers)
Exemple de Requête HTTP avec En-têtes :
GET /users/123 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: application/json, text/plain, */*
Accept-Language: fr-FR,fr;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate, br
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json
Content-Length: 123
Connection: keep-alive
Cookie: session_id=abc123; theme=dark
Cache-Control: no-cache
En-têtes de Réponse (Response Headers)
Exemple de Réponse HTTP avec En-têtes :
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 1234
Content-Encoding: gzip
Cache-Control: max-age=3600, public
Expires: Wed, 21 Oct 2026 07:28:00 GMT
Last-Modified: Tue, 20 Oct 2026 07:28:00 GMT
ETag: "abc123def456"
Set-Cookie: session_id=xyz789; HttpOnly; Secure; SameSite=Strict
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Server: nginx/1.18.0
Tableau des En-têtes Courants
| Header | Type | Rôle Détaillé | Exemple |
|---|---|---|---|
| Host | Request | Nom de domaine et port du serveur cible. Obligatoire en HTTP/1.1 pour l'hébergement virtuel. | Host: api.example.com |
| User-Agent | Request | Identifie le client (navigateur, OS, version). Utilisé pour l'adaptation du contenu. | Mozilla/5.0 (Chrome 120) |
| Accept | Request | Formats de réponse acceptés par le client (MIME types). | application/json |
| Accept-Encoding | Request | Algorithmes de compression supportés (gzip, deflate, br). | gzip, deflate, br |
| Accept-Language | Request | Langues préférées du client avec priorités (q=0.9). | fr-FR,fr;q=0.9,en;q=0.8 |
| Authorization | Request | Identifiants d'authentification (Basic, Bearer, Digest). | Bearer <token> |
| Content-Type | Request/Response | Format MIME du corps de la requête/réponse. | application/json |
| Content-Length | Request/Response | Taille en octets du corps. Obligatoire pour les requêtes POST/PUT. | 1234 |
| Cookie | Request | Cookies stockés par le client pour la session. | session_id=abc123 |
| Cache-Control | Request/Response | Stratégie de cache (max-age, no-cache, public, private). | max-age=3600 |
| Set-Cookie | Response | Définit un cookie pour le client (nom, valeur, domaine, path, expiration). | session_id=xyz789; HttpOnly |
| CORS | Response | Contrôle l'accès cross-origin (Access-Control-Allow-Origin). | Access-Control-Allow-Origin: * |
| ETag | Response | Identifiant unique de la version de la ressource. Utilisé pour le cache. | "abc123def456" |
| Location | Response | URL de redirection (utilisé avec 301, 302, 303). | https://example.com/new-resource |
| Server | Response | Nom et version du serveur logiciel. | nginx/1.18.0 |
| Referer | Request | URL de la page précédente. Utilisé pour l'analyse du trafic. | https://google.com |
Détail méconnu : L'en-tête User-Agent est souvent falsifié par les bots et les scrapers pour éviter le blocage. C'est pourquoi les sites modernes utilisent des techniques de détection plus avancées.
2.2 HTTPS (HTTP Sécurisé)
Définition : HTTPS (HyperText Transfer Protocol Secure) est la version sécurisée de HTTP. Il utilise SSL/TLS (Secure Sockets Layer / Transport Layer Security) pour chiffrer les données échangées entre le client et le serveur.
Comment fonctionne TLS/SSL ?
Le Handshake TLS (en détail) :
1. Client Hello : Le client envoie une liste de suites cryptographiques supportées, un nombre aléatoire et l'extension SNI (Server Name Indication).
2. Server Hello : Le serveur choisit une suite cryptographique, envoie son nombre aléatoire et son certificat numérique.
3. Vérification du Certificat : Le client vérifie que le certificat est signé par une Autorité de Certification (CA) de confiance.
4. Échange de Clés : Le client génère une clé de session (clé symétrique), la chiffre avec la clé publique du serveur (trouvée dans le certificat) et l'envoie.
5. Session Établie : Le serveur déchiffre la clé de session avec sa clé privée. Désormais, la communication est chiffrée avec la clé de session.
6. Le client et le serveur peuvent maintenant échanger des données HTTP chiffrées.
Pourquoi HTTPS est-il essentiel ?
| Risque | Sans HTTPS | Avec HTTPS | Technique de Protection |
|---|---|---|---|
| Écoute (Eavesdropping) | Tout le monde peut lire les données en clair | Seul le client et le serveur peuvent déchiffrer | Chiffrement asymétrique + symétrique |
| Man-in-the-Middle | Attaque possible (usurpation d'identité) | Le certificat empêche l'usurpation | Certificat numérique signé par CA |
| Modification des Données | Les données peuvent être altérées en route | Intégrité préservée (MAC) | Message Authentication Code (MAC) |
| Identité du Serveur | "Qui es-tu vraiment ?" | Le certificat vérifie l'identité du serveur | Certificat X.509 + Chaîne de confiance |
| SEO | Pénalité par Google | Avantage SEO | HTTPS est un signal de ranking |
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. Avant cela, les certificats coûtaient cher et étaient complexes à installer.
2.3 TCP/IP (Transmission Control Protocol / Internet Protocol)
Définition : TCP/IP est la suite protocolaire qui permet la communication sur Internet. Elle définit comment les données sont encapsulées, adressées, transmises et routées sur le réseau.
La Suite Protocolaire TCP/IP
┌────────────────────────────────────────────────────────┐
│ Couche Application (HTTP, HTTPS, FTP, SMTP, DNS) │ ← Couche 7
├────────────────────────────────────────────────────────┤
│ Couche Transport (TCP, UDP) │ ← Couche 4
├────────────────────────────────────────────────────────┤
│ Couche Internet (IP, ICMP, ARP) │ ← Couche 3
├────────────────────────────────────────────────────────┤
│ Couche Accès Réseau (Ethernet, WiFi, PPP) │ ← Couche 2
├────────────────────────────────────────────────────────┤
│ Couche Physique (Câble, Fibre, Radio) │ ← Couche 1
└────────────────────────────────────────────────────────┘
TCP vs UDP - Comparaison Détaillée
| Caractéristique | TCP | UDP | Explication |
|---|---|---|---|
| Fiabilité | ✅ Garantie | ❌ Non garantie | TCP retransmet les paquets perdus. UDP les ignore. |
| Ordre des Paquets | ✅ Garanti | ❌ Non garanti | TCP réassemble dans l'ordre. UDP peut les livrer dans le désordre. |
| Connexion | ✅ Orienté connexion | ❌ Sans connexion | TCP établit une connexion (handshake). UDP envoie sans prévenir. |
| Vitesse | Plus lent | Plus rapide | TCP a plus d'overhead (en-têtes, retransmissions). |
| Contrôle de Flux | ✅ Oui | ❌ Non | TCP ajuste le débit selon la capacité du réseau. |
| En-tête | 20-60 octets | 8 octets | TCP a un en-tête plus lourd. |
| Utilisations | HTTP, HTTPS, FTP, SSH, SMTP | DNS, VoIP, Streaming, Jeux vidéo | TCP pour la fiabilité, UDP pour la vitesse. |
Le Handshake TCP (3-way handshake) - Détail
Étape 1 : SYN (Synchronize)
Le client envoie un paquet TCP avec le flag SYN activé et un numéro de séquence initial (ISN) aléatoire. (Ex: Seq = 1000)
Étape 2 : SYN-ACK (Synchronize-Acknowledge)
Le serveur répond avec SYN-ACK : il accuse réception du SYN (ACK = ISN + 1) et envoie son propre ISN. (Ex: Seq = 5000, ACK = 1001)
Étape 3 : ACK (Acknowledge)
Le client envoie ACK pour confirmer la réception du SYN-ACK. (Ex: ACK = 5001)
Connexion établie !
Détail méconnu : Une connexion TCP peut rester ouverte pendant des heures, même si aucun paquet n'est échangé (Keep-Alive). C'est comme un appel téléphonique en attente.
📡 3. DNS (DOMAIN NAME SYSTEM)
Définition : Le DNS (Domain Name System) 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). Sans DNS, nous devrions mémoriser des adresses IP pour chaque site web.
Comment fonctionne le DNS ?
Scénario complet de résolution DNS :
1. Tu tapes "https://www.example.com" dans ton navigateur.
2. Le navigateur vérifie son cache DNS local (s'il a déjà résolu ce domaine).
3. Si pas dans le cache, il interroge le résolveur DNS du système (ex: 8.8.8.8 pour Google DNS).
4. Le résolveur commence par interroger un serveur racine (Root) : "Où puis-je trouver les serveurs pour .com ?"
5. Le Root répond : "Voici les adresses des serveurs TLD (Top-Level Domain) pour .com".
6. Le résolveur interroge un serveur TLD .com : "Qui gère example.com ?"
7. Le TLD répond : "Le serveur autoritaire pour example.com est ns1.example.com".
8. Le résolveur interroge le serveur autoritaire : "Quelle est l'IP de www.example.com ?"
9. Le serveur autoritaire répond : "A record = 93.184.216.34"
10. Le résolveur retourne l'IP au navigateur. La résolution est mise en cache pour les prochaines requêtes.
Hiérarchie du DNS
Root Servers (13 clusters mondiaux)
│
├── .com TLD (Verisign) - Gère tous les .com
│ ├── google.com (Serveur Autoritaire)
│ │ ├── A record (IPv4) : 142.250.185.46
│ │ ├── AAAA record (IPv6) : 2a00:1450:4007:80c::2004
│ │ ├── MX record (Mail Exchange) : aspmx.l.google.com
│ │ ├── CNAME record (Alias) : www.google.com → google.com
│ │ └── TXT record (SPF/DKIM) : "v=spf1 include:_spf.google.com ~all"
│ ├── facebook.com
│ └── amazon.com
│
├── .org TLD (Public Interest Registry)
│ ├── mozilla.org
│ └── wikipedia.org
│
├── .fr TLD (AFNIC - France)
│ ├── gouvernement.fr
│ └── lemonde.fr
│
├── .net TLD (Verisign)
│ └── ...
│
└── ... (plus de 1500 TLDs)
Types d'Enregistrements DNS - Guide Complet
| Type | Rôle Détaillé | Exemple | Cas d'Usage |
|---|---|---|---|
| A | Adresse IPv4 (32 bits) du domaine. | google.com → 142.250.185.46 | Liaison domaine → IP v4 |
| AAAA | Adresse IPv6 (128 bits) du domaine. | google.com → 2a00:1450:4007:80c::2004 | Liaison domaine → IP v6 |
| CNAME | Alias (Canonical Name). Redirige un nom vers un autre. | www.google.com → google.com | www, blog, shop → domaine principal |
| MX | Mail Exchange. Spécifie les serveurs de messagerie. | google.com → aspmx.l.google.com (prio 10) | Configuration des emails |
| TXT | Texte arbitraire. Utilisé pour SPF, DKIM, DMARC, vérifications. | "v=spf1 include:_spf.google.com ~all" | Sécurité email, vérification de domaine |
| NS | Name Server. Spécifie les serveurs DNS autoritaires. | google.com → ns1.google.com | Délégation DNS |
| SRV | Service Record. Spécifie un serveur pour un service (port, protocole). | _sip._tcp.example.com → 5060 sipserver.example.com | VoIP, SIP, LDAP, etc. |
| PTR | Pointer Record. Résolution inverse (IP → domaine). | 46.185.250.142.in-addr.arpa → google.com | Reverse DNS pour les serveurs |
| SOA | Start of Authority. Métadonnées de la zone DNS. | ns1.google.com. hostmaster.google.com. 123456 7200 3600 1209600 1800 | Gestion de zone, TTL |
| CAA | Certification Authority Authorization. Quelles CAs peuvent émettre des certificats. | 0 issue "letsencrypt.org" | Sécurité des certificats SSL |
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. Ils utilisent Anycast : une même adresse IP peut être routée vers plusieurs serveurs physiques.
⚡ 4. CDN (CONTENT DELIVERY NETWORK)
Définition : Un CDN (Content Delivery Network) est un réseau de serveurs distribués géographiquement qui collaborent pour accélérer la livraison de contenus web (HTML, CSS, JS, images, vidéos).
Problème Résolu par le CDN
-
▹
Sans CDN (Serveur Centralisé) : Tous les utilisateurs se connectent au même serveur (ex: à Paris).
- Un utilisateur à Paris : 10-30 ms de latence.
- Un utilisateur à Sydney : 200-300 ms de latence (distance physique).
- Le serveur supporte toute la charge (pics de trafic). -
▹
Avec CDN (Distribution) : Les contenus sont copiés (mise en cache) sur des serveurs proches des utilisateurs.
- Un utilisateur à Paris : 10-30 ms (serveur local).
- Un utilisateur à Sydney : 10-30 ms (serveur à Sydney).
- La charge est répartie sur des centaines de serveurs.
Architecture d'un CDN
┌────────────────────────────────────┐
│ Origin Server (Serveur Source) │
│ (Paris, France) │
└────────────┬───────────────────────┘
│ (Content Push / Pull)
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Edge Server #1 │ │ Edge Server #2 │ │ Edge Server #3 │
│ (Paris, FR) │ │ (New York, US) │ │ (Tokyo, JP) │
│ Cache: 100GB │ │ Cache: 100GB │ │ Cache: 100GB │
└────────┬───────┘ └────────┬───────┘ └────────┬───────┘
│ │ │
▼ ▼ ▼
Utilisateurs Utilisateurs Utilisateurs
(Europe) (Amérique) (Asie)
Latence: 10-30ms Latence: 10-30ms Latence: 10-30ms
Stratégies de Cache CDN
| Stratégie | Description | TTL (Time To Live) | Use Case |
|---|---|---|---|
| Cache Static | Fichiers rarement modifiés (images, CSS, JS, polices). | 1 mois à 1 an | Assets de l'application |
| Cache Dynamic | Pages HTML générées dynamiquement (ex: blog, actualités). | 5 minutes à 1 heure | Sites d'information |
| Cache Invalidation | Purge forcée du cache via API (purge all ou par URL). | N/A | Mise à jour de contenu critique |
| Edge Computing | Code exécuté à la périphérie (Cloudflare Workers, Lambda@Edge). | N/A | Personnalisation, A/B testing, géolocalisation |
| Cache Warming | Pré-chargement du cache avant un pic de trafic. | N/A | Événements, lancements de produits |
Les CDN Majeurs - Comparaison
| CDN | Part de Marché | Caractéristiques | Prix | Points Forts |
|---|---|---|---|---|
| Cloudflare | 20%+ | Gratuit (plan free), DDoS protection, Workers (serverless), WAF | Gratuit → Entreprise (payant) | Facilité d'utilisation, écosystème complet |
| Akamai | 15%+ | Historique (1998), réseau mondial, sécurisé, entreprise | Élevé (entreprises) | Performance, sécurité, fiabilité |
| Fastly | 10%+ | Haute performance, purges instantanées (instant purges), VCL | Pay-as-you-go | Flexibilité, performance |
| Amazon CloudFront | 10%+ | Intégration AWS (S3, EC2, Lambda@Edge), pay-as-you-go | Pay-as-you-go | Intégration AWS, écosystème |
| Microsoft Azure CDN | 5%+ | Intégration Azure, Verizon et Akamai backends | Pay-as-you-go | Intégration Azure |
Pourquoi utiliser un CDN ?
- ▹
Performance : Latence réduite jusqu'à 70%. Temps de chargement plus rapide.
- ▹
Scalabilité : Absorbe les pics de trafic (flash sales, événements).
- ▹
Sécurité : Protection DDoS (volumétrique et applicative), WAF (Web Application Firewall).
- ▹
Disponibilité : Redondance mondiale. Si un serveur tombe en panne, un autre prend le relais.
- ▹
Économie : Réduction des coûts de bande passante (le CDN absorbe le trafic).
- ▹
SEO : Google favorise les sites rapides (Core Web Vitals).
Détail méconnu : Le plus ancien CDN est Akamai (1998), créé pour distribuer les jeux vidéo et les applications de streaming. Il possède plus de 300 000 serveurs dans 130 pays.
🔄 5. LE CYCLE DE VIE D'UNE REQUÊTE WEB
Scénario Complet - Étape par Étape
Étape 1 : Saisie de l'URL
Tu tapes "https://www.example.com" dans la barre d'adresse de ton navigateur.
Étape 2 : Résolution DNS (0.1 - 0.5s)
Le navigateur résout le nom de domaine en adresse IP via le DNS (cache local → résolveur → Root → TLD → Autoritaire).
Étape 3 : Connexion TCP + TLS (0.1 - 0.3s)
Le navigateur établit une connexion TCP avec le serveur (3-way handshake) et négocie TLS pour HTTPS.
Étape 4 : Requête HTTP
Le navigateur envoie une requête HTTP : GET / HTTP/1.1 avec les en-têtes (Host, User-Agent, Accept, etc.).
Étape 5 : Réception par le Serveur
Le serveur web (Nginx/Apache) reçoit la requête, la route vers le bon handler selon l'URL et la méthode HTTP.
Étape 6 : Traitement Application
L'application (Node.js, Django, Spring Boot) exécute la logique métier : validation, calculs, accès à la base de données.
Étape 7 : Accès Base de Données
L'application interroge la base de données (SQL ou NoSQL) pour récupérer ou modifier des données.
Étape 8 : Génération de la Réponse
L'application construit la réponse (HTML, JSON, XML) avec les données récupérées.
Étape 9 : Envoi de la Réponse HTTP
Le serveur renvoie la réponse HTTP : HTTP/1.1 200 OK avec les en-têtes (Content-Type, Cache-Control) et le corps.
Étape 10 : Réception par le Navigateur
Le navigateur reçoit la réponse et vérifie le statut (200, 404, etc.) et les en-têtes.
Étape 11 : Parsing HTML
Le navigateur parse le HTML pour construire le DOM (Document Object Model).
Étape 12 : Parsing CSS
Le navigateur parse le CSS pour construire le CSSOM (CSS Object Model).
Étape 13 : Exécution JavaScript
Le navigateur exécute le JavaScript (ex: V8 pour Chrome) pour ajouter de l'interactivité.
Étape 14 : Layout & Painting
Le navigateur calcule les dimensions (Layout) et dessine la page (Painting) à l'écran.
Étape 15 : Affichage ! 🎉
Les Goulots d'Étranglement (Bottlenecks) - Analyse
| Étape | Problème | Cause | Solution |
|---|---|---|---|
| DNS | Résolution lente | Réseau lent, DNS non optimisé | Cache DNS, DNS pré-résolu, DNS-over-HTTPS |
| TCP/TLS | Handshake coûteux | 3-way handshake + TLS négociation | HTTP/3 (QUIC), Keep-Alive, TLS session resumption |
| Réseau | Latence, bande passante | Distance physique, congestion réseau | CDN, Compression (gzip/brotli), optimisation d'images |
| Serveur | Temps de réponse | Code lent, overload, I/O disque | Cache, Load Balancing, Microservices, optimisation du code |
| Base de données | Requêtes lentes | Index manquants, requêtes complexes | Index, Cache (Redis), Sharding, requêtes optimisées |
| Frontend | JavaScript lourd | Bundle trop volumineux, code inefficace | Code Splitting, Lazy Loading, Tree Shaking, minification |
| Rendu | Layout complexe | Réflows/Répaints fréquents, CSS lourd | CSS optimisé, GPU acceleration, réduction des sélecteurs |
🔧 6. LES TECHNOLOGIES & TOOLS
Outils de Test et Debugging
| Outil | Rôle | Fonctionnalités Clés | Exemple d'utilisation |
|---|---|---|---|
| Chrome DevTools | Debugging navigateur | Network tab, Performance tab, Console, Elements, Sources (debugging JS) | Analyser les requêtes HTTP, déboguer JS, mesurer les performances |
| Postman | Test d'API | Collections, environnements, tests automatisés, génération de code | Tester une API REST, envoyer des requêtes HTTP, valider les réponses |
| curl | CLI HTTP | Toutes les méthodes HTTP, en-têtes, cookies, SSL, pipelines | curl -I https://example.com |
| Wireshark | Analyse réseau | Capture de paquets, filtres, analyse TCP/UDP/HTTP, décodage SSL | Capturer et analyser les paquets TCP/IP |
| Pingdom | Monitoring performance | TTFB, temps de chargement, analyse des ressources, uptime monitoring | Mesurer la performance d'un site depuis plusieurs localisations |
| WebPageTest | Test de performance | First Contentful Paint, Largest Contentful Paint, analyse détaillée | Analyser la performance d'un site dans des conditions variées |
| Insomnia | Test d'API | Alternative à Postman, interface épurée, support GraphQL | Tester des API REST et GraphQL |
Commandes Utiles (curl, dig, nslookup, traceroute, ping)
# Résolution DNS
nslookup google.com
# Affiche l'adresse IP, le serveur DNS utilisé, et les enregistrements.
dig google.com
# Version plus détaillée de nslookup (plus d'infos sur les enregistrements).
# Traceroute (chemin réseau)
traceroute google.com
# Affiche tous les routeurs traversés entre le client et le serveur.
# Ping (latence)
ping -c 5 google.com
# Envoie 5 paquets ICMP pour mesurer le temps de réponse.
# Tester une requête HTTP avec curl
curl -I https://example.com
# Récupère uniquement les en-têtes de la réponse.
curl -X POST https://api.example.com/users -H "Content-Type: application/json" -d '{"name":"Jean"}'
# Envoie une requête POST avec des données JSON.
curl -v https://example.com
# Mode verbose : affiche tous les échanges (requête, en-têtes, réponse).
curl -s -w "DNS: %{time_namelookup}s, TCP: %{time_connect}s, SSL: %{time_appconnect}s, Total: %{time_total}s\n" https://example.com
# Mesure les temps de chaque étape de la requête.
# Voir les connexions réseau actives
netstat -ant | grep ESTABLISHED
# Affiche toutes les connexions TCP établies.
# Tester un port ouvert
nc -zv example.com 443
# Vérifie si le port 443 (HTTPS) est ouvert sur le serveur.
Détail méconnu : curl est utilisé par 90% des développeurs pour tester des API. Il est disponible sur presque tous les systèmes Linux/macOS et peut être installé sur Windows.
📊 RÉSUMÉ (À RETENIR)
| Composant | Rôle | Exemple | Port |
|---|---|---|---|
| Client | Demande des ressources | Navigateur, Application mobile | Dynamique |
| Serveur Web | Fournit des fichiers statiques | Nginx, Apache | 80, 443 |
| Serveur App | Exécute la logique métier | Node.js, Django | 3000, 5000, 8080 |
| HTTP | Protocole de communication | Requête/Réponse | 80 |
| HTTPS | HTTP sécurisé (chiffré) | SSL/TLS | 443 |
| TCP | Transport fiable des données | Paquets réseau | Dynamique |
| DNS | Résolution de noms de domaine | google.com → IP | 53 |
| CDN | Distribution de contenu | Cloudflare, Akamai | 80, 443 |
| Cache | Stockage temporaire | Redis, Memcached | 6379, 11211 |
🧠 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.
- ▹ Le code 418 (I'm a teapot) est un easter egg d'HTTP, créé comme blague pour April Fools' Day 1998.
- ▹ Le header User-Agent est souvent falsifié par les bots pour éviter le blocage. Certains bots utilisent des User-Agents de navigateurs réels.
- ▹ Let's Encrypt (2014) a démocratisé le HTTPS en offrant des certificats gratuits et automatisés.
🔬 EXERCICES PRATIQUES
Exercice 1 : Observer une Requête HTTP
- 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, Accept)
- Le statut (200 OK, 301, 404)
- Le temps de chargement (TTFB, Total)
Questions :
- Combien de requêtes sont faites pour charger la page ?
- Quels sont les types de fichiers (HTML, CSS, JS, Images, Fonts) ?
- Le TTFB (Time To First Byte) est-il inférieur à 200ms ?
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 (ping) ?
- Quels en-têtes renvoie le serveur google.com ?
Exercice 3 : Tester 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 permanente (301)
curl -I https://httpbin.org/redirect/1
# 4. Erreur serveur (500)
curl -I https://httpbin.org/status/500
# 5. Accès interdit (403)
curl -I https://httpbin.org/status/403
Questions :
- Quelle est la différence entre 301 et 302 ?
- Pourquoi 404 apparaît-il souvent sur les sites ?
- Que signifie 500 ?
- Que signifie 403 ?
Exercice 4 : Envoyer des Requêtes avec curl
# 1. Requête GET avec en-têtes
curl -H "X-Custom-Header: Hello" https://httpbin.org/headers
# 2. Requête POST avec données JSON
curl -X POST https://httpbin.org/post -H "Content-Type: application/json" -d '{"name":"Jean", "age":30}'
# 3. Requête PUT
curl -X PUT https://httpbin.org/put -d '{"name":"Jean"}'
# 4. Requête DELETE
curl -X DELETE https://httpbin.org/delete
Questions :
- Quel est l'en-tête par défaut envoyé par curl ?
- Comment ajouter un en-tête personnalisé ?
- Comment envoyer des données en POST ?
Exercice 5 : Mesurer les Performances
# Tester le temps de réponse complet
time curl -s https://google.com > /dev/null
# Mesurer les temps détaillés
curl -s -w "DNS: %{time_namelookup}s, TCP: %{time_connect}s, SSL: %{time_appconnect}s, Total: %{time_total}s\n" https://cloudflare.com
# Comparer avec et sans CDN
curl -s -w "Total: %{time_total}s\n" https://example.com
Questions :
- Combien de temps pour une requête vers google.com ?
- Quelle est la latence DNS ?
- Le temps SSL est-il significatif ?
🎯 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 des données.
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, Frameworks...