Réseau : analyse d’une connexion TCP et de ses options avec Wireshark
Sommaire
I. Présentation
Dans cet article, nous allons aborder le principe de connexion TCP qui est appelé communément le « tree way-handshake » et les options présentées lors de cette connexion, le tout grâce à une analyse Wireshark.
Mais avant d’aborder cette partie, il faut savoir que le protocole TCP existe depuis 1981 avec la RFC 793. Afin de répondre à l’augmentation des débits et de la latence sur les réseaux, le protocole TCP a eu le droit à des améliorations, dont l’une des plus importantes est la RFC 7323 appelé « TCP for High Performance ». Pour information, la dernière RFC liée à TCP date d'août 2022 (RFC 9223).
Pour rappel, il existe déjà un article sur le protocole TCP sur notre site :
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. Le principe de la connexion TCP
La connexion TCP permet d’établir une connexion à un service comme un serveur web par exemple. La connexion TCP va permettre d’établir plusieurs paramètres entre les deux hôtes :
- Numéro de séquence à utiliser
- Les options supportées par les deux hôtes
- Le calcul de l'Initial RTT du réseau
Pour rappel, voici une illustration de la demande de connexion TCP :
Les options TCP sont présentes dans les segments « SYN » et « SYN ACK » donc il est important de capturer la demande de connexion TCP dans le cadre d’une analyse de performance.
Les champs flags valides lors d’une connexion TCP sont « SYN » qui est la demande de connexion, « SYN ACK » qui est la réponse du serveur distant et « ACK » pour valider la connexion de la part du client.
Dans certains cas, le flag « ECN-setup » (Explicit Congestion Notification) est utilisé pour informer l’hôte distant d’une congestion réseau. Elle est définie dans la RFC 3168.
Le flag « ECN-Setup » comprend les flags suivants :
- ECE : Explicit Congestion Echo
- CWR : Congestion Window Reduct - Ce flag permet d’informer une réduction de la fenêtre TCP de congestion (la fenêtre envoi de données)
La particularité du flag ECE, c’est que ce sont les routeurs qui informent d’une congestion au niveau du paquet IP.
Pourquoi je mentionne ce point, car des outils comme NMAP peuvent ajouter des flags comme « URG » (le flag urgent permet d’envoyer des données de manière prioritaire) mais celui-ci ne doit pas apparaitre lors du processus de demande de connexion TCP.
III. Les options disponibles
Les options TCP présentées par les différents hôtes ne sont pas une négociation lors de la connexion TCP. Si une option TCP n’est pas présente sur l’un des hôtes de la connexion, celle-ci ne sera pas utilisée.
Dans ce chapitre je vais présenter les options les plus couramment utilisées, bien qu'il en existe d’autres.
A. La MSS
La MSS (Maximum Segment Size) est la taille maximum des données que peut contenir un segment. Si celui-ci n’est pas spécifié par un hôte, la valeur par défaut est égale à 536 octets.
Voici un extrait de la dernière RFC 9223 à ce sujet :
La taille de la MSS va dépendre de plusieurs facteurs :
- La MTU (Maximum Transmit Unit) : c’est la taille maximum que peux transporter le réseau en incluant les entêtes protocolaires et les données, sur Ethernet par défaut nous sommes à 1500 octets. Donc la MSS sera à 1460 octets.
- Des options TCP utilisées, par exemple l’option Timestamps va prendre 12 octets donc la MSS sera à 1448 octets
- De votre type de connexion, si vous êtes en VPN, la MSS va baisser, car il faut prendre en compte l’entête de votre protocole utilisé.
Dans l’entête TCP, la MSS est de 2 octets.
B. Windows Scaling
Avant de rentrer dans le détail de cette option, nous allons faire un rappel sur la fenêtre TCP. Qu’est-ce que la fenêtre TCP ?
La fenêtre TCP est le buffer de réception des données reçu lors des échanges TCP, ce buffer permet de stocker les données reçues avant de les envoyer vers l’application. Par défaut la fenêtre TCP est de 64 Ko octets, donc on peut recevoir 64 Ko de données avant d’envoyer un acquittement TCP.
La fenêtre TCP joue un rôle primordial dans la performance d’un transfert de données, car nous pouvons calculer le débit consommé avec la fenêtre TCP de réception et le RTT réseau.
Voici le calcul théorique :
Débit = fenêtre TCP en octets * 8 bits / RTT réseau en secondesVoici un exemple de calcul : prenons notre fenêtre TCP de base 64 Ko avec un RTT réseau de 5 ms
Débit = 64000 * 8 / 0.005 sec
Débit = 102 Mb/sCela signifie que nous pourrons au maximum consommer 102 Mb/s de bande passante (débit), donc nous seront bridé par la fenêtre TCP de réception.
Avec l’augmentation des bandes passantes et de la latence, il a fallu adapter le protocole TCP pour répondre à l’évolution des réseaux, c’est pour cela que la RFC 7323 (qui a remplacé la RFC 1323) a été publié.
Dans cette RFC, on implémente l’option « Windows Scaling » qui va permettre de mettre en place un facteur de mise à l’échelle de la fenêtre TCP par des puissances de deux. La taille de la fenêtre TCP avec cette option peut atteindre 1 Gigaoctet au maximum.
- Extrait de la RFC 7323 :
C. SACK
L’option TCP « SACK » signifie Select Acknowledge. Elle permet, en cas de perte de paquets, de demander seulement les paquets perdus et d’informer l’hôte distant des paquets reçus.
Pour plus d’informations, vous pouvez aller voir la RFC 2018.
D. Timestamps
L’option Timestamps a aussi vu le jour sous la RFC 7323 (anciennement 1323). Cette option permet de calculer le RTT réseau en utilisant les flags « TSval » et « TSecr » : ce sont des chiffres effrayants à regarder ! 😉
L’autre utilisation de l’option Timestamps, est de rejeter les anciens segments dupliqués pour éviter une corruption de la session TCP. L’option Timestamps occupe 12 octets dans l’entête TCP.
Pour plus d’information, vous pouvez vous référer à la RFC 7323, au chapitre 5.
IV. Wireshark et les options TCP
A. Affichage dans Wireshark
Au sein de l'interface de Wireshark, les options TCP apparaissent dans la colonne « info » dans le panneau liste des paquets.
Voici un exemple de connexion TCP :
Dans cette connexion TCP, on remarque que les deux hôtes supportent seulement deux options TCP.
- « WS » : Windows Scaling avec des valeurs différents mais cela ne pose aucun problème tant que l’option est supportée
N.B : la valeur WS ne doit jamais être à UN, car 64 ko multiplié par 1 est toujours égal à 64 Ko.
La seule exception que j’ai remarquée lors de mes analyses de performance avec une valeur à 1, c’est avec un load balancer du constructeur F5 qui met la valeur WS à 1, mais qui augmente sa fenêtre TCP malgré tout.
- « SACK_PERM » pour utiliser l’option Select Acknowledge.
La fenêtre TCP de réception de base à une valeur de « 64240 octets » pour les deux hôtes et une MSS de « 1460 octets ».
Examinons maintenant en détail la trame « numéro 1 » au niveau de l’entête TCP :
Quelques commentaires sur cette image :
- Au niveau du champ flag, on voit seulement le « SYN »
- Au niveau des options TCP, on voit une nouvelle valeur qui est No-Operation (NOP) : ce sont les options non supportées par les hôtes.
- On voit que les options ajoutent « 12 octets » d’entête TCP, ce qui est égal à « 32 octets ».
Concernant l’option « Windows scale » Wireshark indique qui faut multiplier par 256 la valeur qui se situe dans « Window » qui est égal à 64240 octets. Enfin, la dernière option activée est « SACK permitted ».
Passons à la trame « numéro 2 »
Sur la trame numéro 2, on peut noter seulement deux différences :
- Flags, qui contient à la fois « SYN » et « ACK »
- Le facteur multiplicateur de « Window Scaling » de 128
Je vous laisse calculer la taille de la fenêtre de réception de chaque hôte, en indiquant votre méthode de calcul et le résultat dans les commentaires de l’article 😊 ! À vous de jouer !
B. Les filtres associés
Maintenant que nous avons vu les options TCP et les flags, voici quelques filtre d’affichage qui peuvent vous aider à analyser une connexion TCP.
V. Le RTT réseau
A. Définition
Le RTT signifie Round Trip Time : c’est le temps pour aller d’un point A à un point B et faire le chemin inverse. Ce temps est mesuré en millisecondes (ms).
Il va permettre de déterminer la latence. En effet, la latence du réseau : c’est le temps qu’effectue un paquet pour aller d’un point A à un point B, ce temps est mesuré en millisecondes (ms), donc on divisera le RTT par deux.
B. Comment calcule-t-on le RTT réseau ?
Le RTT réseau se calcul sur la demande de connexion TCP, pour en déduire la latence du réseau.
L’emplacement de votre point de capture est très important pour connaitre le RTT réseau, voici un schéma qui va illustrer le calcul du RTT réseau par Wireshark ou des équipements comme des boitiers de QoS ou des sondes réseau.
C. Wireshark et le RTT
Dans Wireshark, le calcul du RTT réseau sur la connexion TCP s’appelle iRTT (Initial Round Trip Time) car Wireshark va prendre des mesures du RTT réseau tout au long de la session TCP. Nous reviendrons sur cette notion dans un prochain article qui sera publié sur IT-Connect.
Le iRTT réseau se situe dans l’analyse détaillée du protocole TCP dans la partie « SEQ/ACK analysis ».
Ma capture réseau a été prise sur mon poste de travail, donc il faut aller sur la réponse du serveur à la demande de connexion TCP pour avoir le iRTT.
Dans mon cas, le temps d’un aller-retour avec l’hôte 178.32.126.188 est à « 14ms » donc une latence de 7 ms.
Voici un filtre que vous pouvez utiliser pour voir les RTT réseau élevées :
VI. Conclusion
Maintenant vous avez les cartes en main pour analyser une demande de connexion TCP, et calculer le RTT réseau associé ! J’espère que cet article vous a plu, car d’autres vont suivre sur TCP, notamment sur l'analyse de problèmes de performances. Toutefois, le prochain article sera théorique et portera sur le RTT réseau avant d’explorer l’univers de TCP avec Wireshark.
Très bon article ! On en veut encore.
Merci beaucoup pour ce début d’articles. J’espère qu’un maximum de cas réel si possible et comment les résoudre/analyser seront utilisés car les tutos d’outil de diag prennent tout leur sens « quand ca va mal » et pas quand la latence est à 7 😀