Performance réseau¶

Bande passante, latence, MTU et QoS — les grandeurs qui conditionnent la performance des systèmes distribués.

Les trois mesures du débit¶

On confond souvent bande passante, débit et goodput. Ces trois termes désignent des choses différentes, et cette confusion mene a des erreurs de dimensionnement.

Bande passante (bandwidth) : la capacité maximale théorique du lien. Un lien 10 Gbps peut transporter 10 milliards de bits par seconde dans des conditions idéales. C'est une caractéristique du medium physique.

Débit (throughput) : la quantite de données effectivement transmise par unite de temps. Le débit est toujours inférieur à la bande passante — il tient compte des en-têtes protocolaires, des retransmissions, de la congestion et des pauses du contrôle de flux.

Goodput : la quantite de données utiles (payload applicatif) reçue par l'application destinataire par unite de temps. Le goodput exclut les en-têtes, les retransmissions, les paquets de contrôle. C'est le chiffre qui compte pour l'application.

Sur un lien 1 Gbps, avec TCP/IPv4 sur Ethernet, le goodput maximal théorique est d'environ 94% de la bande passante (overhead des en-têtes). En pratique, avec la congestion, les pertes et les retransmissions, le goodput réel peut être bien inférieur.

Latence : les quatre composantes¶

La latence est le temps que met un paquet pour aller d'un point A à un point B. Elle se decompose en quatre composantes :

Latence de propagation¶

Le temps que met le signal pour traverser le medium physique. La lumiere parcourt environ 200 000 km/s dans la fibre optique (2/3 de la vitesse dans le vide). Pour un trajet Paris-New York (6000 km de fibre), la latence de propagation est d'environ 30 ms dans chaque direction.

Cette latence est incompressible. Aucune technologie ne peut la réduire — c'est une contrainte physique fondamentale. C'est pourquoi les CDN et les architectures multi-region existent : on rapproche le calcul de l'utilisateur plutôt que d'essayer d'accélérer la lumiere.

Latence de serialisation¶

Le temps nécessaire pour placer tous les bits d'un paquet sur le medium. Un paquet de 1500 octets (12000 bits) sur un lien 1 Gbps prend 12 microsecondes. Sur un lien 100 Mbps, il prend 120 microsecondes.

La serialisation est negligeable sur les liens rapides mais significative sur les liens lents (WAN, liaisons satellites). Elle explique aussi pourquoi les jumbo frames (MTU 9000) ont un coût de serialisation plus élevé par paquet — mais un coût total plus faible pour un même volume de données, car il y a moins de paquets a traiter.

Latence de mise en file d'attente (queuing)¶

Quand un routeur reçoit plus de paquets qu'il ne peut en transmettre, les paquets s'accumulent dans une file d'attente (buffer). Le temps passe dans cette file est la latence de queuing. Elle est variable et imprévisible — c'est la composante qui cause le jitter.

Les routeurs ont des buffers finis. Quand le buffer est plein, les paquets sont jetes (tail drop). Les algorithmes de gestion de file comme RED (Random Early Détection) ou CoDel (Controlled Delay) jettent des paquets avant que le buffer soit plein pour signaler la congestion a TCP.

Latence de traitement¶

Le temps que le routeur met pour examiner l'en-tête du paquet, consulter sa table de routage, et décider ou envoyer le paquet. Sur les routeurs modernes avec ASIC dédiés, cette latence est de l'ordre de la microseconde. Sur des routeurs logiciels (iptables, software-defined networking), elle peut être de l'ordre de la dizaine de microsecondes.

Latence par distance¶

Ces chiffres sont des RTT (aller-retour). La latence one-way est la moitie. Un appel API inter-region a 30 ms de RTT coute au minimum 30 ms — et chaque échange supplémentaire (TLS handshake, redirections) ajoute un RTT.

Jitter¶

Le jitter est la variation de la latence entre paquets consecutifs. Un lien avec 50 ms de latence moyenne et 5 ms de jitter signifie que les paquets arrivent entre 45 ms et 55 ms.

Le jitter est particulièrement problematique pour :

• VoIP et visioconference : les jitter buffers compensent, mais au prix de la latence
• Streaming : les buffers de lecture absorbent le jitter, mais augmentent le délai initial
• Protocoles de synchronisation : NTP et PTP sont sensibles au jitter

Un lien avec une latence élevée mais stable (fibre sous-marine) est souvent preferable a un lien avec une latence faible mais un jitter important (4G en mouvement).

Mesurer le jitter¶

Le jitter se mesure avec ping (ecart-type du RTT), mtr (colonne StDev), ou avec des outils dédiés comme smokeping qui visualise la distribution de latence sur la durée. Un jitter supérieur à 10% du RTT moyen merite investigation.

En interne dans un datacenter, le jitter devrait être inférieur à 0.1 ms. Un jitter plus élevé indique de la congestion sur un lien ou un équipement réseau sature. Sur Internet, un jitter de 5-20 ms est normal — les applications doivent l'absorber avec des buffers ou des mécanismes de compensation.

MTU et fragmentation¶

Le MTU (Maximum Transmission Unit) est la taille maximale d'un paquet que le lien peut transporter sans fragmentation. Le MTU standard Ethernet est de 1500 octets.

Le problème de la fragmentation¶

Quand un paquet IP est plus grand que le MTU du prochain lien, deux choses peuvent se produire :

1. Fragmentation IP : le routeur découpé le paquet en fragments plus petits. Le destinataire reassemble. C'est coûteux en CPU et en mémoire, et un fragment perdu oblige à retransmettre tout le paquet.

2. Don't Fragment (DF) flag : le paquet est marque DF. Le routeur ne peut pas fragmenter — il jette le paquet et renvoie un ICMP "Fragmentation Needed". C'est le mécanisme utilisé par Path MTU Discovery.

Path MTU Discovery (PMTUD)¶

PMTUD détermine le MTU maximal utilisable sur le chemin complet entre source et destination. L'émetteur envoie des paquets avec le flag DF. Si un routeur sur le chemin a un MTU inférieur, il renvoie un ICMP avec le MTU du lien. L'émetteur réduit la taille de ses paquets.

Le problème : les firewalls bloquent souvent les messages ICMP, ce qui casse PMTUD. Les paquets trop gros sont jetes silencieusement — un "trou noir MTU". Les symptomes sont insidieux : les petites requêtes fonctionnent, les grosses réponses sont perdues. Un ping -s 1472 -M do <destination> (Linux) teste le PMTUD en envoyant un paquet de taille maximale avec le flag DF.

MSS Clamping¶

Quand PMTUD est casse (ICMP bloque), une alternative est le MSS clamping. Le routeur ou le firewall modifie le champ MSS (Maximum Segment Size) dans le SYN TCP pour que les segments ne depassent pas le MTU du lien le plus restrictif. C'est une solution pragmatique déployée sur la plupart des tunnels VPN et des liens PPPoE (DSL).

Jumbo frames¶

Les jumbo frames augmentent le MTU a 9000 octets (ou plus). Le gain : moins d'overhead protocolaire par octet de données, moins d'interruptions CPU (moins de paquets a traiter pour le même volume). Sur les transferts massifs intra-datacenter (réplication de base de données, backup), les jumbo frames peuvent augmenter le débit de 10 a 30%.

La contrainte : tous les équipements sur le chemin doivent supporter le même MTU. Un seul switch avec un MTU de 1500 sur le chemin provoque de la fragmentation ou des pertes.

Congestion¶

La congestion apparait quand le volume de trafic dépassé la capacité d'un lien ou d'un routeur. Les paquets s'accumulent dans les buffers, la latence augmente, et quand les buffers debordent, les paquets sont jetes.

Ou la congestion se produit¶

Le comportement de TCP face à la congestion¶

TCP interprété la perte de paquets comme un signal de congestion et réduit son débit (\(\text{cwnd} \mathbin{/}= 2\) pour fast recovery, \(\text{cwnd} = 1\) pour timeout). Ce mécanisme est efficace mais a deux défauts :

1. TCP sous-utilise les liens à haute bande passante et forte latence (liens long-haul) : après une perte, la fenêtre de congestion met du temps a remonter. Le produit bandwidth-delay product (\(\text{BDP} = \text{bande passante} \times \text{RTT}\)) donne le volume de données qui devrait être en vol pour saturer le lien. Sur un lien 10 Gbps a 100 ms de RTT, le BDP est de 125 MB — il faut 125 MB en vol pour utiliser toute la bande passante. Remonter à ce niveau après une perte prend des minutes avec CUBIC.

2. TCP est equitable entre les flux, pas entre les applications : une application qui ouvre 10 connexions TCP obtient 10x plus de bande passante qu'une application avec une seule connexion. C'est pourquoi les navigateurs ouvraient 6 connexions par domaine en HTTP/1.1.

QoS — Quality of Service¶

La QoS permet de prioriser certains types de trafic par rapport à d'autres quand le réseau est congestionne. Sans QoS, tous les paquets sont traites de manière identique (best-effort).

DiffServ¶

DiffServ (Differentiated Services) est le modèle de QoS dominant. Il utilise le champ DSCP (6 bits) de l'en-tête IP pour marquer les paquets avec une classe de service. Les routeurs appliquent un traitement différent selon la classe :

Traffic shaping¶

Le traffic shaping lisse le trafic pour éviter les pics de congestion. Les deux algorithmes classiques :

• Token bucket : les paquets ne sont transmis que si un jeton est disponible. Les jetons sont ajoutes à un rythme constant. Le burst est limite par la taille du seau. Permet des pics contrôles.
• Leaky bucket : les paquets arrivent dans un seau et sont transmis à un rythme constant. Lisse complètement le trafic — aucun pic.

Le bandwidth-delay product¶

Le BDP (bandwidth-delay product) est la quantite de données "en vol" dans le réseau à un instant donne. C'est le produit de la bande passante par le RTT :

Pour utiliser toute la bande passante, TCP doit maintenir au moins un BDP de données en vol (fenêtre de congestion >= BDP). Sur les liens à forte latence, la fenêtre TCP par défaut (typiquement 64 KB dans les anciennes implémentations) est très insuffisante. Les parametres tcp_rmem et tcp_wmem de Linux doivent être ajustes pour les transferts long-haul.

Mesurer la performance réseau¶

Les outils de mesure sont indispensables pour valider les hypothèses de dimensionnement et diagnostiquer les problèmes.

Les outils essentiels¶

Ce qu'il faut mesurer en production¶

Les métriques réseau a surveiller en continu :

• RTT p50 / p99 entre les services critiques : une dégradation du p99 sans changement du p50 indique du jitter ou de la congestion intermittente
• Taux de retransmission TCP : au-delà de 0.1%, la performance se dégradé visiblement. Au-delà de 1%, c'est un problème urgent
• Connexions en TIME_WAIT et CLOSE_WAIT : une accumulation signale un problème de gestion des connexions
• Débit entrant/sortant par interface : détecter la saturation avant qu'elle ne cause des pertes

La règle des 10x¶

En architecture distribuée, on observe souvent la règle des 10x pour la dégradation de performance à travers le réseau :

Chaque fois qu'on remplacé un appel local par un appel réseau, on paye un facteur 1000x a 1000000x. C'est le coût réel du découpage en microservices — et c'est pourquoi les frontieres de services doivent être choisies avec soin.

Impact pour l'architecte¶

La latence, pas la bande passante, est le goulot : pour la plupart des applications web, la bande passante est suffisante (les requêtes HTTP font quelques KB). C'est la latence — amplifiee par le nombre d'allers-retours — qui domine. Réduire le nombre de round-trips (batching, prefetching, HTTP/2 multiplexing) a plus d'impact que doubler la bande passante.

Latence x nombre de sauts : une architecture microservices avec 10 appels séquentiels inter-services a 0.5 ms de RTT chacun ajoute 5 ms de latence incompressible. Avec des appels entre regions (30 ms de RTT), c'est 300 ms — inacceptable pour une requête utilisateur. La topologie des appels est une décision architecturale.

MTU et tunnels : dans un environnement containerise (Kubernetes, overlay networks), vérifier le MTU effectif est un prérequis. Un PMTUD casse provoque des timeouts intermittents que TCP masque par des retransmissions — la latence p99 explose sans explication apparente.

Dimensionnement : le BDP détermine la taille des buffers TCP nécessaires. Les parametres par défaut du noyau sont souvent insuffisants pour les transferts inter-regions. Un sysctl net.ipv4.tcp_wmem mal configuré peut limiter le débit a une fraction de la bande passante disponible.

Sursouscription : les switches d'accès sont presque toujours sursouscris — 48 ports 1 Gbps avec un seul uplink 10 Gbps donnent un ratio de sursouscription de 4.8:1. Cela signifie que si tous les serveurs du rack communiquent simultanément vers l'extérieur, seuls 20% du trafic passe. En pratique, les patterns de trafic sont rarement aussi extremes, mais les pics de trafic (réplication, backup, déploiement) peuvent saturer les uplinks. Les architectures leaf-spine modernes reduisent la sursouscription en multipliant les liens entre les couches.

Tail latency : la latence p99 ou p999 est souvent 10 a 100 fois plus élevée que la latence mediane. Un appel réseau avec 1 ms de latence mediane peut avoir 50 ms de latence p99 à cause du jitter, de la congestion intermittente, ou de la retransmission d'un paquet perdu. Quand une requête utilisateur fan-out vers 20 services en parallèle, la latence totale est determinee par le plus lent — et la probabilite de tomber sur un p99 augmente avec le nombre de services. C'est la "latency amplification" décrite par Jeff Dean.

Chapitre suivant : Impact sur les architectures distribuees — les fallacies of distributed computing et leurs conséquences concrètes.