RTT réseau – C’est quoi ? Comment l’analyser avec Wireshark ?

I. Présentation

Dans cet article, nous allons aborder la notion de RTT réseau et la latence des réseaux, qui sont deux notions importantes quand il est question de performance des réseaux et des applications.

Cet article est découpé en deux grandes parties :

• Une partie théorique
• Une partie pratique avec Wireshark

D'ailleurs, retrouvez tous les articles sur l'utilisation et la configuration de Wireshark sur cette page :

• Tutoriels Wireshark sur IT-Connect
• Téléchargement - Wireshark

II. Sur un réseau, qu'est-ce que la latence ?

A. Qu’est-ce que la latence ?

La latence est le temps que met un paquet pour aller d’un point A vers un point B, elle se mesure en millisecondes (ms). Autrement dit, c'est le temps qu'il faut pour qu'une donnée (comme une requête ou une réponse) soit envoyée, transmise à travers le réseau, et reçue à destination.

Elle est influencée par plusieurs facteurs, dont la distance physique, la qualité des équipements réseau, le support de connexion (fibre optique, liaison sans-fil, etc.) et la congestion du réseau.

B. Qu’est-ce que le Round Trip Time ?

Le Round Trip Time que l'on appellera RTT, est le temps d’aller/retour d’un paquet sur le réseau. Il représente le temps qu'il faut pour qu'un paquet de données soit envoyé depuis un point A, atteigne un point B (la destination), et que la réponse revienne de B à A (l'acquittement).

Le RTT est influencé par différents facteurs, au même titre que la latence, et nous en parlerons dans la suite de cet article. Les notions de RTT réseau et latence du réseau sont extrêmement importantes dans le cadre de la performance des réseaux.

III. Comment est calculée le RTT réseau ?

A. Le RTT réseau initial

Le RTT réseau est calculé en premier par la demande de connexion TCP qui permet d’établir une connexion à un service comme un serveur web, par exemple.

Le calcul du RTT réseau se fait entre la demande de connexion « SYN » et « SYN ACK » quand la capture est prise côté client. Si votre capture est prise côté serveur, celle-ci se calcule entre le « SYN ACK » envoyé et la réception du « ACK ».

B. Suivi du RTT réseau

Le RTT réseau est calculé avec les acquittements TCP, car ceux-ci n’ont aucune charge applicative dans les paquets, cela permet de voir la variation du RTT réseau pour une application donnée.

Ce calcul du RTT réseau est utilisé par des sondes de performance de type NPMd (Network Performance Monitoring et Diagnostic) et des sondes QoS (Quality of Service).

Pourquoi ce type d’équipement ne calcule pas la latence de manière globale sur un lien WAN ? Tentons de répondre à cette question.

Sur des réseaux WAN, on place des équipements qui permettent de prioriser certains types de flux, comme des flux applicatifs, qui impactent le business de l’entreprise, contrairement à des applications de type partage de fichiers, ou bien de sauvegarde. Pour cela, les boitiers de QoS peuvent agir sur la latence en ralentissant les acquittements TCP entre autres, donc la latence sera plus élevée pour certains flux applicatifs.

Pour un suivi global, on peut utiliser un outil de supervision comme Zabbix, pour effectuer à des intervalles réguliers des requêtes ICMP (Internet Control Message Protocol) de type « echo » et « reply ».

IV. Qu’est-ce qui peut influer le RTT d’un réseau ?

Intéressons-nous aux différents facteurs qui peuvent influer le RTT d'un réseau.

• La congestion du réseau

La congestion se produit lorsque trop de données circulent sur le réseau en même temps. Ceci peut entraîner des retards dus à la mise en file d'attente des paquets ou à leur retransmission en cas de perte. Cela augmente le RTT.

• Les temps de réponses des serveurs

Les serveurs peuvent augmenter les temps de réponses si ceux-ci sont surchargés en CPU ou en mémoire.

J’ai travaillé sur des analyses de performance pour déplacer un Mainframe dans un autre Datacenter. À partir d’une certaine heure, nous avons constaté une augmentation du temps des acquittements TCP, cela s’est expliqué par une baisse des performances de la CPU via une licence pour réduire les coûts.

• Nombre de sauts de réseau

Le nombre de sauts correspond au nombre de routeurs traversés par un paquet pour atteindre une destination. Ainsi, plus on traverse de routeurs, et plus le RTT réseau va augmenter.

• La distance géographique

La distance géographique est un élément physique qui va impacter la RTT réseau.

• Le support de transmission

Le type de support va influer sur le RTT réseau, en passant par une Fibre optique, la vitesse de transmission sera plus rapide qu'un support cuivre ou via une liaison satellite.

V. Analyse du RTT réseau avec Wireshark

L'outil ping, basé sur le protocole ICMP, est utile pour mesurer le RTT d'un réseau de façon globale sur un lien. Wireshark présente l'avantage d'être plus précis et de nous permettre d'aller plus loin dans l'analyse, car il mesure le RTT par session TCP. Découvrons comment utiliser Wireshark pour mesurer le RTT d'un réseau.

A. L’Initial Round Trip Time

Pour avoir le iRTT (Initial Round Trip Time - RTT initial), il est impératif de capturer le handshake TCP.

Pour se faire, si vous êtes côté client, vous allez sur le paquet « SYN ACK » ensuite dans le détail du paquet. Ici, vous déroulez la partie « Transmission Control Protocol », ensuite « SEQ/ACK Analysis » pour afficher le iRTT réseau.

PS : vous pouvez utiliser en colonne le filtre d’affichage « tcp.time_delta », celui-ci vous donnera aussi le iRTT pour les premiers paquets échangés au niveau de la poignée de main TCP.

B. Suivi du RTT réseau

Pour suivre le RTT réseau d’une session TCP, il faut aller dans « Statistiques » puis « Graphique des flux TCP » et cliquer sur « Temps d’Aller-Retour ».

Une nouvelle fenêtre s’ouvre :

Dans l’image ci-dessus, on aperçoit sur l’axe vertical le temps du RTT réseau qui est à 50 ms maximum dans le sens "site web vers mon ordinateur". Vous pouvez changer de sens à tout moment en cliquant sur le bouton « Changer de direction ».

La question qui se pose : est-ce un bon RTT réseau avec un maximum de 50ms ?

Un RTT réseau inférieur à 100 ms sera transparent pour les utilisateurs. Entre 100 et 200 ms, cela va commencer à impacter l’expérience utilisateur. Sachez que le RTT réseau va aussi dépendre de la sensibilité de l’application, la VOIP va être plus sensible qu’une application WEB, par exemple. Dans certains cas, un processus de mise en cache peut améliorer le RTT, et donc les performances d'une application.

Comment savoir quel paquet a remonté les 50 ms de RTT réseau ? Positionnez votre curseur sur le point et en bas, apparaitra le paquet qui a remonté 50 ms de RTT réseau.

Vous pouvez voir dans un paquet le RTT réseau calculé. Il est toujours lié à un Acquittement TCP. Il suffit de répéter la même procédure que pour le iRTT réseau, Wireshark va ajouter deux informations, le paquet à partir duquel il a calculé le RTT réseau et le RTT réseau affiché.

Vous pouvez ajouter en colonne le RTT réseau comme vu précédemment dans les tutoriels sur Wireshark.

VI. Le RTT réseau et la performance des applications

A. Turns applicatif

Qu’est-ce qu’un turn applicatif ? Un turn applicatif se définit comme l’ensemble formé par une requête applicative et la réponse correspondante.

Prenons l'exemple d'une application simple, où chaque interaction se limite à une seule requête suivie d'une seule réponse. Dans un environnement local, comme un LAN de recette avec une latence de 1 ms de RTT, le délai induit par un turn applicatif est pratiquement imperceptible.

Cependant, si cette même application est déployée sur un réseau satellite, où la latence peut facilement atteindre 500 ms par tour, on constate immédiatement une perte de 0,5 seconde par interaction. Bien que cela reste généralement supportable pour des opérations isolées, la situation devient problématique lorsque les interactions se multiplient.

Imaginez maintenant qu'au lieu d’une unique interaction, l'application effectue une série de requêtes SQL où le client rapatrie ligne par ligne les 1000 lignes de la réponse. Chaque ligne récupérée nécessite un nouveau turn applicatif, et donc une nouvelle attente de 0,5 seconde. Ainsi, l'opération qui aurait pu être réalisée en une seule interaction rapide dans un environnement à faible latence se transforme en une série d'attentes cumulatives, rendant l'application presque inutilisable dans ces conditions.

B. Comment voir les turns applicatif dans Wireshark ?

Sélectionnez un paquet, effectuez un clic droit et allez sur « Suivre » puis « TCP stream ».

Une nouvelle fenêtre s’ouvre. Tout en bas à gauche, vous avez le nombre de turn applicatif.

Il suffit de faire le calcul suivant pour connaître l’impact du RTT réseau sur la performance de l’application :

• Nombre de turns * par le RTT réseau en seconde

Remarque : les applications de type SQL font beaucoup d’échanges applicatifs et ne sont pas optimisés pour les liens WAN.

VII. Conclusion

Voici un aperçu du RTT réseau et de son analyse avec Wireshark ! Maintenant, nous allons pouvoir rentrer dans l’univers de TCP dans les prochains articles...

Si vous avez une question, n'hésitez pas à commenter cet article.

Yohan Ingénieur performance réseau

Exerce depuis maintenant 10 ans et demi en tant que responsable d’infrastructure dans une entreprise d’assurance (2 ans en alternance). Plus spécialisé dans l'analyse de traces réseau et de métrologie NPMd , je connais les environnements Cisco ACI , catalyst, Alcatel entre autres, à travers le site it-connect.fr. Je souhaite pouvoir partager mon expérience et mes connaissances réseau. J'ai une chaîne YouTube dédiée à wireshark.

See Full Bio