Comment fonctionne réellement Internet

Où sont passées les deux secondes ?

Kofi, à Douala, touche un lien vers le relevé de son compte de monnaie mobile. L'écran reste blanc deux secondes, puis la page apparaît. Qu'a fait son téléphone pendant ce temps ? Pour répondre autrement que par « Internet est lent », il faut savoir que l'ouverture d'une page est faite de quatre opérations successives, chacune pouvant échouer ou ralentir indépendamment des autres.

1. DNS   nom -> adresse            shop.bac.example -> 203.0.113.20
2. TCP   adresse -> connexion      trois messages : SYN, SYN-ACK, ACK
3. TLS   connexion -> privée       clés convenues, certificat vérifié (https seulement)
4. HTTP  connexion -> requête      GET /releve -> 200 + les données

Les adresses de cet atelier sont fictives : 203.0.113.0/24 est une plage réservée à la documentation, et le domaine .example n'existe pas sur le vrai Internet.

Les quatre phases en une phrase chacune

• DNS (Domain Name System) : un annuaire. Le réseau ne sait acheminer que vers des adresses numériques ; on demande donc à un serveur appelé résolveur l'adresse qui correspond au nom.
• TCP (Transmission Control Protocol) : on ouvre un canal fiable entre deux programmes, un peu comme décrocher et entendre « allô ? » avant de parler.
• TLS (Transport Layer Security) : on convient de clés secrètes et on vérifie un certificat pour que la conversation soit privée et attribuée à un serveur précis. Cette phase n'existe que pour les adresses https.
• HTTP (HyperText Transfer Protocol) : enfin la conversation utile. Le client envoie quelques lignes de texte (« donne-moi /releve »), le serveur répond par un code (200 = réussi, 404 = introuvable) et des données.

Exemple détaillé

Supposons un aller-retour (RTT, round-trip time : le temps pour qu'un message aille au serveur et que la réponse revienne) de 100 ms vers le serveur, et un résolveur proche qui connaît déjà la réponse (30 ms). Dans le cas courant, sans connexion déjà ouverte :

Ce calcul est un modèle simplifié, pas une mesure : il ignore le temps de calcul du serveur, la taille de la réponse et les pertes de paquets. Il montre pourtant l'essentiel : trois des quatre phases coûtent chacune un aller-retour complet vers le serveur, quelle que soit la quantité de données. Les navigateurs réduisent ce coût en réutilisant des connexions déjà ouvertes et en gardant les réponses DNS en cache (c'est-à-dire en mémoire) ; le protocole HTTP/3 fusionne même l'ouverture du transport et la phase cryptographique. Nous étudions le chemin classique, parce que les variantes récentes se comprennent comme des raccourcis de celui-ci.

Ce que chaque phase garantit — et ne garantit pas

À retenir

Ouvrir une page = DNS, puis TCP, puis TLS, puis HTTP. Chaque phase coûte du temps (souvent un aller-retour) et offre une garantie étroite. Utilisez le schéma interactif ci-dessous : avancez pas à pas et notez, à chaque étape, ce qu'un observateur placé sur le trajet peut lire.

Une capture, trois protocoles mélangés

Un outil comme Wireshark ou tcpdump affiche chaque paquet qui passe par une interface réseau. Voici un extrait fictif et simplifié (adresses privées et de documentation) : un téléphone 10.0.0.5 ouvre une page https.

No.  Source             Destination        Proto  Info
 1   10.0.0.5:53012     10.0.0.1:53        DNS    requête  A shop.bac.example
 2   10.0.0.1:53        10.0.0.5:53012     DNS    réponse  A 203.0.113.20
 3   10.0.0.5:40111     203.0.113.20:443   TCP    SYN
 4   203.0.113.20:443   10.0.0.5:40111     TCP    SYN, ACK
 5   10.0.0.5:40111     203.0.113.20:443   TCP    ACK
 6   10.0.0.5:40111     203.0.113.20:443   TLS    ClientHello
 7   203.0.113.20:443   10.0.0.5:40111     TLS    ServerHello (le reste de la poignée de main est chiffré)

Comment distinguer les trois familles ? Par ce que le paquet est et par le port (un numéro qui désigne le programme visé sur une machine, après le deux-points) :

• Lignes 1-2, DNS. Le port 53 est celui du DNS. Le téléphone interroge 10.0.0.1 (ici, le routeur de la maison faisant office de résolveur) ; le serveur web n'est pas encore contacté. La réponse contient l'adresse 203.0.113.20. Le DNS passe le plus souvent par UDP, un transport léger sans connexion : une question, une réponse.
• Lignes 3-5, TCP. Le premier paquet envoyé au serveur web est la ligne 3 : SYN, « je voudrais parler ». Puis SYN-ACK, puis ACK : la connexion est ouverte. Le port 443 est le port habituel de HTTPS.
• Lignes 6-7, TLS. Une fois TCP ouvert, le client envoie ClientHello : la phase cryptographique commence par-dessus la connexion existante. En TLS 1.3, tout ce qui suit le ServerHello, certificat compris, est déjà chiffré : une capture ne le montre donc pas en clair (en TLS 1.2, le certificat passait en clair).

Les couches : des enveloppes emboîtées

Chaque message est glissé dans une enveloppe, elle-même glissée dans une autre :

Les modèles à sept ou à quatre couches que vous croiserez dans les manuels découpent ces enveloppes un peu différemment ; l'important ici est l'ordre et le rôle, pas un numéro à mémoriser.

Routage IP : de saut en saut

Une adresse IPv4 s'écrit sur 32 bits, en quatre octets : 203.0.113.20. La notation CIDR ajoute une barre oblique et le nombre de bits qui désignent le réseau : dans 192.168.1.0/26, les 26 premiers bits désignent le réseau, les 6 derniers les machines. Cela donne 2^6 = 64 adresses, de 192.168.1.0 (adresse du réseau) à 192.168.1.63 (adresse de diffusion). Par convention, ces deux adresses extrêmes ne sont pas attribuées à des machines : il reste donc 62 adresses utilisables (les cas particuliers /31 et /32 sont hors programme).

Un routeur n'a pas une carte d'Internet. Il possède une table : « les paquets pour tel préfixe, donnez-les à tel voisin ». À chaque saut, il lit l'adresse de destination, choisit la ligne qui correspond au préfixe le plus précis et transmet. Chaque routeur décrémente aussi un compteur, le TTL (time to live) ; arrivé à zéro, le paquet est détruit et le routeur le signale à l'émetteur. L'outil traceroute exploite exactement cela : il envoie des paquets de TTL 1, 2, 3… et note qui répond à chaque fois, ce qui dessine le chemin saut après saut.

Dernière précision utile : la plupart des téléphones et ordinateurs portent une adresse privée (par exemple 10.x.x.x ou 192.168.x.x). Le serveur ne voit pas cette adresse : il voit celle de l'équipement qui fait la traduction à la sortie du réseau local.

Ce que cela ne garantit pas

IP ne promet pas la livraison : c'est TCP, au-dessus, qui détecte les trous et redemande les paquets manquants. Et ni IP ni TCP ne protègent le contenu : un observateur placé sur le trajet lit les adresses, les ports et, sans TLS, les données.

À retenir

DNS = une question posée à un résolveur (port 53, avant tout contact avec le serveur). IP = l'adressage et le routage de paquets, sans garantie. TCP = la connexion fiable entre deux programmes, reconnaissable à SYN, SYN-ACK, ACK. Dans une capture, on les reconnaît à leur nature et à leur port.

Pourquoi une petite page peut être plus lente qu'un gros fichier ?

Awa télécharge un fichier de 5 Mo sur une bonne connexion, et c'est rapide. Puis elle ouvre une page de 20 Ko, dont chaque élément demande une nouvelle requête, et c'est lent. Deux grandeurs différentes sont en jeu, et on les confond sans cesse :

• la latence : le temps qu'un message met à aller et revenir (RTT), en millisecondes. Elle dépend surtout de la distance et du nombre d'équipements traversés ;
• le débit (ou bande passante) : la quantité de données qui passe par seconde, en mégabits par seconde (Mbit/s). Il dépend de la capacité du lien le plus étroit du trajet.

Une image : sur une route, la latence est le temps du trajet à vide ; le débit est le nombre de voies. Ajouter des voies ne raccourcit pas un trajet de 300 km.

Le modèle de calcul

Pour estimer le temps d'un échange, nous utiliserons un modèle simplifié :

durée totale = (allers-retours d'établissement × RTT) + (taille × 8 ÷ débit)

La taille est en mégaoctets ; on multiplie par 8 pour obtenir des mégabits (1 octet = 8 bits). Les phases TCP, TLS et requête comptent chacune un aller-retour d'établissement ; le DNS est compté à part (leçon 1) et on le suppose ici déjà résolu.

Exemple. Fichier de 5 Mo, débit 20 Mbit/s, RTT 120 ms, 3 allers-retours d'établissement (TCP, TLS, requête) :

• transmission des données : 5 × 8 ÷ 20 = 2 secondes = 2 000 ms ;
• établissement : 3 × 120 = 360 ms ;
• total : 2 000 + 360 = 2 360 ms.

Ici le débit domine : la transmission pèse plus de cinq fois l'établissement. Prenons maintenant une page de 20 Ko (0,02 Mo) sur la même connexion : 0,02 × 8 ÷ 20 = 0,008 s = 8 ms de transmission, contre 360 ms d'établissement. Cette fois la latence domine presque entièrement. Et si la page exige dix requêtes sur dix connexions neuves, on paie dix fois les allers-retours.

Un plancher physique

La lumière dans une fibre optique avance à peu près aux deux tiers de sa vitesse dans le vide, soit environ 200 000 km/s. Pour un trajet de 6 000 km (chiffre rond, à titre d'illustration), l'aller prend au mieux 30 ms, donc l'aller-retour au moins 60 ms — et les chemins réels sont plus longs que la ligne droite, avec des équipements à traverser. Aucune optimisation logicielle ne passe sous ce plancher ; on peut seulement faire moins d'allers-retours ou rapprocher les serveurs.

C'est pourquoi les systèmes sérieux réutilisent les connexions, mémorisent les réponses DNS (le premier appel est souvent bien plus lent que les suivants) et regroupent les requêtes. TLS 1.3 (RFC 8446, voir RFC 8446) a été conçu notamment pour qu'une poignée de main complète ne coûte qu'un seul aller-retour, là où TLS 1.2 en demandait deux.

Pourquoi cela compte pour la suite

Quand un nœud de blockchain relaie un bloc à ses voisins, ou qu'un portefeuille interroge un service distant, les mêmes lois s'appliquent : beaucoup de petits messages coûtent des allers-retours, un gros message coûte du débit. Vous retrouverez ce raisonnement quand nous parlerons de la propagation des blocs dans les ateliers de consensus.

Ce que le modèle ne dit pas

C'est une approximation : il ignore la perte de paquets (qui force des retransmissions), le démarrage progressif de TCP (qui n'utilise pas tout le débit au début d'une connexion), la congestion, et le temps de calcul du serveur. Pour savoir ce qui se passe vraiment, il faut mesurer — c'est l'objet du laboratoire autonome.

À retenir

Latence = temps d'un aller-retour ; débit = volume par seconde. Les petites requêtes sont limitées par la latence, les gros fichiers par le débit. La distance impose un plancher que le logiciel ne franchit pas.

Le cadenas veut-il dire « site sûr » ?

Un message arrive : « Votre compte est bloqué, connectez-vous ici ». Le lien mène à un site avec un cadenas dans la barre d'adresse. Le site est-il fiable ? Non — et comprendre pourquoi demande de séparer trois garanties que l'on résume trop souvent en un seul mot, « chiffré ».

Trois garanties, pas une

La troisième repose sur le certificat : un document, signé par une autorité que votre appareil connaît déjà, qui affirme « cette clé appartient au nom de domaine shop.bac.example ». La façon dont les signatures fonctionnent est le sujet de l'atelier 105 ; retenez pour l'instant que votre appareil embarque une liste d'autorités de confiance et vérifie que le certificat présenté est signé par l'une d'elles et correspond bien au nom demandé.

Le déroulement, en gros, avec TLS 1.3 (RFC 8446) : le client envoie ClientHello ; le serveur répond par ses éléments d'échange de clés (ServerHello), puis envoie son certificat, déjà chiffré avec les clés issues de cet échange ; les deux côtés calculent les mêmes clés de session sans jamais les envoyer ; tout ce qui suit est chiffré et authentifié avec ces clés.

Ce que fait désactiver la vérification

Une erreur de certificat est pénible, et beaucoup de code « qui marche » la contourne avec des réglages comme verify=False ou --insecure. Ce que l'on supprime alors, c'est précisément la troisième garantie. La conversation reste chiffrée — avec quelqu'un dont on ne sait plus rien. Un attaquant placé sur le trajet présente son propre certificat, le programme l'accepte ; l'attaquant déchiffre, lit, éventuellement modifie, rechiffre et relaie. Les deux extrémités voient une connexion parfaitement chiffrée. C'est une attaque de l'homme du milieu (man-in-the-middle), et le chiffrement ne la gêne pas : il la dissimule. Pour une machine de test que vous maîtrisez, avec son certificat auto-signé, la bonne pratique n'est pas de tout désactiver : indiquez à l'outil de faire confiance à CE certificat précis (par exemple curl --cacert cert.pem, ou verify="cert.pem" avec la bibliothèque Python requests). La vérification reste alors active pour ce serveur seulement. Sur un chemin que vous ne contrôlez pas, la désactiver n'est jamais acceptable.

Ce que TLS ne protège pas, même bien configuré

• Ce que vous regardez reste visible. L'adresse IP du serveur est lisible, par nécessité. Dans la configuration classique, le nom du serveur voyage aussi en clair au début de la poignée de main (champ SNI, server name indication), et la requête DNS d'avant le faisait déjà. Des extensions (Encrypted Client Hello, DNS chiffré) existent pour réduire ces fuites, mais elles ne sont pas partout activées. Un observateur ne lit donc pas vos messages, mais il sait avec qui vous parlez et quand.
• La taille et le rythme fuient. Des messages chiffrés dont on connaît la longueur et le tempo en disent beaucoup, sans qu'un octet soit déchiffré.
• Le serveur voit tout. TLS protège le transport, pas la destination : ce que vous envoyez à un service, il le lit en clair.
• Un certificat valide ne prouve pas l'honnêteté. Il atteste un nom de domaine, rien de plus. Un site de hameçonnage avec un nom trompeur peut obtenir un certificat valide.
• Les extrémités restent exposées. Un téléphone infecté lit les données avant le chiffrement et après le déchiffrement.

La question à garder

Face à tout système, dans la suite du cursus, la question n'est pas « est-ce chiffré ? » mais :

Qui peut mentir ici, et que se passe-t-il alors ?

Vous venez d'y répondre une fois, sur les quatre phases d'une requête HTTPS : le DNS peut mentir (réponse falsifiée), le réseau peut lire ou perdre des paquets, le serveur peut mentir sur le contenu. Chaque couche a réduit une partie du problème, aucune ne l'a supprimé.

À retenir

TLS = confidentialité + intégrité + authentification du serveur nommé. Il ne cache ni l'adresse du serveur ni, classiquement, son nom, il ne prouve pas l'honnêteté, et il s'arrête aux extrémités. Désactiver la vérification supprime l'authentification, pas le chiffrement.