🇫🇷 L'odyssée d'une requête : Lorsque vous tapez une URL

Ce geste, vous le faites cent fois par jour. Une adresse, la touche Entrée, une page. Rien de plus banal — et pourtant, sous ce clic se cache l’une des plus belles cathédrales que l’ingénierie ait jamais construites : des dizaines de machines, des milliers de kilomètres de fibre optique, une cinquantaine d’années de protocoles empilés les uns sur les autres, et du silicium cadencé à plusieurs milliards de battements par seconde.

Cet article raconte ce voyage dans l’ordre chronologique, de la pression physique sur la touche jusqu’aux pixels allumés à l’écran. À chaque étape, on descendra ou remontera dans la pile : tantôt dans le matériel (clavier, processeur, mémoire, carte réseau), tantôt dans le logiciel (système d’exploitation, navigateur), tantôt dans ce qui les relie — DNS, TCP, TLS, HTTP, serveurs web. Les durées indiquées en tête de chapitre sont des ordres de grandeur réalistes pour une connexion fibre en France vers un site correctement hébergé ; elles servent de fil conducteur, pas de chronomètre.

Le voyage se lit en onze étapes : le prologue (la machine était déjà prête), la frappe, l’analyse de l’URL, le DNS, TCP, TLS, HTTP, le voyage des paquets, le serveur, le rendu et l’épilogue.

00 — Prologue : la machine était prête

t − quelques minutes · matériel, firmware, système

Avant même que l’histoire commence, un travail colossal a déjà eu lieu : celui de l’allumage. Quand vous avez pressé le bouton d’alimentation, le processeur s’est réveillé dans un état minimal et est allé exécuter le firmware de la carte mère — le BIOS historique, remplacé depuis quinze ans par son successeur UEFI, mais tout le monde continue de dire « BIOS ». Ce petit programme gravé dans une mémoire flash a une mission : transformer un tas de composants inertes en une machine capable de charger un système d’exploitation.

Il commence par le POST (Power-On Self-Test) : recenser et tester le matériel. L’étape la plus délicate est l’initialisation de la RAM — le fameux memory training, où le contrôleur mémoire calibre les tensions et les délais de chaque barrette à la nanoseconde près. Puis l’UEFI énumère les périphériques (SSD NVMe, carte réseau, GPU), applique éventuellement Secure Boot pour vérifier les signatures cryptographiques de ce qu’il s’apprête à lancer, trouve le chargeur d’amorçage (Windows Boot Manager, GRUB, systemd-boot…) sur la partition EFI, et lui passe la main.

Le chargeur charge le noyau du système d’exploitation en mémoire. Le noyau prend alors le contrôle total : il active la mémoire virtuelle (chaque processus croira disposer de la machine entière), configure le contrôleur d’interruptions, monte les systèmes de fichiers, charge les pilotes — dont celui de la carte réseau — puis démarre l’espace utilisateur : services, session graphique, et, quelque part dans tout ça, votre navigateur.

Un navigateur moderne n’est d’ailleurs pas un programme mais une petite constellation : un processus principal qui orchestre, un processus réseau, un processus GPU, et un processus de rendu par site, enfermé dans un bac à sable. Nous les recroiserons. Au moment où notre histoire commence, tout ce monde tourne déjà, paisiblement, en attendant un événement. Le voici.

01 — La frappe : une touche, une interruption

t = 0 · matériel, système

Votre doigt enfonce la touche Entrée. Sous le capuchon, deux contacts se touchent et ferment un circuit. Le clavier n’est pas passif : il embarque son propre microcontrôleur, qui scanne la matrice de touches plusieurs centaines de fois par seconde, élimine les rebonds électriques du contact (debouncing — sans quoi une pression produirait dix caractères), et encode l’événement au format HID, le standard des périphériques d’entrée. Pour Entrée, c’est le code 0x28.

Sur un clavier USB, ce rapport est déposé dans une file que le contrôleur hôte de la machine vient relever jusqu’à mille fois par seconde. À la réception, le contrôleur lève une interruption : un signal électrique qui force le processeur à suspendre ce qu’il faisait, sauvegarder son état, et sauter dans une routine du noyau. C’est le mécanisme fondamental par lequel le matériel se fait entendre du logiciel — nous le reverrons à l’identique avec la carte réseau.

Le pilote clavier du noyau traduit le code HID en code de touche générique, l’estampille et le publie comme événement d’entrée. Le serveur d’affichage (WindowServer sous macOS, Wayland ou X11 sous Linux, DWM sous Windows) détermine quelle fenêtre a le focus — le navigateur — et lui transmet l’événement. Là, il atterrit dans la boucle d’événements du processus principal, qui le dispatche au champ actif : la barre d’adresse. Touche Enter, champ validé. L’odyssée commence.

Sous la loupe — ce que « exécuter » veut dire : CPU, caches, RAM

Chaque étape logicielle de cet article se ramène à la même mécanique : le processeur lit des instructions en mémoire, les décode et les exécute, à plusieurs milliards de cycles par seconde, sur une douzaine de cœurs, avec un pipeline qui traite plusieurs instructions en parallèle et un prédicteur de branchement qui parie sur la suite du programme.

Son goulot d’étranglement, c’est la mémoire. D’où une hiérarchie : des caches L1/L2 minuscules et ultra-rapides collés à chaque cœur, un L3 partagé, puis la RAM. Et la RAM elle-même est virtualisée : chaque adresse manipulée par un programme est traduite par la MMU via des tables de pages (accélérées par un cache dédié, le TLB). Si la page n’est pas en RAM, le noyau la charge depuis le disque — c’est un défaut de page.

Les ordres de grandeur ci-dessous expliquent toute l’architecture du reste de l’article : le réseau est un million de fois plus lent que la RAM, donc tout le monde cache tout, à tous les étages.

* si un cycle CPU durait une seconde.

02 — Le navigateur décortique l’URL

t + 1 ms · navigateur

Première question que se pose le navigateur : qu’est-ce que vous venez de taper ? La barre d’adresse est une « omnibox » : si le texte ne ressemble pas à une adresse, il part vers un moteur de recherche. Ici, www.example.com a la tête d’un nom de domaine ; le navigateur le canonise en une URL complète et la découpe : le schéma (https), l’hôte (www.example.com), le port implicite (443 pour HTTPS), le chemin (/).

Petit détail savoureux : il a probablement commencé avant que vous finissiez de taper. À chaque caractère, l’omnibox interroge l’historique et les suggestions, et si elle est suffisamment confiante sur votre destination, elle lance une préconnexion spéculative — résolution DNS, voire connexion TCP — en douce. Une partie du travail des chapitres suivants est parfois déjà faite au moment où vous appuyez sur Entrée.

Suivent quelques vérifications éclair. La liste HSTS d’abord : si le domaine y figure (elle est préchargée dans le navigateur), toute tentative en http:// sera convertie en https:// avant même de toucher le réseau. Les caches ensuite : une copie fraîche de la page existe-t-elle dans le cache mémoire de l’onglet, ou dans le cache disque ? Un service worker est-il enregistré pour ce site ? Si une réponse valide est trouvée, le voyage s’arrête presque ici. Supposons que non : il faut aller chercher la page. Le processus principal confie l’affaire au processus réseau, qui rassemble les cookies du domaine et les en-têtes à envoyer.

Dernier point d’architecture, invisible mais crucial : le futur contenu de la page sera confié à un processus de rendu isolé, sans droit d’accès direct à vos fichiers ni au réseau — le sandbox. Depuis les failles Spectre, chaque site a même droit à son propre processus (site isolation). Si une page malveillante compromet son moteur de rendu, elle reste enfermée dans une pièce vide.

03 — DNS : l’annuaire planétaire

t + 2 ms · réseau, système, protocole

Le réseau ne connaît pas les noms, seulement les adresses IP. Avant toute connexion, il faut donc traduire www.example.com en quelque chose comme 203.0.113.7. C’est le rôle du DNS (Domain Name System), une base de données distribuée sur toute la planète, hiérarchique, et sans doute l’infrastructure la plus sollicitée du monde — des milliers de milliards de requêtes par jour.

La quête suit une chaîne de caches. Le navigateur a le sien. Le système d’exploitation aussi, plus le vénérable fichier hosts. Si personne n’a la réponse, la machine — via son stub resolver, le client DNS minimal intégré à l’OS — envoie la question à un résolveur récursif : celui de votre box ou de votre FAI par défaut, ou un résolveur public comme 1.1.1.1 (Cloudflare), 8.8.8.8 (Google) ou 9.9.9.9 (Quad9). Historiquement, la question part en clair en UDP sur le port 53 ; de plus en plus souvent, elle est chiffrée (DoH, DNS sur HTTPS, ou DoT, DNS sur TLS).

Si le récursif n’a pas la réponse en cache, il remonte la hiérarchie depuis le sommet. Les serveurs racine — 13 adresses logiques, démultipliées en plus d’un millier d’instances physiques par la magie de l’anycast (une même IP annoncée depuis des dizaines d’endroits ; le routage vous amène à la plus proche) — ne connaissent pas example.com, mais savent qui gère .com. Les serveurs du TLD .com savent quels serveurs font autorité pour example.com. Et le serveur autoritatif, enfin, détient la réponse.

La réponse est un enregistrement parmi la petite grammaire du DNS :

Sous la loupe — le DNS comme levier d’architecture

Parce qu’il est le premier maillon, le DNS est devenu bien plus qu’un annuaire : c’est un instrument de pilotage. Un TTL court permet de basculer un site vers d’autres serveurs en quelques minutes (déploiements, pannes). Les CDN s’en servent pour vous répondre avec l’adresse du point de présence le plus proche de votre résolveur — c’est en partie pour cela que la page que vous voyez à Paris et celle vue à Tokyo ne sortent pas du même bâtiment. Revers de la médaille : c’est aussi un point de défaillance spectaculaire. Les grandes pannes d’Internet — Dyn en 2016, Facebook en 2021 — furent avant tout des pannes de DNS.

Notre machine détient désormais une adresse : 203.0.113.7, gardée en cache pour les 300 prochaines secondes. Une vingtaine de millisecondes se sont écoulées. Il est temps d’établir le contact.

04 — TCP : fabriquer un canal fiable sur un réseau qui ne l’est pas

t + 22 ms · protocole, système, matériel

Internet, à sa base, ne promet presque rien. Le protocole IP achemine des paquets indépendants, en « meilleur effort » : ils peuvent se perdre, arriver en double, en désordre, ou pas du tout. Construire là-dessus quelque chose d’utilisable, c’est le travail de TCP (Transmission Control Protocol, 1981) : un flux d’octets fiable et ordonné, simulé au-dessus d’un service qui ne l’est pas.

Le processus réseau du navigateur demande au noyau une prise de communication — une socket — via un appel système, puis connect() vers 203.0.113.7, port 443. Le noyau choisit un port source éphémère (disons 51646) : le quadruplet (IP source, port source, IP destination, port destination) identifiera cette connexion parmi toutes les autres. Puis s’engage la fameuse poignée de main en trois temps : la machine envoie un segment SYN (« je veux ouvrir, je numérote mes octets à partir de X »), le serveur répond SYN-ACK (« reçu, moi je numérote à partir de Y »), la machine conclut par ACK. Un aller-retour complet — nos ~15 ms — avant le moindre octet utile : c’est le prix d’entrée, et la raison pour laquelle navigateurs et serveurs recyclent leurs connexions autant que possible.

Ces numéros de séquence sont le cœur du mécanisme : chaque octet émis est numéroté et doit être acquitté. Non acquitté à temps ? Retransmis. Arrivé en désordre ? Réordonné. TCP gère aussi deux régulations : le contrôle de flux (ne pas noyer le destinataire, qui annonce sa fenêtre de réception) et le contrôle de congestion (ne pas noyer le réseau). Une connexion démarre prudemment — le slow start, une dizaine de segments — puis accélère à chaque aller-retour sans perte, et ralentit dès que ça frotte. Des algorithmes comme CUBIC ou BBR passent leur vie à chercher le débit maximal que le chemin peut porter. C’est grâce à eux qu’Internet ne s’effondre pas sur lui-même — il l’a fait, une fois, en 1986.

Sous la loupe — le trajet d’un segment dans votre machine

Quand le noyau émet ce SYN, que se passe-t-il physiquement ? La pile TCP/IP du noyau construit le segment dans une structure en RAM, y ajoute l’en-tête IP, choisit l’interface de sortie d’après sa table de routage, et le dépose dans une file de l’émetteur : l’anneau de transmission de la carte réseau (NIC). Celle-ci lit alors le paquet directement en RAM, sans déranger le processeur — c’est le DMA, l’accès direct à la mémoire — puis le sérialise sur le support : impulsions électriques sur du cuivre, symboles radio en Wi-Fi, lumière sur la fibre. À la réception, symétrie parfaite : la carte dépose les paquets en RAM par DMA et lève une interruption, exactement comme le clavier au chapitre 01. À haut débit, le noyau bascule même en mode sondage (NAPI) pour ne pas mourir sous les interruptions — un serveur chargé en reçoit des millions par seconde.

05 — TLS : sceller l’enveloppe

t + 37 ms · protocole, cryptographie

Le canal TCP existe, mais tout ce qui y passerait serait lisible — et falsifiable — par chaque routeur, chaque Wi-Fi public, chaque intermédiaire du chemin. Le s de https, c’est TLS (Transport Layer Security), qui apporte trois garanties : la confidentialité (chiffrement), l’intégrité (toute altération est détectée) et l’authenticité (vous parlez bien à example.com, pas à un imposteur).

En TLS 1.3 (2018), la négociation tient en un seul aller-retour. Le navigateur ouvre avec un ClientHello : les suites cryptographiques qu’il sait parler, le nom du site demandé (le SNI, nécessaire car un même serveur héberge souvent des centaines de sites), l’extension ALPN (« sais-tu parler HTTP/2 ? »), et — l’astuce qui économise un aller-retour par rapport à TLS 1.2 — sa part d’un échange de clés Diffie-Hellman sur courbe elliptique, envoyée d’office. Le serveur répond avec sa propre part, son certificat, et une signature prouvant qu’il détient la clé privée associée. Dès cet instant, les deux parties dérivent les mêmes clés de session sans jamais les avoir transmises — c’est la beauté de Diffie-Hellman — et tout le reste de la conversation est chiffré (AES-GCM ou ChaCha20-Poly1305).

Reste la question de confiance : pourquoi croire ce certificat ? Parce qu’il est signé par une autorité de certification (Let’s Encrypt, DigiCert…), elle-même signée par une autorité racine dont la clé publique est pré-installée dans votre OS et votre navigateur — le magasin de confiance, une centaine d’organisations qui portent, littéralement, la confiance du web. Le navigateur vérifie la chaîne complète, le nom, les dates, et la présence du certificat dans les journaux publics de Certificate Transparency. Bonus élégant : les clés de session étant éphémères, même un attaquant qui volerait plus tard la clé privée du serveur ne pourrait pas déchiffrer les conversations passées — la confidentialité persistante (forward secrecy).

06 — HTTP : enfin, la requête

t + 52 ms · protocole, navigateur

Cinquante millisecondes de préparatifs pour en arriver là : demander la page. HTTP (HyperText Transfer Protocol) est un protocole d’une simplicité désarmante — c’est son génie. Un client demande une ressource par un verbe et un chemin, un serveur répond par un code de statut et un contenu. Conceptuellement, notre requête ressemble à ceci :

GET / HTTP/2
host: www.example.com
user-agent: Mozilla/5.0 (Macintosh…) Chrome/143.0
accept: text/html,application/xhtml+xml,…
accept-encoding: gzip, deflate, br, zstd
accept-language: fr-FR,fr;q=0.9
cookie: session=k7Jq2…
if-none-match: "a1b9c"

Chaque en-tête est une petite négociation : les formats acceptés, les compressions comprises (br, c’est Brotli, qui divise le poids du HTML par cinq), la langue préférée, les cookies qui portent votre session. Et if-none-match illustre l’obsession du cache : il signifie « j’ai déjà une copie, version a1b9c » — si le serveur constate que cette copie est encore la bonne, il répondra 304 Not Modified, sans corps, quelques octets au lieu de quelques dizaines de kilo-octets.

La réponse aura la même forme : un statut (200 OK, 301 redirection, 404 introuvable, 500 erreur serveur — les 2xx disent « succès », les 3xx « allez voir ailleurs », les 4xx « c’est vous », les 5xx « c’est moi »), des en-têtes (type de contenu, directives de cache cache-control, en-têtes de sécurité), puis le corps : le HTML.

Le protocole, lui, a beaucoup évolué sous cette surface stable :

Notre navigateur, prévenu par l’ALPN du chapitre précédent, parle ici HTTP/2. La requête — quelques centaines d’octets une fois compressée et chiffrée — est remise au noyau, qui la découpe en segments TCP. Elle quitte la machine. Suivons-la.

07 — Le voyage : routeurs, câbles et lumière

t + 53 ms · réseau, matériel

Ce qui circule sur le câble n’est pas « une requête » : c’est une poupée russe. La requête HTTP est chiffrée dans un enregistrement TLS, découpé en segments TCP, chacun glissé dans un paquet IP, lui-même emballé dans une trame adaptée au support physique. Chaque couche a son en-tête, ses adresses, son rôle — et chaque équipement du chemin ne lit que la couche qui le concerne.

Premier bond : la trame part en Wi-Fi vers la box — modulée en symboles radio sur un canal partagé, acquittée trame par trame, retransmise en cas de collision — ou en Ethernet sur cuivre. La box joue alors trois rôles : commutateur, routeur, et surtout NAT. Votre machine porte une adresse privée (192.168.1.24) invisible d’Internet ; la box substitue sa propre adresse publique, note la correspondance dans sa table (192.168.1.24:51646 ↔ 88.x.x.x:29104), et fera la traduction inverse au retour. Puis le paquet file sur la fibre : converti en lumière, il traverse le réseau de collecte du FAI jusqu’à un cœur de réseau régional.

À partir de là, le paquet saute de routeur en routeur — quinze à vingt-cinq bonds typiquement, visibles avec l’outil traceroute. Chaque routeur fait une seule chose, des millions de fois par seconde : lire l’adresse IP de destination, consulter sa table de routage (plus d’un million de préfixes aujourd’hui), décrémenter le champ TTL (à zéro, le paquet meurt — c’est l’anti-boucle), et réémettre sur la bonne interface. Mais qui remplit ces tables ? Personne ne « dirige » Internet : c’est une fédération d’environ cent mille systèmes autonomes (AS) — FAI, hébergeurs, universités, géants du cloud — qui s’annoncent mutuellement leurs routes via le protocole BGP, se connectent en direct sur des points d’échange (à Paris : France-IX) ou achètent du transit aux opérateurs de dorsales. La route de votre paquet est le produit de milliers d’accords commerciaux — et d’aucun plan d’ensemble.

Si le serveur est loin, le paquet empruntera l’un des ~500 câbles sous-marins qui tissent les continents — des fibres de la taille d’un tuyau d’arrosage qui portent chacune des centaines de térabits par seconde. Dans le verre, la lumière avance à ~200 000 km/s, les deux tiers de sa vitesse dans le vide : Paris–New York coûte incompressiblement ~30 ms l’aller. C’est la seule limite que l’ingénierie ne négociera jamais — d’où, précisément, l’invention des CDN : si on ne peut pas accélérer la lumière, on rapproche le serveur.

08 — Côté serveur : la remontée de la pile, en miroir

t + 65 ms · serveur, réseau, système

« Le serveur » est une commodité de langage. Pour un site sérieux, votre requête atterrit d’abord sur un point de présence (PoP) d’un CDN — Cloudflare, Fastly, Akamai, CloudFront — situé à quelques millisecondes de chez vous, sélectionné par la magie du DNS géographique ou de l’anycast croisés au chapitre 03. C’est lui qui a répondu aux poignées de main : la terminaison TLS se fait en périphérie, précisément pour que ces allers-retours restent courts.

Là, premier verdict : le cache. Si la ressource est statique et présente sur le PoP, la réponse repart immédiatement — la majorité du trafic mondial se règle ainsi, sans jamais toucher le serveur d’origine. Notre page d’accueil est dynamique : direction l’origine, via une connexion longue distance que le CDN maintient ouverte et réutilise (encore des poignées de main économisées).

À l’origine, la requête traverse une petite chaîne de tri. Un répartiteur de charge la distribue vers l’une des machines saines du parc — il les sonde en permanence et écarte celles qui toussent. Sur la machine élue, le noyau vit le chapitre 04 en miroir : le port 443 est en écoute, la connexion sort de la file d’accept, et un reverse proxy comme nginx la prend en charge. Son architecture mérite une phrase : un processus par cœur, chacun surveillant des dizaines de milliers de connexions via epoll — le mécanisme du noyau qui dit « préviens-moi quand l’une d’elles a du nouveau » — sans jamais bloquer. C’est la réponse moderne au vieux « problème des 10 000 connexions ».

nginx transmet enfin à l’application — du code Node.js, Python, Go, PHP, Java… — qui fait le vrai travail métier : valider la session portée par le cookie, interroger la base de données (elle-même précédée d’un cache mémoire type Redis, car même 5 ms de requête SQL sont une éternité à cette échelle), assembler le HTML. Puis tout redescend : compression Brotli, chiffrement TLS, segments TCP, paquets IP — la pile entière, dans l’autre sens.

Le premier octet de la réponse atteint votre machine autour de t + 130 ms — c’est le TTFB (time to first byte) des outils de mesure. Le reste du HTML suit, cadencé par le contrôle de congestion, en quelques dizaines de millisecondes. La partie réseau de l’odyssée s’achève. Reste à transformer ces octets en page.

09 — Le rendu : de l’octet au pixel

t + 130 ms · navigateur, matériel

Les octets déchiffrés et décompressés sont poussés vers le processus de rendu sandboxé du chapitre 02. Commence la dernière métamorphose, la plus étrange : transformer du texte en géométrie, puis en couleurs.

Le parseur HTML lit le document et construit le DOM, l’arbre des éléments. Il n’attend pas la fin : dès les premières lignes, un préchargeur balaie le reste du fichier à la recherche de ressources à télécharger — feuilles de style, scripts, polices, images — et lance ces requêtes en parallèle. Chacune rejoue une mini-odyssée : cache, DNS éventuel, la connexion HTTP/2 existante, le CDN. Une page moyenne embarque ainsi 70 sous-ressources ; c’est le vrai coût du web moderne, bien plus que le HTML lui-même.

Le CSS, parsé de son côté, devient le CSSOM : l’ensemble des règles, résolues selon la cascade et la spécificité. Le JavaScript, lui, passe au moteur V8 : d’abord compilé en bytecode et interprété, puis — pour les fonctions chaudes — recompilé à la volée en code machine optimisé par les étages supérieurs du JIT, avec des paris sur les types qui seront annulés si le code se met à mentir. Attention au piège historique : un <script> sans attribut defer/async bloque le parseur, car il a le droit de réécrire le document en plein vol. C’est la raison d’être de la moitié des conseils de performance web.

DOM et CSSOM fusionnent en arbre de rendu (les éléments visibles, avec leurs styles calculés). Le layout résout alors le système de contraintes — flexbox, grilles, flux de texte — et assigne à chaque boîte une position et une taille au pixel près. Le paint convertit ces boîtes en listes d’instructions de dessin, rastérisées par couches. Enfin le compositeur — sur son propre fil d’exécution, aidé du processus GPU — assemble les couches à l’écran. C’est lui qui rend le défilement fluide : faire glisser des couches déjà peintes ne coûte presque rien au GPU, pendant que le fil principal reste libre.

Dernier maillon, purement matériel : le compositeur livre ses images au rythme du VSync de l’écran. Le contrôleur d’affichage lit la mémoire vidéo et pilote la dalle, qui ajuste ses cristaux liquides ou ses OLED pixel par pixel. Autour de t + 300 ms, les photons partent vers votre rétine. Les métriques modernes donnent des noms à ces instants : First Contentful Paint pour le premier contenu, Largest Contentful Paint pour l’élément principal. Votre page est là.

10 — Épilogue : trois cents millisecondes

t + 300 ms

Récapitulons le voyage, en vraie grandeur :

Trois cents millisecondes, donc — un battement de paupières. Dans ce battement : un microcontrôleur de clavier, une interruption matérielle, une quinzaine de processus, quatre protocoles empilés, un annuaire distribué sur des milliers de serveurs, deux poignées de main cryptographiques, une vingtaine de routeurs appartenant à une demi-douzaine d’organisations différentes, un centre de données, une base de données, un compilateur à la volée et une carte graphique. Le noyau Linux pèse à lui seul quelque quarante millions de lignes de code, Chromium à peu près autant : personne, nulle part, ne comprend l’édifice en entier. Il tient parce que chaque couche offre à celle du dessus une abstraction simple — un flux fiable, un nom résolu, un canal sûr, un document structuré — et lui cache tout le reste.

Et le plus vertigineux n’est pas là. Le plus vertigineux, c’est que ce n’était que la première requête. Chaque feuille de style, chaque script, chaque image de la page a rejoué sa propre miniature de cette odyssée ; chaque lien sur lequel vous cliquerez recommencera tout. Ce ballet se produit, à l’échelle du globe, quelques millions de fois par seconde — sur une infrastructure sans chef d’orchestre, tenue par des accords entre cent mille réseaux et par une pile de standards ouverts dont les plus anciens ont cinquante ans. La prochaine fois que vous appuierez sur Entrée, vous saurez ce que vous venez de déclencher.

Pour creuser

• What happens when… — la version encyclopédique et collaborative de cette question, en anglais.
• High Performance Browser Networking, Ilya Grigorik — le livre de référence, libre d’accès, sur TCP, TLS, HTTP et les réseaux mobiles.
• How DNS works — la résolution DNS en bande dessinée.
• Inside look at modern web browser — l’architecture de Chrome racontée par son équipe, en quatre parties.
• Les textes canoniques, d’une lisibilité étonnante : RFC 9293 (TCP), RFC 8446 (TLS 1.3), RFC 9114 (HTTP/3).

Les durées de cet article sont des ordres de grandeur, pas des mesures. Schémas SVG faits main. www.example.com est un domaine réservé à la documentation par la RFC 2606, qui vous répondra pourtant vraiment.