Entre le branchement de ton PC et l'affichage de https://www.example.org, cinq protocoles se succèdent, toujours dans le même ordre : DHCP lui donne une adresse IP, DNS trouve celle du serveur, TCP ouvre une connexion, TLS la chiffre, puis HTTP demande la page. TCP appartient à la couche transport du modèle TCP/IP (couche 4 d'OSI), les quatre autres à la couche application. Quand un site refuse de s'ouvrir, l'un de ces maillons a lâché : suis la chaîne dans l'ordre et tu trouveras lequel.
Le trajet d'une page, protocole par protocole
OSI découpe la communication en sept couches (physique, liaison de données, réseau, transport, session, présentation, application), TCP/IP en quatre (accès réseau, internet, transport, application). Le tableau suit le haut de la pile, dans l'ordre des échanges.
| Protocole | Transporté par | Port du serveur | Ce qu'il apporte |
|---|---|---|---|
| DHCP | UDP | 67 (client : 68) | adresse, masque, passerelle, serveur DNS |
| DNS | UDP, ou TCP | 53 | l'adresse IP du serveur web |
| TCP | IP | 443 ici | une connexion fiable |
| TLS | TCP | 443 | chiffrement, identité du serveur |
| HTTP | TLS sur TCP, ou TCP | 443 en https, 80 en http | la page |
Session et présentation, couches 5 et 6 d'OSI, n'existent pas à part dans TCP/IP : les protocoles d'application s'en chargent. TLS, glissé entre TCP et HTTP, ne tombe dans aucune couche OSI unique ; TCP/IP le range dans l'application.
Piège classique : HTTPS n'est pas un autre protocole que HTTP : c'est le même, mêmes requêtes et mêmes codes, transporté dans TLS. Seul le port par défaut change, 443 au lieu de 80.
DHCP : obtenir une adresse
Au branchement, ton PC n'a pas d'adresse IP et ne connaît aucun serveur. Il parle donc à tout le réseau local à la fois, par diffusion (broadcast) : destination 255.255.255.255, source 0.0.0.0. DHCP (Dynamic Host Configuration Protocol) organise l'échange en quatre messages portés par UDP ; le serveur écoute sur le port 67, le client sur le port 68 (RFC 2131).
Étape 1 : DISCOVER. Le PC cherche un serveur, en diffusion.
Étape 2 : OFFER. Chaque serveur qui l'entend peut proposer une adresse.
Étape 3 : REQUEST. Le PC retient une offre et l'annonce en diffusion : les autres serveurs savent ainsi que la leur est déclinée.
Étape 4 : ACK. Le serveur choisi confirme : l'adresse est attribuée.
En plus de l'adresse, le serveur fournit le masque de sous-réseau, la passerelle (le routeur de sortie du réseau) et les serveurs DNS. Le tout pour une durée limitée, le bail, que le PC fait prolonger avant son terme.
Remarque : si aucun serveur ne répond, beaucoup de systèmes, Windows compris, se donnent une adresse en 169.254.x.x, dite « lien local » : aucun routeur ne transmet un paquet qui la porte. Tu restes alors coincé dans ton réseau local.
DNS : trouver le serveur
Ton PC connaît maintenant un serveur DNS, celui que DHCP lui a donné. Il lui demande l'adresse IP de www.example.org, en UDP vers le port 53 : une question, une réponse, aucune connexion à ouvrir. Si la réponse est trop longue pour un datagramme UDP, elle revient tronquée avec le drapeau TC levé, et la question repart en TCP, sur le même port (RFC 1035).
Ce serveur, qu'on appelle résolveur, est récursif : il fait tout le travail à ta place. S'il n'a rien en mémoire, il descend l'arbre des noms : un serveur racine l'envoie vers les serveurs de .org, qui l'envoient vers ceux de example.org, qui donnent l'adresse.
La réponse est un enregistrement : type A pour une adresse IPv4, AAAA pour une adresse IPv6. Chacun porte un TTL, une durée en secondes pendant laquelle le résolveur peut le garder en cache et le resservir sans redemander.
Piège classique : le TTL d'un enregistrement DNS n'a rien à voir avec celui d'un paquet IP. Le premier est une durée de cache, en secondes. Le second est un compteur que chaque routeur baisse d'au moins 1.
TCP et TLS : ouvrir un canal chiffré
Avec l'adresse du serveur, le navigateur ouvre une connexion TCP vers son port 443 : trois segments (SYN, SYN-ACK, ACK), soit un aller-retour avant les premières données. TCP livre tous les octets, dans l'ordre, mais ne cache rien : sans chiffrement, chaque équipement du trajet peut lire ce qui passe.
TLS (Transport Layer Security) prend le relais. Le client annonce les méthodes de chiffrement qu'il connaît ; le serveur en choisit une et envoie son certificat, qui prouve qu'il est bien www.example.org. Tous deux en tirent des clés de session, inconnues de tout observateur. En TLS 1.3, cette poignée de main coûte un seul aller-retour.
Une fois le canal établi, un observateur sur le trajet voit encore les adresses IP, les ports et souvent le nom du site. Il ne voit plus ni la page demandée ni son contenu.
HTTP : demander la page
Dans ce canal part enfin la requête HTTP. En HTTP/1.1, c'est du texte : une ligne avec la méthode, le chemin et la version, puis des en-têtes, un par ligne. L'en-tête Host, obligatoire, dit quel site tu veux : un même serveur en héberge souvent plusieurs.
GET /cours/reseaux.html HTTP/1.1
Host: www.example.orgGET demande une ressource ; POST envoie des données, celles d'un formulaire par exemple. Le serveur répond par une ligne d'état portant un code à trois chiffres, puis ses en-têtes et la page.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8Le premier chiffre donne la famille du code (RFC 9110) :
| Famille | Sens | Exemples |
|---|---|---|
| 1xx | information : la suite arrive | 100 Continue |
| 2xx | succès | 200 OK |
| 3xx | redirection, souvent vers une autre adresse | 301 Moved Permanently |
| 4xx | erreur du client : requête mal formée ou impossible à satisfaire | 404 Not Found |
| 5xx | erreur du serveur, sur une requête valable | 500 Internal Server Error, 503 Service Unavailable |
Exercices corrigés
Exercice 1 : Données fictives. À 10 h 00, un résolveur met en cache l'enregistrement A de www.example.org, dont le TTL vaut 3 600. On lui redemande ce nom à 10 h 40, puis à 11 h 05. Dans chaque cas, répond-il depuis son cache ? À 10 h 40, combien de temps la réponse reste-t-elle valable ?
Correction :
Le TTL se compte en secondes : $3\,600$ s font 60 min, donc la réponse reste en cache jusqu'à 11 h 00.
À 10 h 40, il s'est écoulé $40 \times 60 = 2\,400$ s : le résolveur répond depuis son cache, et la réponse vaut encore $3\,600 - 2\,400 = 1\,200$ s, soit 20 min.
À 11 h 05, le TTL est écoulé : le résolveur interroge de nouveau les serveurs du domaine.
Exercice 2 : Données fictives. Le cache DNS de ton PC est vide, mais le résolveur connaît déjà l'adresse du site. La question DNS coûte un aller-retour de 10 ms vers le résolveur. L'ouverture TCP, la poignée de main TLS 1.3 et le couple requête-réponse HTTP coûtent chacun un aller-retour de 40 ms vers le serveur web. Temps de calcul négligés. Au bout de combien de temps arrive le premier octet de la page en https ? Et en http ?
Correction :
En https : DNS, puis TCP, TLS et HTTP, soit $10 + 3 \times 40 = 130$ ms.
En http, la poignée de main TLS disparaît : $10 + 2 \times 40 = 90$ ms.
TLS coûte donc ici 40 ms, près d'un tiers du total : $\dfrac{40}{130} \approx 0{,}31$.
Exercice 3 : Trois étudiants n'arrivent pas à ouvrir le même site. Chez Léa, ipconfig, sous Windows, affiche l'adresse 169.254.37.12. Chez Hugo, un ping vers l'adresse IP du serveur répond, mais le navigateur ne trouve pas le nom du site. Chez Inès, le navigateur affiche « 404 Not Found ». Pour chacun, quel protocole est en cause, et le réseau est-il en panne ?
Correction :
Léa : DHCP, et son réseau local est en cause. Son adresse en 169.254 dit qu'aucun serveur n'a répondu. Elle vérifie câble, Wi-Fi et serveur DHCP, puis relance la demande avec ipconfig /renew.
Hugo : DNS ; le réseau, lui, marche, puisque le ping passe. C'est la traduction du nom qui échoue : il vérifie le serveur DNS reçu par DHCP, avec ipconfig /all.
Inès : aucun protocole en panne, et le réseau marche. Recevoir une réponse HTTP prouve que toute la chaîne, de DHCP à TLS, a fonctionné. Un code 4xx désigne une erreur du client : le serveur ne trouve rien à ce chemin, l'adresse saisie est à vérifier. Accuser le réseau, c'est l'erreur visée.
À retenir
À retenir :
- Du branchement à la page en https : DHCP, DNS, TCP, TLS, puis HTTP.
- DHCP : UDP, ports 67 et 68, quatre messages ; une adresse en 169.254 signe son échec.
- DNS : UDP port 53, TCP si la réponse est tronquée ; son TTL est une durée de cache, en secondes.
- HTTPS, c'est HTTP dans TLS, sur le port 443 au lieu de 80.
- 4xx : le client s'est trompé ; 5xx : le serveur a échoué ; dans les deux cas, le réseau a marché.
Sources
- RFC 2131, « Dynamic Host Configuration Protocol », mars 1997 : texte sur rfc-editor.org.
- RFC 1035, « Domain Names, Implementation and Specification », novembre 1987 : texte sur rfc-editor.org.
- RFC 9110, « HTTP Semantics », juin 2022 : texte sur rfc-editor.org.