Modèle en couches, commutation de paquets, adressage IP et routage, fiabilité de TCP, débit et latence, du navigateur au serveur.
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.
Définition 10.1 · réseau de communication
Un réseau de communication est un ensemble de machines (hôtes, hosts) reliées par des liens physiques et par des équipements d'aiguillage (commutateurs et routeurs, switches et routers), muni d'un ensemble de règles — les protocoles — qui fixent le format des messages échangés et la suite d'actions que chaque partie doit accomplir.
Un protocole n'est pas un programme: c'est une convention. Deux implémentations écrites dans deux langages différents, par deux équipes qui ne se sont jamais parlé, interopèrent si et seulement si elles respectent la même convention.
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.
Question 10.1
Un opérateur double la capacité d'un lien en commutation de circuits, sans changer le débit réservé par usager. Qu'obtient-il?
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.
Couche
Rôle
Unité
Exemples
Adresse utilisée
Application
ce que l'usager veut faire
message
HTTP, DNS, SMTP
nom de domaine
Transport
de processus à processus, fiable ou non
segment / datagramme
TCP, UDP
numéro de port
Réseau
d'hôte à hôte à travers le monde
paquet
IP
adresse IP
Liaison
d'un équipement au suivant sur le même lien
trame
Ethernet, Wi-Fi
adresse MAC
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.
Application.1460 octets de texte HTTP.
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.
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.
Liaison. Ethernet préfixe 14 octets (adresse MAC destination, adresse MAC source, type) et ajoute en fin de trame 4 octets de FCS (frame check sequence), qui est un CRC sur 32 bits — celui du chapitre 8. Total: 1518 octets.
Figure 10.1. Encapsulation d'un segment HTTP de 1460 octets. En descendant la pile, le message gagne un en-tête TCP de 20 octets, un en-tête IP de 20 octets, puis un en-tête Ethernet de 14 octets et une remorque FCS de 4 octets; en remontant, chaque couche retire le sien (cellule en pointillé). Les cellules d'en-tête sont dessinées à largeur fixe pour pouvoir porter leur étiquette: la vraie proportion, 58 octets sur 1518, est donnée par la barre du bas, elle proportionnelle.
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.
Question 10.2
Une charge utile de 100 octets est encapsulée dans TCP (20 o), IPv4 (20 o) et Ethernet (14+4 o). Quelle est la surcharge, en pourcentage de la trame transmise?
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 28=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 216=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:
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;
le résolveur interroge un serveur de ch: «qui gère exemple.ch?»; réponse: l'adresse des serveurs faisant autorité pour exemple.ch;
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;
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.
Question 10.3
Une adresse IPv6 fait 128 bits au lieu de 32. De combien l'espace d'adressage est-il multiplié?
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.
Question 10.4
Remettez dans l'ordre les opérations qu'un routeur effectue sur un paquet IP entrant.
Glissez les éléments pour les mettre dans le bon ordre
1.
Chercher dans la table de transmission le préfixe le plus long qui contient cette adresse
2.
Réencapsuler le paquet dans une nouvelle trame et l'émettre vers le saut suivant
3.
Décrémenter la durée de vie et détruire le paquet si elle atteint zéro
4.
Lire l'adresse de destination dans l'en-tête IP
5.
Recevoir la trame et vérifier son CRC, puis en retirer l'en-tête de liaison
6.
Placer le paquet dans la file d'attente de l'interface de sortie choisie
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 RTT=160 ms, dont le BDP vaut 2 Mo. Si la connexion démarre avec une fenêtre de dix segments, soit 10×1460=14600 octets, et qu'elle double à chaque aller-retour, il lui faut
⌈log2146002000000⌉=⌈7,10⌉=8
allers-retours, soit 8×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.
Question 10.5
Sur un chemin de temps d'aller-retour 160 ms, une connexion TCP annonce la fenêtre maximale d'un champ de 16 bits, soit 65535 octets. Quel débit peut-elle atteindre au plus, en Mb/s?
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: ttx n'est pas le temps que le paquet met à arriver, et tprop n'est pas non plus ce temps. Le dernier bit arrive à l'instant ttx+tprop, et les deux termes se comportent différemment quand on change les paramètres. Doubler le débit divise ttx par deux et ne touche pas à tprop.
Le plancher imposé par la lumière
Dans une fibre optique, la lumière ne va pas à c=3⋅108 m/s mais à environ v=2⋅108 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:
tprop=2⋅108m/s2,00⋅105m=1,00⋅10−3s=1,00ms,
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⋅108 m/s:
RTTmin=3⋅1084×3,5786⋅107=0,477s=477ms.
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.
Figure 10.2. Traversée de trois routeurs, donc quatre liens de 50 km à 100 Mb/s, par un paquet de 1500 octets. Le temps court vers la droite, les nœuds sont empilés vers le bas: un paquet est donc un parallélogramme dont la largeur horizontale est le temps d'émission (120 µs, segment épais sur la ligne de l'émetteur) et dont la pente porte le temps de propagation (250 µs). Chaque routeur attend le dernier bit avant de réémettre: le total vaut 4 × (120 + 250) = 1480 µs.
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 ttx 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:
ttx=10812000=120μs,tprop=2⋅1085⋅104=250μs,
T=4×(120+250)=1480μs=1,48ms.
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)ttx+Ktprop — vérifié ici par simulation pas à pas: N=3 et K=4 donnent 6×120+4×250=1720 µs, c'est-à-dire seulement 240 µ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 T2D(S)=L+4S/D, d'où TD(S)−T2D(S)=4S/D et la formule (10.4). En posant u=8S/D≥0, on a g=L+uu/2=21⋅L+uu, fonction strictement croissante de u, nulle en u=0 et de limite 21 quand u→+∞; elle ne l'atteint pour aucun u fini puisque L>0. □
Le rôle de S∗ est plus précis qu'une frontière commode. En reportant (10.5) dans (10.4):
g(S∗)=L+8S∗/D4S∗/D=L+LL/2=41.
À 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.
Figure 10.3. Temps total de transfert en fonction de la taille du fichier, pour 10 Mb/s (trait épais) et 20 Mb/s (trait fin), sur un chemin de latence 160 ms. Les deux axes sont logarithmiques. À gauche de la taille de bascule S* = 200 ko, les deux courbes se confondent sur le plancher de latence: le débit n'y commande rien. À droite, elles sont deux droites parallèles séparées d'un facteur deux constant. Les deux courbes sont échantillonnées depuis la formule T = 0,160 s + 8S/D.
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 log2 d'un facteur deux. Tout le contenu du chapitre est dans la position du coude.
Explorateur 10.1 · Explorateur: débit et latence ne se remplacent pas
Modèle simplifié et déclaré comme tel: un aller-retour de latence (2d/v avec v = 2·10⁸ m/s dans la fibre), puis l'émission du fichier au débit nominal; files d'attente, pertes et démarrage lent de TCP sont négligés, donc le résultat est un plancher, pas une prédiction. La barre du haut est le temps au débit choisi, celle du bas au débit doublé; la partie claire est la latence, la partie en couleur l'émission. Prenez un fichier de 0,05 Mo à 10 000 km: doubler le débit ne gagne presque rien. Passez à 50 Mo: le gain approche 50 %. Le readout «taille de bascule S*» donne la frontière entre les deux régimes — c'est la taille pour laquelle l'émission dure exactement aussi longtemps que la latence, et pour laquelle le doublement gagne exactement 25 %.
Distance d (km)8 000
Débit D (Mb/s)20
Taille du fichier S (Mo)0,50
Latence (aller-retour)
80,0 ms
Temps d'émission au débit D
200,0 ms
Temps total au débit D
280,0 ms
Temps total au débit 2D
180,0 ms
Gain apporté par le doublement
35,71 %
Taille de bascule S* = D·L/8
200,0 ko
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.
Question 10.6
Sur un chemin de latence 160 ms, le temps de téléchargement d'un fichier de 1 ko passe de 160,8 ms à 160,4 ms quand on double le débit. Quelle est la bonne conclusion?
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
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.
É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.
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.
Requête HTTP. Le navigateur envoie sa requête et attend la réponse: un aller-retour avant le premier octet utile.
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⋅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 1460 octets et 98,3% d'un message d'un octet. Un réseau n'est efficace que sur de gros messages.
Les espaces d'adressage se comparent par le calcul: 232≈4,3⋅109 contre 2128≈3,4⋅1038, soit un rapport . Un port fait bits, donc valeurs; le DNS résout les noms par délégation, chaque niveau ne connaissant que le suivant.
Aucun routeur ne connaît la route. Chacun choisit le prochain saut par recherche du préfixe le plus long, et la route est la composition de décisions locales; le champ TTL sur 8 bits borne les boucles à 255 sauts. Les tables sont construites par des protocoles à vecteur de distance, à état de liens ou à vecteur de chemin.
TCP découvre la capacité du chemin au lieu de la connaître: acquittements, numéros de séquence, retransmission sur expiration, fenêtre glissante, puis augmentation additive et diminution multiplicative. Une fenêtre de 65535 octets plafonne le débit à 3,28 Mb/s sur un aller-retour de 160 ms, contre 262 Mb/s sur 2 ms. UDP est le bon choix quand une donnée en retard est inutile ou quand l'échange tient en un aller-retour.
Le temps d'un transfert vaut T=L+8S/D: doubler le débit gagne 0,25% sur 1 ko et 49,99% sur 1 Go, exactement 25% à la taille de bascule S∗=DL/8, et jamais . Le plancher de latence se calcule: ms pour Lausanne–Zurich à l'aller, ms d'aller-retour par satellite géostationnaire. Plus de débit ne réduit pas la latence; seules la distance et le nombre d'allers-retours le font, et un chargement de page en coûte quatre.
Série d'exercices du chapitre 10Exercice 1 sur 5
Question 10.7
Une charge utile de 40 octets est encapsulée dans TCP, IPv4 et Ethernet (58 octets d'en-têtes au total). Quelle est la surcharge, en pourcentage de la trame?
Problème guidé 10.1 · Télécharger un fichier de cinq mégaoctets
Vous téléchargez un fichier de S=5 Mo depuis un serveur situé à d=3000 km, sur un chemin de débit utile D=50 Mb/s. Le signal se propage dans la fibre à v=2⋅108 m/s. On néglige les files d'attente, les pertes et le démarrage lent de TCP, et l'on compte un aller-retour de latence avant que les données ne commencent à arriver. Vous allez décomposer le temps total, puis décider si un abonnement deux fois plus rapide en vaut la peine.
1
La latence
La latence à compter est un aller-retour, c'est-à-dire deux fois la distance divisée par la vitesse de propagation.
Question
Calculez la latence d'aller-retour, en millisecondes.
Le temps d'émission
Le total, et le gain d'un doublement
La taille de bascule
Exercices
Vous pouvez afficher le corrigé directement sous chaque énoncé après avoir cherché la solution.
Exercice 10.1 · Encapsulation et surcharge
Les en-têtes valent 20 octets pour TCP, 20 pour IPv4, 40 pour IPv6, et 14+4 pour Ethernet. La MTU d'Ethernet est de 1500 octets.
Calculez la surcharge, en pourcentage de la trame, pour des charges utiles de 20, 512 et 1460 octets en IPv4.
Quelle est la charge utile maximale (MSS) en IPv4? en IPv6? Calculez la surcharge d'une trame pleine dans les deux cas.
Un fichier de 10 Mo est transmis en segments TCP pleins. Combien de paquets faut-il, quelle est la taille du dernier, et combien d'octets circulent au total sur le câble?
Solution
1. Les en-têtes totalisent 20+20+14+4=58 octets, indépendamment de la charge utile ℓ, et la surcharge vaut σ(ℓ)=58/(ℓ+58):
Exercice 10.2 · Adressage, sous-réseaux et ordres de grandeur
Combien d'adresses contient un réseau /26? Combien sont attribuables à des machines? Combien de réseaux /26 tient-on dans un /24?
On distribue des adresses IPv4 au rythme d'un million par seconde. Combien de temps faut-il pour épuiser 232 adresses? Refaites le calcul pour 2128 et comparez à l'âge de l'univers, de l'ordre de 1,4⋅1010 ans.
Pourquoi la traduction d'adresses (NAT) n'est-elle pas une solution à l'épuisement d'IPv4, mais seulement un report?
Solution
1. Un /26 réserve 26 bits au préfixe, donc 32−26=6 bits à l'hôte: 26=64 adresses, dont 62 attribuables (la première désigne le réseau, la dernière est l'adresse de diffusion). Un /24 contient 226−24=4 réseaux . Notez la mécanique générale: chaque bit ajouté au préfixe la taille du réseau et le nombre de sous-réseaux.
Exercice 10.3 · Traversée de routeurs et pipeline
Un paquet de 1500 octets traverse trois routeurs, donc quatre liens identiques de 50 km à 100 Mb/s. Le signal se propage à 2⋅108 m/s et les routeurs fonctionnent en stockage et retransmission. On néglige l'attente et le traitement.
Calculez ttx, tprop et le temps total d'acheminement d'un paquet.
On envoie maintenant trois paquets à la suite. À quel instant le dernier bit du troisième arrive-t-il? Établissez la formule générale pour N paquets et K liens.
Quel serait le total si l'on envoyait les 4500 octets en un seul paquet (en supposant la MTU assez grande)? Commentez.
Exercice 10.4 · Fenêtre, produit débit-délai et démarrage lent
Un chemin a un temps d'aller-retour de 30 ms. Le MSS vaut 1460 octets.
Calculez le produit débit-délai pour D=100 Mb/s puis D=1 Gb/s, en octets.
Une connexion annonce la fenêtre maximale d'un champ de 16 bits, soit 65535 octets. Quel débit atteint-elle au plus? Comparez au BDP à 1 Gb/s.
Le démarrage lent part d'une fenêtre de dix segments et la double à chaque aller-retour. Combien d'allers-retours faut-il pour atteindre le BDP à 1 Gb/s, et combien de temps cela représente-t-il? Combien d'octets ont été transférés pendant ce temps?
Solution
1.BDP=D×RTT, en bits, que l'on divise par 8:
D=108b/s:8108×0,030=375000 octets=0,375 Mo;
Exercice 10.5 · Compter les allers-retours d'une page
Une page de 2 Mo est chargée depuis un serveur situé à 16000 km, sur un chemin de 100 Mb/s. Le cache DNS est chaud et la session utilise TLS 1.3. On compte un aller-retour pour le DNS, un pour la poignée de main TCP, un pour TLS et un pour la requête HTTP.
Calculez le temps d'aller-retour, le temps avant le premier octet utile, puis le temps total.
Quelle fraction du total les allers-retours représentent-ils? Que gagne-t-on en passant le débit à 1 Gb/s?
On réplique la page sur un serveur à 200 km. Que devient le total? Comparez les deux optimisations et concluez.
La même page est chargée par satellite géostationnaire (aller-retour de 477 ms) à 100 Mb/s. Commentez.
Solution
1. Aller-retour: RTT=2×1,6⋅107/2⋅108=0,160 s =160 ms. Quatre allers-retours avant le premier octet utile:
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.
2
168 ms
164 ms
2,38%
100 ko
240 ms
200 ms
16,67%
200 ko =S∗
320 ms
240 ms
25,00%
1 Mo
960 ms
560 ms
41,67%
10 Mo
8,16 s
4,16 s
49,02%
100 Mo
80,16 s
40,16 s
49,90%
1 Go
800,16 s
400,16 s
49,99%
Plus la latence est grande, plus il faut de gros fichiers pour que le débit compte.
1,91 s
0,168
un gain de 79%, à débit inchangé
296≈7,9⋅1028
16
65536
50%
1
477
ℓ
trame
surcharge
20 o
78 o
74,36%
512 o
570 o
10,18%
1460 o
1518 o
3,82%
La surcharge décroît comme 1/ℓ pour ℓ grand: elle est divisée par vingt quand la charge utile est multipliée par soixante-treize.
2. La MTU limite le paquet IP, en-tête compris. En IPv4, MSS=1500−20−20=1460 octets, et la trame fait 1460+58=1518 octets, de surcharge 58/1518=3,82%. En IPv6, l'en-tête réseau fait 40 octets, donc MSS=1500−40−20=1440 octets; la trame fait toujours 1518 octets mais les en-têtes en occupent 78, soit 78/1518=5,14%. On paye 1,32 point de pourcentage pour quatre fois plus d'adresses.
3.10 Mo =107 octets. Le nombre de paquets vaut ⌈107/1460⌉=6850: les 6849 premiers portent 1460 octets, le dernier
107−6849×1460=460 octets.
Vérification: 6849×1460+460=107. Sur le câble circulent
6849×1518+(460+58)=10397300 octets,
soit une surcharge de 397300/10397300=3,82% de ce qui circule, ou 3,97% de plus que la charge utile. (Ces deux pourcentages différents décrivent la même chose et se confondent souvent: le premier rapporte la surcharge au total transmis, le second à la charge utile.)
/26
divise par deux
double
2. À 106 adresses par seconde,
106232=4295 s≈1 h 12 min.
Pour IPv6,
1062128=3,40⋅1032 s=1,08⋅1025 ans,
soit environ 7,7⋅1014 fois l'âge de l'univers. La leçon n'est pas qu'IPv6 est «très grand» mais que l'exponentielle est une autre échelle: 96 bits de plus ne sont pas 96 fois plus, ils sont 296 fois plus. C'est le même argument qui, au chapitre 9, sépare une clé de 128 bits d'une clé de 256 bits.
3. Le NAT ne crée aucune adresse: il multiplexe plusieurs machines derrière une seule adresse publique en réécrivant les ports. Trois limites. D'abord, le nombre de ports est fini (65536 par protocole et par adresse), donc le facteur de multiplexage est borné. Ensuite, les machines internes ne sont plus adressables depuis l'extérieur: toute application de pair à pair doit contourner le problème par des mécanismes ad hoc. Enfin, le routeur doit maintenir un état par connexion — exactement ce que la commutation de paquets avait éliminé —, et cet état se perd lorsqu'il redémarre. Le NAT achète du temps en abandonnant le principe de bout en bout; il ne résout pas la pénurie, il la rend supportable.
En stockage et retransmission, chaque lien coûte la somme des deux, car le routeur attend le dernier bit avant de réémettre:
T=4×(120+250)=1480μs=1,48ms.
2. Pendant que le paquet 1 franchit le lien 2, le paquet 2 peut franchir le lien 1: les émissions se recouvrent. Le premier lien est occupé de 0 à 360 µs par les trois émissions successives, si bien que le troisième paquet part avec 2ttx=240 µs de retard sur le premier et subit ensuite exactement le même trajet. D'où
T3=1480+2×120=1720μs.
En général, le dernier paquet attend (N−1)ttx avant de partir, puis met K(ttx+tprop):
T(N,K)=(N+K−1)ttx+Ktprop.
Vérification par simulation pas à pas des dates d'émission et d'arrivée: N=3, K=4 donne 6×120+4×250=1720 µs, et N=10 donne 13×120+1000=2560 µs. Le coût marginal d'un paquet supplémentaire n'est que de ttx=120 µs: le pipeline amortit la propagation.
3. Un unique paquet de 4500 octets =36000 bits donne ttx=360 µs, donc
T=4×(360+250)=2440μs,
nettement plus que les 1720 µs obtenus avec trois paquets. La raison est que le gros paquet paye son temps d'émission quatre fois, une par lien, sans recouvrement possible, alors que le découpage permet de superposer l'émission sur un lien et la propagation sur un autre. C'est un argument pour découper qui s'ajoute à celui de la perte (retransmettre un petit paquet coûte moins cher) — et qui doit être mis en balance avec la surcharge d'en-têtes de l'exercice 10.1: trois paquets payent trois fois 58 octets.
D=109b/s:8109×0,030=3750000 octets=3,75 Mo.
2. La fenêtre est vidée et rechargée une fois par aller-retour, donc
Dmax=0,03065535×8=1,7476⋅107b/s=17,48Mb/s.
Sur un lien à 1 Gb/s, on n'utiliserait que 1,75% de la capacité. Le rapport au BDP le dit autrement: 65535/3750000=1,75% — c'est le même nombre, et ce n'est pas une coïncidence, puisque le débit atteint est W/RTT et le débit possible BDP/RTT. Sans l'option d'extension de fenêtre, un lien rapide et long est inutilisable par une seule connexion.
3. La fenêtre initiale vaut 10×1460=14600 octets et double à chaque aller-retour: 14600, 29200, 58400, 116800, 233600, 467200, 934400, 1868800, 3737600. Il faut donc
⌈log2146003750000⌉=⌈8,005⌉=9
allers-retours, soit 9×30=270 ms. Pendant ces neuf allers-retours, l'émetteur a envoyé la somme des neuf fenêtres, soit 14600(29−1)=14600×511=7460600 octets, environ 7,46 Mo. Un transfert plus petit que cela ne verra jamais le gigabit annoncé: il se sera terminé avant la fin du démarrage lent. C'est la version dynamique de la taille de bascule, et elle pousse dans le même sens.
4×0,160=0,640s.
Émission de la page: 8×2⋅106/108=0,160 s. Total:
T=0,640+0,160=0,800s.
2. Les allers-retours représentent 0,640/0,800=80% du total. En passant à 1 Gb/s, le temps d'émission tombe à 0,016 s et le total à 0,656 s: un gain de
0,8000,800−0,656=18,0%,
pour un débit multiplié par dix. Le terme de latence, lui, n'a pas bougé d'une microseconde.
3. À 200 km, RTT=2 ms et les quatre allers-retours coûtent 8 ms. À 100 Mb/s inchangés, le total devient
T=0,008+0,160=0,168s,
soit un gain de (0,800−0,168)/0,800=79,0%à débit constant. Conclusion: sur cette page, rapprocher le serveur vaut quatre fois plus que multiplier le débit par dix. C'est le contenu du théorème 10.1 appliqué à un cas réaliste, et c'est la raison d'être de la réplication géographique du contenu. On remarquera aussi qu'après rapprochement, la situation s'est inversée: le terme dominant est devenu l'émission (160 ms contre 8), et c'est maintenant que payer pour du débit deviendrait rentable. La bonne optimisation dépend du régime dans lequel on se trouve, et il faut donc commencer par le déterminer.
4. Les quatre allers-retours coûtent 4×0,477=1,909 s, auxquels s'ajoutent 0,160 s d'émission: T=2,07 s, dont 92% de latence. Augmenter le débit ne sert pratiquement à rien; supprimer un aller-retour en fait gagner 477 ms, soit trois fois plus que le passage de 100 Mb/s à l'infini. C'est pourquoi un lien satellitaire géostationnaire supporte bien un téléchargement de gros fichier et mal une session interactive — et pourquoi les constellations en orbite basse, où l'altitude est cent fois moindre, changent la nature du problème au lieu de l'améliorer marginalement.