Ce qui se passe quand tu ouvres une page web

Avec un aller-retour de 50 ms, une page HTTPS demande au moins 4 allers-retours, soit 200 ms, avant que le premier octet de HTML arrive. HTTP/3 en supprime un.

Sept heures quarante du matin. Dans un train bondé, une élève touche, en données mobiles, un lien vers le menu de la cantine, et un instant plus tard le menu du jour s'affiche. (C'est une scène inventée.) Pendant ce court instant, le téléphone a fait tout ce que décrivent les cinq unités précédentes : une résolution DNS, une connexion TCP, une session chiffrée et une requête HTTP à laquelle on a répondu avec un code d'état. Suis le téléphone pas à pas et compte les attentes.

D'abord, le téléphone lit le lien

Disons que le lien est https://www.example.com/index.html. MDN découpe une URL en parties. https est le schéma : utiliser HTTP sur une connexion TLS chiffrée, sur le port 443 sauf si un autre port est écrit. www.example.com est l'hôte, le nom que le DNS va transformer en adresse. /index.html est le chemin, la ressource demandée sur ce serveur. Une URL peut aussi porter une requête après un point d'interrogation et un fragment après un croisillon. Le fragment désigne un endroit dans la page et n'est jamais envoyé au serveur.

Quatre allers-retours avant le premier octet

Le temps qu'il faut à un message pour atteindre le serveur et à la réponse pour revenir s'appelle le temps d'aller-retour (RTT). Compte les allers-retours et tu verras d'où vient l'attente. Un : si le nom n'est pas en cache, la résolution DNS coûte environ un aller-retour jusqu'au résolveur. Deux : la poignée de main TCP, SYN à l'aller et SYN-ACK au retour. Trois : TLS 1.3 (RFC 8446) s'accorde sur les clés en un aller-retour, et le dernier message de poignée de main du client peut voyager avec la requête HTTP. Quatre : la requête part et la réponse revient. Avec un RTT de 50 ms, cela fait 200 ms avant le premier octet du menu, même si le serveur répond instantanément.

HTTP/3 (RFC 9114) fonctionne sur QUIC (RFC 9000) au lieu de TCP. QUIC repose sur UDP et établit en même temps la connexion et les clés TLS, si bien que l'aller-retour TCP séparé disparaît : DNS, un aller-retour de poignée de main, puis la requête, trois en tout. Le HTTP simple sur le port 80 se passe de TLS et en demande aussi trois, mais alors n'importe qui sur le chemin, par exemple la personne qui gère le Wi-Fi d'un café, peut lire ou modifier la page. Le cadenas dans la barre d'adresse signifie que la connexion à ce domaine est chiffrée. Il ne signifie pas que le site lui-même est honnête.

Le menu arrive précédé d'un nombre

La réponse commence par un code d'état à trois chiffres. La RFC 9110 regroupe les codes selon leur premier chiffre : 1xx information, 2xx succès, 3xx redirection, 4xx erreur du client et 5xx erreur du serveur. Ceux que tu croiseras le plus sont 200 OK, 301 Moved Permanently (la page a une nouvelle adresse), 404 Not Found et 500 Internal Server Error. Si l'école avait déplacé la page du menu, le téléphone recevrait d'abord un 301, puis redemanderait à la nouvelle adresse. Un 404 signifie que le serveur a répondu et n'avait rien à ce chemin : le réseau, lui, fonctionnait.

Une page, beaucoup de fichiers

Le HTML est rarement la page entière. Imaginons qu'il mentionne une feuille de style, un script et cinq images. Si le téléphone ouvrait une nouvelle connexion pour chacun, chaque fichier repaierait les allers-retours TCP et TLS. À la place, le navigateur garde la connexion ouverte et y envoie les requêtes suivantes, et avec HTTP/2 et HTTP/3 plusieurs requêtes voyagent en même temps sur une seule connexion. Les navigateurs ont aussi leur propre cache. Quand une réponse indique qu'elle peut être réutilisée pendant un certain temps, la visite suivante charge ce fichier depuis le stockage sans envoyer de requête. Ce n'est qu'une fois les fichiers arrivés que le navigateur met en page et dessine ce que tu vois. Voilà pourquoi la page du menu que l'élève ouvre chaque matin s'affiche plus vite qu'un site ouvert pour la première fois, même sur le même réseau.