Réseaux et communication

Objectifs du chapitre

À la fin de ce chapitre, vous serez capable de:

• opposer la commutation de circuits et la commutation de paquets, dire ce que chacune réserve et quel prix la seconde fait payer (délai variable, perte, déséquencement);
• expliquer pourquoi un réseau est construit en couches, suivre un message à travers la pile TCP/IP et calculer la surcharge d'encapsulation d'une trame;
• décrire l'adressage IP, comparer les espaces d'adressage d'IPv4 et d'IPv6 par le calcul, et retracer la résolution d'un nom par le DNS;
• expliquer le principe de proche en proche du routage et pourquoi aucun routeur ne connaît la route complète;
• expliquer comment TCP obtient une livraison fiable sur un réseau qui ne la garantit pas, ce que fait le contrôle de congestion, et quand UDP est le bon choix;
• décomposer le temps de transfert en propagation, transmission et attente, calculer le plancher de latence imposé par la vitesse de la lumière, et compter les allers-retours d'un chargement de page web.

Le problème

Les neuf chapitres précédents ont supposé une machine seule. Le chapitre 1 lui a donné une manière de représenter l'information, les chapitres 2 à 5 ont mesuré ce qu'elle peut calculer et à quel prix, les chapitres 6 à 8 ont compté les bits nécessaires et ceux qu'il faut rajouter pour survivre au bruit, le chapitre 9 a montré comment rendre un message inintelligible à qui n'en est pas le destinataire. Il reste la dernière question du cours: comment faire passer ces bits d'une machine à une autre?

Formulée ainsi, la question paraît modeste. Elle ne l'est pas, à cause de quatre contraintes qui tiennent toutes ensemble.

• Le support est partagé. Une fibre, un câble, une bande de fréquences ne servent pas un seul émetteur. Il faut donc une règle d'accès, et cette règle décide de tout le reste.
• Le support n'est pas fiable. Un bit peut être altéré par le bruit thermique, une interférence, une soudure fatiguée. Un paquet entier peut être détruit parce qu'un routeur n'avait plus de mémoire pour le stocker. Le chapitre 8 a fourni les outils pour détecter et corriger; il reste à décider quoi faire quand la détection dit «cette trame est fausse».
• L'échelle est planétaire. Le nombre de machines raccordées se compte en milliards et aucune d'entre elles ne peut connaître la position de toutes les autres. Toute solution qui demanderait à un équipement de détenir la carte complète du réseau est disqualifiée d'avance.
• La vitesse de la lumière est finie. C'est la contrainte la plus dure du chapitre, parce qu'elle ne se contourne pas: aucune somme d'argent n'achète un signal plus rapide que la lumière. Nous la calculerons plus loin et nous en tirerons la leçon centrale du chapitre.

Cette dernière phrase explique la forme qu'a prise l'Internet. Les documents qui définissent ses protocoles sont publics, numérotés, et n'importe qui peut les lire.

Commutation de circuits et commutation de paquets

Deux manières de partager un support

Le réseau téléphonique du vingtième siècle et l'Internet répondent à la question du partage de deux façons incompatibles.

La différence tient en une phrase: le circuit réserve à l'avance, le paquet partage à la demande. Tout le reste en découle, y compris les défauts.

Pourquoi les paquets ont gagné

La raison n'est pas idéologique, elle est arithmétique. Le trafic informatique est sporadique: une session de navigation ou de terminal passe l'essentiel de son temps sans rien émettre, puis émet une rafale. Réserver une capacité pour un émetteur silencieux la gaspille.

Un second argument, moins quantifiable mais décisif, est l'absence d'état. Un routeur en commutation de paquets ne mémorise rien d'une communication: il regarde l'adresse de destination d'un paquet, choisit un lien, et l'oublie. On peut donc ajouter, retirer ou faire tomber des équipements sans renégocier quoi que ce soit, et la même infrastructure porte indifféremment un appel vocal, un transfert de fichier ou une mise à jour logicielle. Cette neutralité vis-à-vis de l'usage est la raison pour laquelle un réseau conçu pour des terminaux de laboratoire porte aujourd'hui la téléphonie qui devait le remplacer.

Ce que les paquets coûtent

Trois défauts, tous conséquences directes de l'absence de réservation, et aucun n'est un accident d'implémentation.

• Le délai est variable. Un paquet qui trouve une file vide traverse un routeur en quelques microsecondes; le même paquet, arrivé une milliseconde plus tard derrière une rafale, attend. Cette variabilité s'appelle la gigue (jitter) et elle est le cauchemar des applications temps réel.
• Les paquets se perdent. La file d'attente d'un routeur est finie. Lorsqu'elle est pleine, le paquet suivant est détruit — et il n'y a rien de mieux à faire. La perte n'est donc pas une panne: c'est le mode normal de signalisation de la saturation.
• Les paquets se déséquencent. Deux paquets d'un même message peuvent suivre deux routes différentes et arriver dans le désordre. Rien dans le réseau ne l'interdit.

Ces trois défauts sont le cahier des charges de TCP, que nous verrons plus loin. Retenez la logique: le réseau a été rendu simple et non fiable pour pouvoir être grand, et la fiabilité a été repoussée dans les machines aux extrémités.

Le modèle en couches

Pourquoi découper

Un réseau doit faire coexister des supports physiques sans rapport entre eux (fibre, cuivre, radio), des équipements de dix constructeurs et des applications qu'on n'avait pas imaginées en le concevant. Écrire un programme qui traite tout cela d'un bloc est impossible: chaque nouvelle technologie de câble obligerait à réécrire chaque navigateur.

L'idée est exactement celle de l'abstraction en programmation, appliquée à un système réparti: on remplace un problème par une pile de problèmes indépendants, dont chacun peut changer sans que les autres le sachent. Le prix à payer est une perte d'efficacité — de l'information est recopiée d'une couche à l'autre, et chaque couche ajoute ses propres octets — et une opacité parfois gênante: une couche ne peut pas dire à celle du dessous pourquoi elle veut que ce paquet parte d'abord.

La pile TCP/IP

Quatre couches suffisent à décrire l'Internet.

Le modèle OSI, plus ancien, en distingue sept en ajoutant une couche physique sous la liaison et deux couches (session, présentation) entre le transport et l'application. Son vocabulaire est resté — on dit couramment «couche 2» pour la liaison et «couche 3» pour le réseau — mais l'Internet est bâti sur les quatre du tableau. Retenez surtout la ligne médiane: IP est la couche étroite. Tout ce qui est au-dessus doit fonctionner sur IP, tout ce qui est en dessous doit porter IP, et c'est ce goulet unique qui rend le réseau universel.

L'encapsulation

Suivons un message concret. Un navigateur envoie une requête HTTP; la requête a été découpée par TCP en segments d'au plus $1460$ octets, et nous suivons un segment plein.

1. Application. $1460$ octets de texte HTTP.
2. Transport. TCP préfixe un en-tête de $20$ octets sans option (ports source et destination, numéro de séquence, numéro d'acquittement, fenêtre, somme de contrôle, drapeaux). Total: $1480$ octets.
3. Réseau. IPv4 préfixe un en-tête de $20$ octets sans option (adresses source et destination, durée de vie, protocole, somme de contrôle d'en-tête). Total: $1500$ octets — c'est exactement la MTU (maximum transmission unit) d'Ethernet, et ce n'est pas une coïncidence: le $1460$ du début a été choisi pour que le paquet y tienne.
4. Liaison. Ethernet préfixe $14$ octets (adresse MAC destination, adresse MAC source, type) et ajoute en fin de trame $4$ octets de (), qui est un — celui du chapitre 8. Total: octets.

La somme des en-têtes vaut $20+20+14+4=58$ octets. C'est une constante, indépendante de la charge utile — et c'est de là que vient tout l'intérêt du calcul suivant.

Adressage

Une adresse IP

Le découpage en préfixe et hôte est ce qui rend le routage possible à l'échelle mondiale: un routeur lointain n'a pas besoin de connaître les machines d'un campus, seulement le préfixe qui les contient. Un réseau /24 réserve $24$ bits au préfixe et $8$ à l'hôte, soit $2^8=256$ adresses, dont $254$ utilisables (la première désigne le réseau lui-même, la dernière est l'adresse de diffusion).

L'épuisement d'IPv4

Les ports

Une adresse IP désigne une machine; elle ne dit pas quel programme de cette machine doit recevoir les octets. C'est le rôle du port, un entier de $16$ bits porté par l'en-tête de transport, donc $2^{16}=65536$ valeurs par protocole et par adresse. Les ports inférieurs à $1024$ sont dits réservés et affectés par convention aux services usuels: $80$ pour HTTP, $443$ pour HTTPS, $53$ pour le DNS, $22$ pour SSH.

Le quadruplet (adresse source, port source, adresse destination, port destination) identifie une connexion de façon unique. C'est lui, et non l'adresse seule, que TCP utilise pour ranger un segment arrivant dans la bonne connexion — ce qui permet à un navigateur d'ouvrir simultanément plusieurs connexions vers le même serveur, en changeant seulement son port source.

Le DNS, annuaire des noms

Personne ne retient 128.178.50.12. Le DNS (domain name system) est l'annuaire réparti qui traduit un nom en adresse. Sa structure est un arbre: à la racine les serveurs racine, en dessous les domaines de premier niveau (ch, org, com), en dessous les domaines délégués, et ainsi de suite. Chaque niveau ne connaît que le niveau suivant, et la délégation est le mécanisme qui permet à une organisation de gérer ses propres noms sans demander la permission à quiconque.

Traçons conceptuellement la résolution de www.exemple.ch par un résolveur qui ne sait rien:

1. le résolveur interroge un serveur racine: «qui gère ch?»; le serveur racine ne connaît pas www.exemple.ch, mais il renvoie l'adresse des serveurs de la zone ch;
2. le résolveur interroge un serveur de ch: «qui gère exemple.ch?»; réponse: l'adresse des serveurs faisant autorité pour exemple.ch;
3. le résolveur interroge un de ces serveurs: «quelle est l'adresse de www.exemple.ch?»; réponse: l'adresse cherchée, accompagnée d'une durée de vie (TTL) qui dit combien de temps la réponse peut être conservée;
4. le résolveur mémorise la réponse et la renvoie au client.

Trois échanges pour le résolveur, un seul pour le client. Mais la mise en cache change tout: si le résolveur a déjà vu exemple.ch récemment, l'étape 1 et souvent l'étape 2 disparaissent, et il ne reste qu'un aller-retour. Nous compterons plus loin ces allers-retours, parce qu'ils sont ce qui se voit.

Notez ce que la structure du DNS accomplit: elle transforme un problème mondial — «associer des milliards de noms à des adresses» — en une suite de questions locales, chacune posée à quelqu'un qui connaît la réponse ou sait à qui la poser. C'est le même principe que le routage, et pour la même raison: personne ne peut tout savoir.

Routage

La table de transmission

Un routeur ne connaît pas la route. Il connaît une table de transmission (forwarding table) qui associe à un préfixe d'adresse une interface de sortie, et son travail tient en trois gestes: lire l'adresse de destination du paquet, chercher dans la table le préfixe le plus long qui la contient, émettre le paquet sur l'interface correspondante. Puis il oublie le paquet.

C'est difficile à admettre la première fois: comment un paquet arrive-t-il, si personne ne sait où il va? La réponse est que chaque routeur sait dans quelle direction aller, ce qui est infiniment moins d'information que le trajet complet. Une table de quelques centaines de milliers de préfixes suffit à couvrir l'Internet, là où une table des routes complètes serait hors de portée.

Cette conception a trois conséquences immédiates.

• Le réseau n'a pas de mémoire de votre communication. Deux paquets successifs peuvent suivre deux chemins différents si une table change entre-temps; d'où le déséquencement.
• Une boucle est possible. Si deux routeurs se renvoient le paquet, il tourne indéfiniment. L'en-tête IP porte donc un champ TTL (time to live) sur $8$ bits, décrémenté à chaque saut et qui détruit le paquet à zéro: au plus $255$ sauts. Ce n'est pas une mesure de temps, c'est un compteur de sauts — le nom est un vestige.
• Le réseau ne promet rien. IP offre un service dit «au mieux» (best effort): il essaie, il ne garantit ni la livraison, ni l'ordre, ni le délai.

D'où viennent les tables

Elles sont construites automatiquement par des protocoles de routage, que ce cours nomme sans les développer — ils font l'objet d'un cours de réseaux à part entière.

• À l'intérieur d'un domaine administratif unique (un campus, un opérateur), les protocoles de passerelle intérieure (interior gateway protocols) calculent des routes de coût minimal. Deux familles: les protocoles à vecteur de distance, où chaque routeur annonce à ses voisins sa distance estimée à chaque destination, et les protocoles à état de liens, où chaque routeur diffuse l'état de ses propres liens et calcule ensuite localement un arbre de plus courts chemins — avec l'algorithme de Dijkstra du chapitre 4.
• Entre domaines administratifs, les protocoles de passerelle extérieure (exterior gateway protocols) forment une famille à vecteur de chemin, où l'on annonce le chemin complet des domaines traversés. Le critère n'y est plus le coût: il est politique (avec qui accepte-t-on d'échanger du trafic, et à quelles conditions commerciales). C'est une remarque importante pour l'ingénieur: la route qu'un paquet suit n'est pas la plus courte, elle est celle que des accords entre opérateurs autorisent.

Fiabilité: TCP

Le réseau perd, désordonne et retarde. Les applications, elles, veulent un tuyau d'octets qui arrivent tous, dans l'ordre, une seule fois. Rendre le premier à partir du second est le travail de TCP.

Acquittements, numéros de séquence, retransmission

Le point subtil est le délai d'expiration. Trop court, il provoque des retransmissions inutiles qui aggravent la congestion; trop long, il fait attendre pour rien. Or le bon délai dépend du temps d'aller-retour, qui varie sans cesse. TCP le mesure en continu et en maintient une estimation lissée, augmentée d'une marge proportionnelle à la variabilité observée. C'est un thème du chapitre: le réseau ne fournit aucune information sur lui-même, et tout ce que TCP sait, il l'a déduit de ses propres observations.

La fenêtre glissante et le produit débit-délai

Envoyer un segment, attendre son acquittement, envoyer le suivant: c'est correct et c'est catastrophique. Sur un aller-retour de $160$ ms, on émettrait au mieux un segment de $1460$ octets toutes les $160$ ms, soit $73$ kb/s, quelle que soit la capacité du lien.

D'où la fenêtre: l'émetteur envoie jusqu'à $W$ octets sans attendre, et n'attend que lorsque la fenêtre est pleine. Pour saturer le lien, il faut que la fenêtre couvre tout ce qui peut être «en vol».

Le contrôle de congestion

La fenêtre ci-dessus protège le récepteur d'être submergé. Elle ne protège pas le réseau, et c'est un problème différent: si tous les émetteurs envoient à pleine fenêtre, les files des routeurs débordent, les paquets se perdent, les retransmissions ajoutent du trafic, et le débit utile s'effondre au moment précis où l'on a le plus besoin de lui. Ce phénomène, l'effondrement par congestion (congestion collapse), a réellement eu lieu sur l'Internet dans les années 1980 et a motivé les mécanismes suivants.

Voici l'idée qu'il faut retenir de toute cette section, et elle est conceptuelle avant d'être technique.

Le prix de cette découverte se calcule. Repartons du chemin à $100$ Mb/s et $\mathrm{RTT}=160$ ms, dont le BDP vaut $2$ Mo. Si la connexion démarre avec une fenêtre de dix segments, soit $10\times 1460=14600$ octets, et qu'elle double à chaque aller-retour, il lui faut

allers-retours, soit $8\times 160=1280$ ms, avant même d'atteindre le débit du lien. Une connexion qui transfère moins que ce que le démarrage lent envoie pendant ce temps ne verra jamais les $100$ Mb/s annoncés. C'est pourquoi le coût d'ouverture d'une connexion n'est pas négligeable, et pourquoi les protocoles récents s'efforcent d'en ouvrir moins.

UDP, et quand le choisir

Dire qu'UDP est «TCP en moins bien» est un contresens. Les deux répondent à des besoins différents, et le critère de choix est net.

TCP est le bon choix quand l'intégralité des données importe plus que leur date d'arrivée: un fichier, une page, un courriel, une transaction. Un octet manquant rend le résultat faux, et il vaut mieux attendre.

UDP est le bon choix dans trois situations précises.

• Quand une donnée en retard est une donnée inutile. Dans une conversation vocale, retransmettre l'échantillon perdu il y a $300$ ms n'a aucun sens: il aurait dû être joué. Mieux vaut masquer le trou et continuer. La fiabilité de TCP serait ici nuisible, parce qu'un segment manquant bloque aussi la livraison de tous les segments suivants déjà arrivés — c'est le blocage de tête de file (head-of-line blocking).
• Quand l'échange tient en un aller-retour. Une requête DNS est une question courte et une réponse courte. Ouvrir une connexion TCP coûterait un aller-retour de plus que l'échange lui-même; on préfère envoyer un datagramme et réessayer s'il ne revient rien.
• Quand on veut construire sa propre fiabilité. C'est le choix de QUIC, sur lequel repose HTTP/3: il tourne sur UDP et réimplémente au-dessus le contrôle de flux, la retransmission et la sécurité, précisément pour pouvoir en changer sans toucher au système d'exploitation ni aux équipements du réseau.

Débit et latence

Nous arrivons au cœur du chapitre. Les deux grandeurs que le public confond sous le mot «vitesse» sont indépendantes, et leur confusion produit de mauvaises décisions techniques tous les jours.

Les quatre délais

Le temps qu'un paquet met à franchir un lien se décompose en quatre termes, et il est indispensable de les distinguer parce qu'ils ne dépendent pas des mêmes grandeurs.

Le point de confusion classique: $t_{\text{tx}}$ n'est pas le temps que le paquet met à arriver, et $t_{\text{prop}}$ n'est pas non plus ce temps. Le dernier bit arrive à l'instant $t_{\text{tx}}+t_{\text{prop}}$, et les deux termes se comportent différemment quand on change les paramètres. Doubler le débit divise par deux et ne touche pas à .

Le plancher imposé par la lumière

Dans une fibre optique, la lumière ne va pas à $c=3\cdot 10^8$ m/s mais à environ $v=2\cdot 10^8$ m/s, parce que l'indice de réfraction du verre vaut à peu près $1,5$. Calculons.

Lausanne–Zurich, à vol d'oiseau environ $200$ km:

soit $2,00$ ms pour l'aller-retour. C'est un plancher: la fibre réelle est plus longue que la ligne droite, elle passe par des points de raccordement, et chaque équipement traversé ajoute son délai. Aucune technologie, aucun abonnement, aucun investissement ne descendra en dessous de $1$ ms dans un sens.

Satellite géostationnaire, à $35786$ km d'altitude. Le signal monte et redescend, deux fois pour un aller-retour, et dans le vide à $c=3\cdot 10^8$ m/s:

Presque une demi-seconde, uniquement pour la géométrie. C'est la raison physique pour laquelle une liaison géostationnaire, même à très haut débit, rend une session interactive pénible — et la raison pour laquelle on construit des constellations en orbite basse, où l'altitude est cent fois moindre.

La figure 10.2 met en scène le mode de fonctionnement des routeurs: le stockage et retransmission (store-and-forward). Un routeur reçoit la trame entière, vérifie son CRC, puis seulement alors recommence à émettre. Il faut donc payer $t_{\text{tx}}$ sur chaque lien, et non une seule fois. Pour un paquet de $1500$ octets $=12000$ bits à $100$ Mb/s sur quatre liens de $50$ km:

Remarquez que le découpage en paquets est aussi ce qui rend le pipeline possible: pendant que le paquet $1$ franchit le second lien, le paquet $2$ peut déjà franchir le premier. Avec $N$ paquets et $K$ liens, le dernier bit arrive à l'instant $(N+K-1)t_{\text{tx}}+K{t}_{\text{prop}}$ — vérifié ici par simulation pas à pas: et donnent µs, c'est-à-dire seulement µs de plus que pour un seul paquet. Envoyer un fichier d'un bloc, sans le découper, perdrait cet effet entièrement.

La loi du transfert

Voici la relation que nous voulions établir, et le reste du chapitre en dépend.

Démonstration. La formule (10.3) exprime simplement que le temps est la somme d'un terme constant et du temps d'émission $8S/D$ — le facteur $8$ convertissant les octets en bits. En remplaçant $D$ par $2D$ dans (10.3), on obtient $T_{2D}(S)=L+4S/D$, d'où et la formule (10.4). En posant , on a , fonction strictement croissante de , nulle en et de limite quand ; elle ne l'atteint pour aucun fini puisque .

Le rôle de $S^{\ast }$ est plus précis qu'une frontière commode. En reportant (10.5) dans (10.4):

À la taille de bascule, doubler le débit fait gagner exactement $25\%$ du temps total — jamais $50\%$. Le repère est donc quantitatif et non qualitatif.

La figure 10.3 dit visuellement ce que le tableau dit numériquement. Sur des axes logarithmiques, la formule (10.3) donne deux courbes qui partent d'une asymptote horizontale commune — le plancher de latence — et finissent en deux droites parallèles décalées de ${\log }_2$ d'un facteur deux. Tout le contenu du chapitre est dans la position du coude.

Utilisez l'explorateur pour vérifier le théorème 10.1 à la main. Mettez la taille à $0,05$ Mo et la distance à $10000$ km: la barre est presque entièrement claire, et déplacer le curseur de débit de $1$ à $200$ Mb/s ne raccourcit presque rien. Puis mettez la taille à $50$ Mo: la barre devient presque entièrement colorée et le gain du doublement s'approche de $50\%$ sans jamais l'atteindre. Le readout «taille de bascule» est celui qu'il faut regarder: il donne, pour chaque chemin, la taille à partir de laquelle il devient rationnel de payer pour du débit.

Le web, de bout en bout

Rassemblons tout. Que se passe-t-il entre le moment où vous tapez une adresse et celui où la page s'affiche? Nous allons compter les allers-retours, parce que c'est la compétence utile: elle permet d'estimer un temps d'affichage sans rien mesurer.

Les cinq étapes

1. Résolution du nom. Le navigateur demande au résolveur DNS l'adresse associée au nom. Si le résolveur a la réponse en cache, c'est un aller-retour; sinon, il faut y ajouter les interrogations successives des serveurs racine, du domaine de premier niveau et du serveur faisant autorité, soit jusqu'à trois allers-retours de plus.
2. Établissement de la connexion TCP. La poignée de main en trois temps (three-way handshake): le client envoie SYN, le serveur répond SYN-ACK, le client répond ACK. Le troisième message peut déjà porter des données, si bien que le coût avant de pouvoir émettre est d'un aller-retour.
3. Négociation TLS. C'est ici que le chapitre 9 entre en scène: le client et le serveur établissent un secret partagé par un échange de clés de type Diffie-Hellman, le serveur prouve son identité par un certificat signé, et les deux dérivent les clés symétriques qui chiffreront la suite. En TLS 1.3, cela coûte un aller-retour; les versions antérieures en coûtaient deux.
4. Requête HTTP. Le navigateur envoie sa requête et attend la réponse: un aller-retour avant le premier octet utile.
5. Réception. Les octets de la page arrivent ensuite au débit du chemin, modulo le démarrage lent de TCP — et la page elle-même en déclenche d'autres, pour les images, les feuilles de style et les scripts.

Ce qu'on fait pour réduire le compte

Le nombre d'allers-retours étant le terme dominant, tout l'effort porte sur lui.

• Réutiliser la connexion. HTTP/1.1 puis HTTP/2 conservent la connexion TCP ouverte et y font passer plusieurs requêtes: les étapes 2 et 3 ne sont payées qu'une fois. HTTP/2 va plus loin en multiplexant plusieurs échanges sur la même connexion, ce qui évite d'en ouvrir plusieurs — et donc de payer plusieurs démarrages lents.
• Fusionner les poignées de main. QUIC, qui tourne sur UDP, combine l'établissement de la connexion et la négociation cryptographique en un seul aller-retour, et permet même, lors d'une reprise avec un serveur déjà rencontré, d'envoyer des données dès le premier paquet. Le compte tombe de quatre allers-retours à trois, voire à deux.
• Rapprocher le contenu. Répliquer les fichiers sur des serveurs proches des usagers réduit $d$, donc $L$, donc les quatre termes à la fois. C'est la seule optimisation qui agisse sur la physique plutôt que sur le protocole.
• Envoyer moins. Le chapitre 7 revient ici: comprimer une page divise son temps d'émission, et supprimer une requête supprime un aller-retour entier. Sur un petit fichier, supprimer la requête vaut bien plus que comprimer le contenu.

Fin du parcours: représenter, calculer, transmettre

Ce chapitre clôt le cours, et il vaut la peine de regarder d'où l'on vient.

Tout est bits (chapitre 1). Le premier chapitre a montré qu'une machine ne manipule que des suites de symboles binaires, et que toute autre chose — un entier négatif, un réel, une lettre accentuée, une image, un son — n'existe qu'à travers une convention de représentation choisie par quelqu'un. Ce chapitre-ci n'a rien fait d'autre: une adresse IP est une convention sur $32$ ou $128$ bits, un numéro de port sur $16$ bits, un en-tête est un accord sur l'emplacement de chaque champ. Et la même leçon revient sous la même forme: quand une convention est trop courte, elle finit par déborder — le $0,1$ non représentable du chapitre 1 et l'épuisement d'IPv4 sont deux instances du même phénomène, un espace fini que l'on croyait vaste.

Ce qui se calcule, et à quel prix (chapitres 2 à 5). Les chapitres sur la complexité ont appris à compter les opérations avant de les exécuter, et le chapitre 5 a montré qu'il existe des questions auxquelles aucun programme ne répond. Le routage en est l'application discrète: calculer un plus court chemin est facile (Dijkstra, chapitre 4), et pourtant on ne le fait pas à l'échelle mondiale, parce que le coût n'est pas celui du calcul mais celui de rassembler l'information. La leçon du chapitre 2 se prolonge ici: une solution qui exige de tout savoir n'est pas une solution, aussi rapide soit son algorithme.

Combien de bits suffisent, combien il faut en rajouter (chapitres 6 à 8). Le chapitre 6 a fixé un plancher — l'entropie —, le chapitre 7 a montré comment s'en approcher, le chapitre 8 comment payer de la redondance pour survivre au bruit. Ce chapitre a ajouté une troisième sorte de bits, que ni Shannon ni Hamming ne comptent: les bits d'adressage et de coordination. Les $58$ octets d'en-têtes de la figure 10.1 ne portent ni information au sens du chapitre 6, ni protection au sens du chapitre 8: ils portent l'organisation. Et ils sont, eux aussi, mesurables — $3,82\%$ sur un gros message, $98,3\%$ sur un petit.

Le faire en sécurité (chapitre 9). Le réseau est public par construction. Tout ce que le chapitre 9 a construit — le secret partagé sur un canal ouvert, la signature, le certificat — ne prend son sens que sur un canal que n'importe qui peut écouter. Chiffrer un fichier sur son propre disque est une commodité; chiffrer une session qui traverse vingt équipements appartenant à dix organisations est une nécessité.

Et la question directrice du cours — combien de bits, combien d'opérations, combien de temps? — reçoit ici sa troisième réponse. Les bits, ce sont la charge utile plus les en-têtes. Les opérations, ce sont celles des routeurs, et elles sont délibérément peu nombreuses parce qu'il faut les faire des milliards de fois par seconde. Le temps, enfin, n'est pas ce que l'intuition suggère: il est dominé, pour presque tout ce que vous faites avec un réseau, non par le débit qu'on vous vend mais par la distance et le nombre d'allers-retours.

Ce qui continue ce cours. Un cours de réseaux reprend chacune des sections ci-dessus sur un semestre: contrôle d'accès au support, algorithmes de routage et leur convergence, analyse des files d'attente, qualité de service. Un cours de systèmes d'exploitation explique ce qui se passe entre la carte réseau et le programme. Un cours de systèmes distribués pose la question que ce chapitre a soigneusement contournée: que peut-on garantir quand plusieurs machines doivent se mettre d'accord alors que les messages se perdent et que les horloges dérivent? Un cours de sécurité des systèmes montre ce que la cryptographie du chapitre 9 ne protège pas. Sur cette plateforme, Algorithmes approfondit les chapitres 2 à 4 et Introduction à la programmation apprend à écrire ce que ce cours s'est contenté de décrire.

Aucun d'eux ne remplacera ce que vous avez maintenant: la capacité de répondre, devant un système que vous n'avez jamais vu, aux trois questions «combien de bits, combien d'opérations, combien de temps», et de reconnaître, quand quelqu'un promet mieux, s'il propose une meilleure ingénierie ou s'il vend une impossibilité.

Synthèse

• La commutation de paquets a gagné parce que le trafic est sporadique: sur un lien de $1$ Mb/s, dix usagers en commutation de circuits contre trente-cinq en commutation de paquets, avec une saturation $4,2\cdot 10^{-4}$ du temps. Le prix en est le délai variable, la perte et le déséquencement — et la fiabilité a donc été repoussée aux extrémités.
• L'encapsulation coûte une constante, pas un pourcentage: $20$ octets TCP, $20$ octets IPv4, $14+4$ octets Ethernet, soit $58$ octets. Cela fait $3,82\%$ d'un segment plein de octets et d'un message d'un octet. Un réseau n'est efficace que sur de gros messages.

Exercices

Vous pouvez afficher le corrigé directement sous chaque énoncé après avoir cherché la solution.

Références

• Kurose, J. F. & Ross, K. W., Computer Networking: A Top-Down Approach, Pearson. La référence de premier cycle pour ce chapitre; les chapitres sur la couche transport et la couche réseau couvrent tout ce qui précède avec plus de détail.
• Tanenbaum, A. S. & Wetherall, D. J., Computer Networks, Pearson. Présentation par couches, de la physique à l'application, avec une attention particulière aux couches basses.
• Peterson, L. L. & Davie, B. S., Computer Networks: A Systems Approach, Morgan Kaufmann. Édition librement accessible en ligne; excellente sur le contrôle de congestion.
• Les RFC de l'IETF, librement accessibles: RFC 791 (IPv4), RFC 8200 (IPv6), RFC 9293 (TCP), RFC 768 (UDP), RFC 1034 et 1035 (DNS), RFC 8446 (TLS 1.3), RFC 9000 (QUIC).
• Saltzer, J. H., Reed, D. P. & Clark, D. D., «End-to-End Arguments in System Design», ACM Transactions on Computer Systems, 1984. L'article qui énonce le principe de bout en bout invoqué dans ce chapitre.
• Polycopiés du cours ICC de l'EPFL.