Comment fonctionne vraiment internet
Rien ne voyage du site jusqu'à vous. La page est découpée en milliers de morceaux numérotés, chacun trouve seul son chemin à travers la planète, et votre machine les remet dans l'ordre.
Ce qui se passe entre le clic et la page
Niveau Débutant — langage simple, sans maths
Quand vous tapez une adresse et appuyez sur entrée, la première chose que votre ordinateur doit faire est d'admettre qu'il ne sait pas où se trouve cet endroit. labinatab.com est un nom, et les noms ne signifient rien pour le réseau. Il demande donc, et cette demande est déjà un petit voyage : de votre routeur à votre opérateur jusqu'à une machine qui tient la liste principale, jusqu'à ce qu'une réponse revienne, c'est-à-dire un nombre. Ce nombre est l'adresse, et ce n'est que maintenant qu'on peut envoyer quoi que ce soit.
Vient ensuite la partie surprenante. La page n'est pas envoyée comme une page. Elle est découpée en morceaux d'environ mille cinq cents caractères chacun, et chaque morceau est mis dans sa propre enveloppe avec la destination écrite dessus et un numéro d'ordre écrit dedans. Une photo peut faire quatre cents enveloppes. Chacune part de son côté, et personne ne les tient ensemble.
Elles voyagent en se faisant passer de main en main. Votre enveloppe arrive à une machine qui regarde l'adresse, décide lequel de ses câbles pointe à peu près dans la bonne direction, la jette dans ce câble, puis l'oublie complètement. Dix ou vingt machines font cela à tour de rôle, et aucune ne connaît le trajet entier. C'est la poste, pas un coup de téléphone : aucune ligne n'est jamais ouverte entre vous et le serveur.
Certaines enveloppes se perdent. Une machine est trop occupée, un câble a un raté, et le morceau n'arrive tout simplement jamais. Votre ordinateur remarque le trou dans les numéros d'ordre et redemande celui-là : voilà pourquoi une mauvaise connexion ne vous donne pas la moitié d'une photo, elle vous la donne lentement. Bougez les curseurs et regardez où le temps part réellement. Presque jamais là où les gens le croient.
Bon à savoir
- Chaque morceau de chaque page que vous ouvrez porte sur lui l'adresse complète de la destination, parce qu'aucune machine en chemin ne se souvient de celles qui sont passées avant.
- Environ 99 % du trafic internet intercontinental passe par des câbles sous-marins, pas par des satellites. Un câble de la grosseur d'un tuyau d'arrosage peut porter le trafic d'un pays.
- Dans la fibre, la lumière voyage à environ deux tiers de sa vitesse dans le vide, ce qui pose un plancher dur d'environ 60 ms sur un aller-retour entre l'Europe et la côte ouest américaine. Aucune somme d'argent ne le raccourcit.
DNS, paquets, poignées de main, et pourquoi la latence bat le débit
Niveau Élève — les équations essentielles
Le chargement d'une page est fait de quatre choses distinctes en séquence, et comprendre laquelle domine constitue l'essentiel du savoir pratique. D'abord le DNS : le nom est résolu en adresse IP en parcourant une hiérarchie - les serveurs racine, puis le domaine de premier niveau, puis le serveur faisant autorité pour le domaine - sauf si la réponse est déjà en cache, auquel cas cela ne coûte presque rien. Puis la poignée de main TCP, trois messages qui établissent la connexion et coûtent un aller-retour et demi avant qu'un seul octet de contenu ne bouge. Puis TLS, qui coûte d'autres allers-retours. Ce n'est qu'alors que les données circulent.
Les données sont découpées en paquets dimensionnés par le MTU, typiquement 1500 octets, dont environ 1460 de charge utile. Une page de 240 ko fait donc environ 170 paquets. Ils sont envoyés par fenêtre - plusieurs en vol à la fois, car attendre un accusé de réception après chacun serait catastrophiquement lent - et la fenêtre grandit à mesure que la connexion prouve sa fiabilité. C'est pourquoi la première seconde d'une connexion est plus lente que le reste.
Le routage se fait saut par saut et sans état. Chaque routeur lit la destination, consulte une table d'acheminement et envoie le paquet par une interface. Des paquets d'une même page peuvent prendre des routes différentes et arriver dans le désordre ; TCP les réordonne grâce aux numéros de séquence et redemande ce qui manque. Un paquet perdu coûte au moins un aller-retour complet pour être remarqué et remplacé, ce qui explique pourquoi la perte fait bien plus mal que son pourcentage ne le suggère.
D'où la règle qui surprend : pour les pages web ordinaires, la latence compte plus que le débit. Passer de 10 à 100 Mbit/s ne change presque pas le temps de chargement, parce que la page n'a jamais été assez grosse pour saturer le tuyau. Diviser par deux le temps d'aller-retour le change énormément, parce que le chargement est une chaîne d'allers-retours. C'est exactement la raison d'être des réseaux de distribution de contenu : non pas envoyer plus vite, mais se tenir plus près.
Formules clés
| Délai de propagation | \(t_{\text{prop}} = \dfrac{2d}{c_{\text{fibre}}}\) | c ≈ 200 000 km/s dans le verre |
|---|---|---|
| Paquets nécessaires | \(N = \lceil S / \text{MTU} \rceil\) | S = taille de la page |
| Temps au premier octet | \(t_{\text{TTFB}} \approx t_{\text{DNS}} + 1.5\,\text{RTT} + t_{\text{TLS}}\) | |
| Temps de transfert | \(t \approx \dfrac{S}{B} + \text{RTT}\log_2\!\left(\dfrac{S}{\text{IW}}\right)\) | slow start, IW = fenêtre initiale |
Bon à savoir
- Ouvrir une connexion HTTPS coûte environ 3 allers-retours avant que le moindre contenu n'arrive. À 100 ms de RTT, cela fait 300 ms passées à se mettre d'accord sur le fait de parler, ce qui sur une page courte peut dépasser le temps passé à l'envoyer.
- 1 % de perte de paquets peut couper le débit de TCP de plus de moitié, parce que l'algorithme de contrôle de congestion traite la perte comme un signal de ralentir, et pas seulement comme un morceau à renvoyer.
- Un traceroute vers un serveur à 1000 km montre typiquement de 8 à 15 sauts. Aucun de ces routeurs ne connaît le chemin complet : chacun sait seulement quel voisin est plus proche du but.
Le modèle en couches, le contrôle de congestion et pourquoi internet ne s'effondre pas
Niveau Expert — profondeur mathématique complète
01Les couches, et ce que chacune refuse de savoir
L'astuce centrale de l'architecture est l'ignorance délibérée. IP, la couche réseau, ne promet que le meilleur effort : elle essaiera de livrer un datagramme et ne vous dira rien si elle échoue. Elle ne garantit ni ordre, ni livraison, ni timing. Tout ce que les gens attendent d'un réseau - fiabilité, ordonnancement, contrôle de flux, sécurité - est construit au-dessus, dans TCP et TLS, aux extrémités. C'est le principe de bout en bout, et c'est pourquoi le réseau a pu passer à l'échelle : les routeurs sont restés simples et sans état pendant que la complexité intéressante vivait dans les machines des bords, où elle pouvait être mise à jour sans toucher au centre.
02Le contrôle de congestion comme algorithme distribué
Aucune autorité centrale n'attribue le débit. À la place, chaque émetteur TCP exécute une boucle de contrôle qui augmente son rythme jusqu'à voir de la perte, puis le divise par deux : augmentation additive, diminution multiplicative. Des millions d'émetteurs indépendants suivant cette règle convergent vers un partage à peu près équitable de chaque lien commun, ce qui est un résultat distribué vraiment remarquable. Les variantes modernes le compliquent utilement : CUBIC récupère plus vite sur les chemins à grand produit débit-délai, et BBR abandonne totalement la perte comme signal, modélisant directement le débit et le temps d'aller-retour du goulot, car à l'ère des grands tampons la perte arrive bien après que la file a déjà ruiné la latence.
03Bufferbloat et la tyrannie de la file
La mémoire bon marché a produit une pathologie. Les routeurs aux tampons surdimensionnés absorbent les rafales au lieu de les jeter, si bien que le contrôle de congestion fondé sur la perte reçoit son signal en retard et que la file reste en permanence pleine. Le débit paraît excellent tandis que la latence interactive s'effondre : c'est le symptôme classique d'un envoi vidéo qui détruit un appel vocal sur le même lien. Le remède est la gestion active de file, CoDel et FQ-CoDel, qui jettent ou marquent les paquets selon le temps qu'ils ont passé en file plutôt que selon leur nombre.
04BGP, et le fait que le routage est une affaire de politique
Entre réseaux, les chemins sont choisis par le Border Gateway Protocol, qui n'est pas un algorithme de plus court chemin mais un système pour annoncer une joignabilité et appliquer une politique commerciale. Un système autonome préfère les routes passant par ses clients plutôt que par ses pairs ou ses fournisseurs, pour des raisons d'argent plus que de distance. Les conséquences sont structurelles : internet n'a pas de carte, les changements de route se propagent comme une rumeur et peuvent mettre des minutes à se stabiliser, et une annonce erronée peut tirer le trafic d'un pays à travers le mauvais continent, ce qui est déjà arrivé plus d'une fois.
05Ce que HTTP/3 a changé
Faire passer des flux fiables sur une seule connexion TCP créait le blocage en tête de file : un paquet perdu bloque tous les flux partageant cette connexion. QUIC déplace la machinerie de fiabilité et de chiffrement dans l'espace utilisateur au-dessus d'UDP, offrant des flux indépendants, une poignée de main qui fusionne l'établissement du transport et celui de la cryptographie en un seul aller-retour, et des identifiants de connexion qui survivent à un changement d'adresse IP - un téléphone passant du wi-fi au réseau cellulaire garde ainsi sa connexion au lieu de la reconstruire.
Formules clés
| AIMD | \(w \leftarrow w + \tfrac{1}{w}\ \ \text{par ACK};\quad w \leftarrow \tfrac{w}{2}\ \ \text{à la perte}\) | |
|---|---|---|
| Débit TCP | \(B \approx \dfrac{\text{MSS}}{\text{RTT}\sqrt{p}}\) | loi en racine ; p = taux de perte |
| Produit débit-délai | \(\text{BDP} = B \times \text{RTT}\) | octets en vol pour remplir le tuyau |
| Délai de file | \(t_q = \dfrac{Q}{B}\) | pourquoi un grand tampon est un tampon lent |
Bon à savoir
- AIMD - augmentation additive, diminution multiplicative - est démontrablement équitable et stable pour des flux en compétition sur un même goulot. C'est l'un des rares cas où une simple règle locale produit de façon fiable un bon résultat global.
- Le bufferbloat peut ajouter des secondes de latence à un lien dont le débit se mesure parfaitement. C'est pourquoi un test de vitesse peut afficher 200 Mbit/s pendant qu'un appel vidéo est inutilisable.
- BGP n'a aucune vérification intégrée de qui possède quel bloc d'adresses. La validation de l'origine des routes se déploie, mais pendant l'essentiel de l'histoire d'internet n'importe quel réseau pouvait annoncer n'importe quel préfixe et être cru.