Les effets de la latence et de la perte de paquets sur la performance réseau

Comme nous le savons, les métriques primordiales de la performance du réseau sont la latence, la perte de paquets et la gigue. Nous allons maintenant examiner plus en détail comment ces métriques, en particulier la latence et la perte de paquets, détermine la performance des applications.

Presque toutes les applications utilisent le protocole TCP (Transmission Control Protocol), afin que leurs données puissent arriver du point A au point B ; en effet, 85% du trafic Internet est TCP. Un aspect intéressant du protocole TCP est qu’il masque complètement le
caractère basé sur les paquets du réseau des applications. Qu’une application transmette un seul caractère à TCP de temps en temps (comme Telnet ou SSH) ou vide un fichier de plusieurs mégabytes aussi vite qu’elle le peut (FTP), ou n’importe quoi entre les deux, TCP prend les données en les encapsulant dans des paquets et les envoie ensuite sur le réseau. L’Internet est souvent un endroit effrayant pour les paquets qui essaient de trouver leur chemin : il n’est pas rare que des paquets se perdent et n’arrivent jamais à la destination, ou même arrivent dans un ordre différent de celui de leur transmission. Le protocole TCP retransmet les paquets perdus et remet les données dans l’ordre d’origine si nécessaire avant de transmettre les données au récepteur. Les applications n’ont alors pas à s’inquiéter.

La latence
Les premiers protocoles réseau étaient souvent conçus afin de fonctionner sur des réseaux locaux (LAN) ou des réseaux de campus, où les paquets peuvent voyager d’un bout à l’autre du réseau en quelques millisecondes. Ces protocoles pourtant, n’arrivaient pas à fonctionner toujours aussi bien sur l’Internet, où cela peut prendre un dixième de seconde pour un paquet de faire le tour du monde avant d’atteindre sa destination. Et si on souhaite également d’avoir un retour du paquet, alors ce nombre double à 200 millisecondes. Après tout, la vitesse des impulsions de lumière dans la fibre optique est de 200 000 km ou 124 000 miles par seconde, donc le RTT est d’une milliseconde pour 100 km / 62 mil.

La théorie des files d’attente – Queueing theory (ou un voyage au bureau de poste >>> TO BE DELETED) nous dit que plus un lien est occupé, plus les paquets doivent attendre. Par exemple, un lien 10 Gbps qui fonctionne à 8 Gbps (80 % d’utilisation) nous dit qu’en moyenne, lorsqu’un paquet arrive, il y en a déjà quatre autres en attente. À 99 % d’utilisation, cette file d’attente atteindra 99 paquets. À l’époque où les liens étaient beaucoup plus lents que de nos jours, cela pouvait ajouter une considérable quantité de latence supplémentaire, mais dans le cas d’un lien 10 Gbps, transmettant 99 paquets d’une moyenne de 500 octets peut prendre seulement 0,248 milliseconde. Ainsi, actuellement, la mise en mémoire tampon des routeurs au cœur du réseau ne rajoute pas un délai significatif à moins que les liens ne soient massivement surutilisés – disons une utilisation de 99,9 % ou plus.

Cependant, le protocole TCP dispose de plusieurs mécanismes afin d’obtenir une bonne performance même avec des niveaux de latence élevés. Le mécanisme principal est de s’assurer qu’on a suffisamment de paquets, qui sont conservés “in flight”. Le simple fait d’envoyer un paquet et d’attendre que l’autre partie dise “je l’ai reçu, envoie-le, ensuite envoie le suivant” ne suffit pas; cela pourra limiter le débit à cinq paquets par seconde sur un chemin avec un RTT de 200 ms. TCP essaie donc de s’assurer qu’il envoie suffisamment de paquets pour remplir le lien, mais pas au point de saturer le lien ou le chemin. Cela fonctionne bien pour les transferts de données de longue durée, tels que les
téléchargements.

Cela ne fonctionne pas aussi bien pour les transferts de données plus petits, car pour s’assurer qu’il ne submerge pas le réseau, TCP utilise un mécanisme, dénommé “slow start”. Dans le cas d’un long téléchargement, la partie “slow start” n’est qu’une fraction du temps total, pendant que pour des transferts courts, au moment où TCP atteint sa vitesse, le transfert est déjà terminé. Et puisque TCP doit attendre les accusés de réception du destinataire, plus de latence signifie plus de temps passé en démarrage lent (slow start). Auparavant, la performance des navigateurs Web était souvent limitée par un démarrage lent, mais les navigateurs ont commencé à réutiliser les sessions TCP qui n’avaient déjà plus de démarrage lent pour télécharger des images supplémentaires et d’autres éléments plutôt que de continuer à ouvrir de nouvelles sessions TCP. Cependant, les applications écrites par des développeurs de logiciels ayant moins d’expérience en réseau peuvent utiliser de simples séquences “open-transfer-close-open-transfer-close” qui fonctionnent bien sur les réseaux avec une latence faible mais qui ralentissent beaucoup sur de plus grandes distances. (Ou sur des réseaux à bande passante limitée, qui ajoutent également une
latence supplémentaire.)

Évidemment, presque toutes les connexions TCP sont précédées d’une recherche DNS. Alors, si la latence vers le serveur DNS est considérable, cela ralentit encore plus tout le processus décrit précédemment. On recommande donc d’utiliser un serveur DNS à proximité.

La perte des paquets
Idéalement, on n’aura jamais un seul paquet dans un réseau. Évidemment, dans le monde réel, les choses ne sont pas si idéales et c’est pour deux raisons.
Chaque support de transmission peut basculer un peu de temps en temps, après quoi le paquet entier est perdu. (Un réseau Wi-Fi envoie généralement des bits de correction d’erreur supplémentaires, mais ceux-ci ne peuvent pas faire grand-chose.)

Si une telle erreur survient, le paquet perdu doit être retransmis, ce qui peut retarder un transfert. Par exemple, on envoie des données à une vitesse de 1 000 paquets par seconde sur une connexion RTT de 200 ms. Cela signifie que lorsque l’expéditeur envoie le paquet 500, les paquets 401 à 499 sont toujours “in flight” et donc le destinataire vient d’envoyer un accusé de réception pour le paquet 400. Cependant, les accusés de réception des paquets 301 à 399 sont “in flight” dans l’autre sens, donc le dernier acquittement vu par l’expéditeur est le 300. Et alors, si le paquet 500 est perdu, l’expéditeur ne le remarquera pas jusqu’au moment qu’il voie l’accusé de réception 499 suivi de 501. À ce moment-là, il transmet le paquet 700. Ainsi, le destinataire verra les paquets 499, 501 – 700, 500, puis 701 et en avant. Cela signifie que le récepteur doit mettre en mémoire tampon les paquets 501 – 700 pendant qu’il attend le paquet 500. Il ne faut pas oublier que fournir toutes les données dans le bon ordre – c’est le devoir sacré du protocole TCP.

D’habitude, ce qui est mentionné ci-dessus n’est pose pas vraiment de problème. Mais si la latence du réseau ou la perte de paquets devient trop élevées, TCP manquera d’espace tampon et donc le transfert doit s’arrêter jusqu’à ce que le paquet perdu retransmis ait été reçu. Autrement dit: une latence élevée ou une perte élevée n’est pas optimale, mais cela reste exploitable ; tandis qu’une latence élevée accompagnée d’une perte élevée peuvent ensemble considérablement ralentir TCP.

Cependant, les choses s’aggravent. La deuxième raison pour laquelle les paquets peuvent être perdus est que le protocole TCP envoie les paquets si vite, et la mémoire tampon du routeur/commutateur se remplit plus vite, que les paquets ne peuvent plus être transmis.
Lorsque la mémoire tampon est pleine mais qu’un autre paquet arrive, le routeur ou le commutateur ne peut faire qu’une seule chose: “abandonner” le paquet. Et parce que TCP ne peut pas faire la différence entre un paquet perdu à cause d’un bit inversé ou à cause d’un débordement de la mémoire tampon dans le réseau, il assumera tout simplement qu’il s’agit de ce dernier cas de figure, et ralentira. Dans l’exemple ci-dessus, ce ralentissement n’est pas trop sévère, car les paquets suivants continuent d’être reconnus, ce qui permet à
TCP d’utiliser le mécanisme “fast retransmit”.

Pourtant, la retransmission rapide ne fonctionne pas si l’un des trois derniers paquets d’un transfert est perdu. Dans cette situation, TCP ne peut pas faire la différence entre un seul paquet perdu ou lorsque le réseau est massivement surchargé et aucun paquet ne peut passer. Alors maintenant, TCP laissera son compte à rebours jusqu’à zéro, ce qui prend souvent une seconde, puis essaie de tout recommencer, en mode “slow start”. Ce problème coupe souvent les sessions Web, qui ont tendance à être courtes – où une page prend quelques secondes pour se charger complètement, même si la plupart du contenu apparaît rapidement.

Une autre raison pour laquelle TCP se retrouve dans une situation de délai d’attente est s’il y a trop de paquets en peu de temps. À ce moment, TCP détermine que le réseau ne peut supporter que des vitesses de transfert de données très modérées ; un démarrage lent est
alors justifié. Souvent, dans ce cas, il est plus rapide d’arrêter un téléchargement et de le redémarrer plutôt que d’attendre le redressement de TCP.

La Gigue (Jitter)
La gigue n’est rien d’autre que la différence entre la latence d’un paquet à l’autre. Évidemment, la vitesse de la lumière n’est pas sujet à changement, et les fibres ont tendance à rester de la même longueur. Ainsi, la latence est généralement causée par la mise en mémoire tampon des paquets dans les routeurs et les commutateurs qui terminent les liaisons très utilisées. (Surtout sur des liaisons à une bande passante faible, telles que les liens à large bande ou ceux 3G/4G.) Parfois, un paquet a de la chance et peut passer plus rapidement, mais on a aussi des situations où la file d’attente est plus longue que d’habitude. Pour TCP, ce n’est pas un grand problème, même si cela signifie que TCP doit utiliser une valeur prudente pour estimer son RTT et que les délais d’attente prendront plus de temps que d’habitude. Cependant, pour le trafic audio et vidéo en temps réel (non TCP), la gigue est bien problématique, car les données l’audio/vidéo doivent être lues à un rythme
stable. Cela signifie que l’application doit soit mettre en mémoire tampon les paquets “rapides” et attendre les paquets lents (ce qui peut rajouter un délai perceptible pour l’utilisateur), soit les paquets lents doivent être considérés comme perdus, provoquant des “dropouts”.

En conclusion, pour les réseaux qui utilisent plusieurs connexions Internet, cela peut s’avérer être bien avantageux d’éviter les chemins beaucoup plus longs et donc d’avoir une latence plus élevée que les chemins alternatifs ou ceux congestionnés vers la même destination,
mais avec une perte de paquets élevée.

Chez Noction, nous avons réussi à automatiser complètement le processus de sélection du meilleur chemin. Jetez un coup d’œil à notre plate-forme de routage intelligent – Intelligent Routing Platform , pour voir comment elle évalue les métriques de performance (la perte de paquets et la latence) sur plusieurs fournisseurs afin de choisir la meilleure route.

Accéder à la version anglaise de cet article – Network latency and packet loss effects on performance