Il s’agit d’une question commune à tous ceux qui fournissent des applications critiques sur des réseaux publics et longue distance. Sur quelle métrique dois-je me concentrer pour maximiser la vitesse de transfert des données qui permettent l’accès aux applications cloudifiées ?
Performances réseau : le débit est ce qui compte le plus pour l’expérience utilisateur
Si vous vous mettez à la place d’un utilisateur qui se connecte à une application, ce qui compte, c’est la rapidité avec laquelle votre application apparaît et la rapidité avec laquelle vous pouvez interagir avec elle. Ce qui compte du point de vue de l’expérience utilisateur :
- la rapidité avec laquelle vous établissez votre connexion avec les serveurs qui fournissent les différentes ressources
- la vitesse à laquelle vous les chargez.
Du point de vue de l’utilisateur, la performance du réseau est une question de débit !
Comment mesurer le débit ?
Première clarification, beaucoup de gens confondent débit et bande passante. Bien que ces deux concepts soient liés, ils mesurent deux choses différentes.
- Tout d’abord, le débit est la vitesse à laquelle deux équipements transfèrent effectivement des données de l’un à l’autre.
- Deuxièmement, la bande passante correspond à la quantité maximale de données pouvant être transférées sur une liaison.
Nous utilisons la même unité pour les deux mesures : les bits ou les octets par seconde.
Si le débit peut être mesuré facilement, il est assez difficile de déterminer si ce débit représente la vitesse maximale qu’un utilisateur peut obtenir. Très souvent, les exploitants réseau examinent les facteurs de débit pour identifier les goulots d’étranglement potentiels.
Qu’est-ce qui détermine le débit ?
En cas de dégradation ou de panne du réseau, le débit chute. La surveillance des performances du réseau est indispensable pour identifier les moments où le réseau est lent et la cause profonde.
Quels que soient les outils que vous utilisez (analyseur de paquets comme Wireshark, polling SNMP avec PRTG ou Cacti, charge du trafic, tests actifs), vous avez besoin d’indicateurs qui vous aideront à comprendre si vos utilisateurs peuvent tirer le meilleur parti de l’infrastructure réseau pour transférer des données.
Cet article explique 3 mesures clés de la performance des réseaux (latence, débit et perte de paquets), comment elles influencent la vitesse de transfert en fonction du protocole utilisé (UDP ou TCP).
- La latence est le temps nécessaire pour transmettre un paquet sur un réseau :
- Il existe différentes façons de mesurer la latence : aller-retour, aller simple, etc.
- Tout élément sur le chemin utilisé pour transmettre les données peut avoir un impact sur la latence : équipement de l’utilisateur final, liaisons réseau, routeurs, serveurs proxy, réseau local (LAN), serveur de destination,…
- La limite ultime de la latence sur les grands réseaux est… la vitesse de la lumière.
Si vous souhaitez en savoir plus sur la latence et les différentes façons de la mesurer, je vous recommande de jeter un coup d’œil à cet article.
- Le débit est la quantité de données envoyées/reçues par unité de temps.
- La perte de paquets est le nombre de paquets perdus pour 100 paquets envoyés par un hôte.
Maintenant que nous avons défini chacun d’entre eux, voyons comment ils interagissent les uns avec les autres.
Comprendre l’impact de la latence et de la perte de paquets sur le débit
Cela peut vous aider à comprendre les mécanismes des ralentissements du réseau.
Le protocole utilisé pour la communication aura un impact sur la façon dont les choses fonctionnent, nous devons donc effectuer une analyse différenciée pour UDP et pour TCP.
Mesure des performances du réseau sur UDP
La latence n’a aucun impact sur le débit en UDP.
Lorsque nous utilisons UDP, nous supposons que tous les paquets envoyés sont reçus par l’autre partie (le contrôle de la transmission est exécuté à une couche différente, souvent l’application elle-même).
En théorie ou pour certains protocoles spécifiques (si aucun contrôle n’est entrepris à une couche différente ; par exemple, les transmissions unidirectionnelles), la vitesse à laquelle les paquets peuvent être envoyés par l’expéditeur n’est pas influencée par le temps nécessaire pour livrer les paquets à l’autre partie (= latence). L’expéditeur enverra un nombre donné de paquets par seconde, qui dépend d’autres facteurs (application, système d’exploitation, ressources, …).
En conclusion, la latence n’a aucun impact sur le débit en UDP.
Mesure des performances du réseau sur TCP
La latence a un impact direct sur le débit du TCP.
TCP est un protocole plus sophistiqué : il implique un contrôle de transmission qui vérifie la bonne livraison de tous les paquets. Ce mécanisme s’appelle l’acquittement (“acknowledgement” en anglais) : le récepteur répond à l’expéditeur avec un paquet ou un drapeau spécifique pour confirmer la bonne réception de chaque paquet.
Fenêtre de congestion TCP
Par souci d’optimisation, tous les paquets ne seront pas acquittés un par un ; l’expéditeur n’attend pas chaque acquittement avant d’envoyer de nouveaux paquets. En effet, le nombre de paquets qui peuvent être envoyés avant de recevoir le paquet d’accusé de réception correspondant est géré par une valeur appelée fenêtre de congestion TCP.
L’impact de la fenêtre de congestion TCP sur le débit
Si nous faisons l’hypothèse qu’aucun paquet ne se perd, l’expéditeur enverra le premier ensemble de paquets (correspondant à la fenêtre de congestion TCP) et lorsqu’il recevra le paquet d’accusé de réception (ou acquittement), il augmentera la fenêtre de congestion TCP ; progressivement, le nombre de paquets pouvant être envoyés dans une période de temps donnée augmentera (ainsi que le débit)
Le délai avant la réception des paquets d’accusé de réception (= latence) aura un impact sur la vitesse à laquelle la fenêtre de congestion TCP augmente (donc le débit).
Lorsque la latence est élevée, cela signifie que l’expéditeur passe plus de temps à ne rien faire (ne pas envoyer de nouveaux paquets), ce qui réduit la vitesse de croissance du débit.
Les valeurs du test sont très explicites :
| Latence aller-retour | Débit TCP |
| 0ms | 93.5 Mbps |
| 30ms | 16.2 Mbps |
| 60ms | 8.07 Mbps |
| 90ms | 5.32 Mbps |
La retransmission et la perte de paquets ont un impact sur le débit de TCP.
Comment la congestion TCP gère les paquets d’acquittement manquants.
Le mécanisme de fenêtre de congestion TCP gère les paquets d’acquittement manquants de la manière suivante : si un paquet d’acquittement manque à l’appel après un certain temps, le paquet est considéré comme perdu et la fenêtre de congestion TCP est réduite de moitié (comme le débit – ce qui correspond à la perception d’une capacité limitée sur la route par l’expéditeur) ; la taille de la fenêtre de congestion TCP peut alors recommencer à augmenter si le client ou le serveur a bien reçu les paquets d’acquittement.
La perte de paquets aura deux effets sur la vitesse de transmission des données :
- Les paquets doivent être retransmis (même si seul le paquet d’accusé de réception a été perdu et que les paquets ont été livrés).
- La taille de la fenêtre de congestion TCP ne permet pas d’obtenir un débit optimal.
À titre d’exemple, avec 2 % de perte de paquets, le débit TCP est entre 6 et 25 fois plus faible qu’en l’absence de perte de paquets.
| Latence aller-retour | TCP Débit TCP sans perte de paquets Latence aller-retour | Débit TCP avec 2% de perte de paquets |
| 0 ms | 93.5 Mbps | 3.72 Mbps |
| 30 ms | 16.2 Mbps | 1.63 Mbps |
| 60 ms | 8.7 Mbps | 1.33 Mbps |
| 90 ms | 5.32 Mbps | 0.85 Mbps |
Cela s’appliquera quelle que soit la raison de la perte des paquets d’accusé de réception (c.-à-d. congestion réelle, problème de serveur, mise en forme des paquets, etc.)
En conclusion, si vous surveillez les performances du réseau pour optimiser l’expérience de l’utilisateur, vous devez vous concentrer sur les taux de perte de paquets.
