Quand vous diagnostiquez une dégradation ou une coupure réseau, vous avez besoin de mesurer la performance réseau et d’identifier quand le réseau rame et pour quelle raison (saturation de la bande passante, congestion, défaut de configuration, défaut d’un équipement réseau – switch ou routeur).
Quelle que soit votre approche (capture de trafic avec un analyseur réseau tel que Wireshark, du polling SNMP avec des outils tels que PRTG ou Cacti, ou des tests actifs avec SmokePing ou un simple ping ou traceroute), vous avez besoin d’indicateurs de la performance réseau! On les nomme habituellement métriques et elles permettent de disposer de données chiffrées pour refléter la performance réseau.
3 indicateurs majeurs de performance réseau
Cet article explique la réalité sous-jacente de 3 indicateurs majeurs de performance réseau et comment ils interagissent pour des flux TCP et UDP.
- Latence réseau : c’est le temps nécessaire pour véhiculer un paquet au travers d’un réseau.
- La latence peut être mesurée de plusieurs façons : aller-retour (round trip), unilatérale (one way), etc…
- La latence est impactée par tout élément dans la chaîne utilisée pour transporter les données : station cliente, liens WAN, routeurs, LAN / réseau local, serveur et en dernier ressort, elle est limitée pour les très grands réseaux par la vitesse de la lumière
- Débit réseau : il est défini par la quantité de données envoyées et reçues par unité de temps.
- Perte de paquets : il s’agit du nombre de paquets perdus par rapport à 100 paquets émis par un hôte sur le réseau.
Ces mesures peuvent vous aider à comprendre les mécanismes d’un ralentissement réseau.
Le débit d’un flux n’est pas impacté par la latence réseau
Le protocole UDP est utilisé pour transporter des données sur des réseaux IP. Un des principes de l’UDP est qu’il fait l’hypothèse que tous les paquets émis sont effectivement reçus par l’autre partie (ou les contrôles de la bonne réception et l’éventuelle ré-émission sont gérés à un autre niveau, par exemple, par l’application elle-même).
En théorie ou pour certains protocoles spécifiques (où aucun contrôle n’est effectué à un autre niveau, par exemple, pour des transmissions uni-directionnelles), la vitesse à laquelle les paquets sont envoyés par l’émetteur ne sont pas impactés par le temps nécessaire pour atteindre l’autre partie (ce qui correspond à la latence réseau). Quel que soit ce temps, l’émetteur enverra un certain nombre de paquets par seconde, qui dépend de d’autres facteurs (i.e., application, système d’exploitation, ressources systèmes, etc.).
Pourquoi le débit TCP est directement impacté par la latence
Le TCP est un protocole plus complexe qui intègre un mécanisme qui vérifie que chaque paquet est correctement reçu. Ce mécanisme est nommé acquittement : il consiste, pour le destinataire, à envoyer un paquet spécifique ou à indiquer à l’émetteur la bonne réception de chaque paquet.
Pour des raisons d’efficacité, on n’acquittera pas chaque paquet un par un : l’émetteur n’attend pas l’acquittement du paquet précédent pour envoyer les paquets suivants. En fait, le nombre de paquets qui peuvent être envoyés avant de recevoir l’acquittement correspondant est géré par une valeur appelée « fenêtre de congestion TCP » (TCP Congestion Window).
Si nous faisons l’hypothèse qu’aucun paquet n’est perdu : l’émetteur enverra un premier quota de paquets (correspondant à la fenêtre de congestion TCP) et quand il recevra le paquet d’acquittement, il augmentera la valeur de la fenêtre de congestion ; progressivement le nombre de paquets qui peuvent être envoyés sur une période données augmentera (débit). Le délai jusqu’à ce que le paquet d’acquittement soit reçu (correspondant à la latence) aura donc un impact sur la rapidité à laquelle la fenêtre de congestion TCP augmentera (et donc sur le rythme auquel le débit s’accroira).
Quand la latence est élevée, cela signifie que l’émetteur passe plus de temps en attente (sans envoyer de nouveaux paquets) ce qui réduit la vitesse à laquelle le débit s’accroit.
Les valeurs de test (source : http://smutz.us/techtips/NetworkLatency.html) sont très explicites :
Pourquoi les flux TCP sont impactés par les retransmissions et les pertes de paquets
Le mécanisme de la fenêtre de congestion TCP gère les paquets d’acquittement manquants de la façon suivante : si un paquet d’acquittement est manquant après une période de temps donnée, le paquet sera considéré comme perdu et la fenêtre de congestion sera réduite de moitié (par conséquence le débit sera également réduit de moitié, ce qui répond à la perception par l’émetteur de capacité limitée ou de saturation sur la route) ; le fenêtre de congestion TCP recommencera à augmenter si les paquets d’acquittement sont ensuite reçus correctement.
La perte de paquets aura deux effets sur la vitesse de transmission des données :
- Les paquets devront être retransmis (même si le paquet d’acquittement a été perdu et les paquets de données sont correctement livrés)
- La fenêtre de congestion TCP ne permettra pas un débit optimal
Ceci est corroboré par les mesures suivantes :
Ceci s’appliquera quelle que soit la raison de la perte des paquets d’acquittement (i.e., véritable congestion réseau, problème sur le serveur, application de shaping ou de priorisation).
Source : accedian.com/fr/blog-fr/