Série TCP #2: Comment diagnostiquer les fermetures et deconnexions de sessions TCP

Intoduction:

Voici un deuxième article d’une série couvrant tout ce que vous devez savoir pour résoudre les problèmes de performance qui ont une incidence sur les applications qui s’appuient sur le protocole TCP.

Après avoir étudié comment les sessions TCP sont établies (article en anglais), nous allons maintenant voir ce qui peut dysfonctionner lors de la fermeture d’une session TCP.

Paradoxalement, fermer une connexion TCP est plus complexe que de la créer ! Cela est dû au fait que les ressources doivent être correctement libérées des deux côtés.

La façon standard de fermer une session TCP consiste à envoyer un paquet FIN, puis à attendre une réponse FIN de l’autre partie.

1. A envoie un paquet FIN et attend une réponse, il peut libérer quelques ressources mais doit attendre la réponse de l’autre partie (Fin Wait)
2. B le reçoit et doit libérer des ressources (il doit attendre la fermeture au niveau applicatif – (Close Wait)
3. B peut maintenant envoyer un FIN à A et attendre l’acquittement (Last Ack wait).
4. A peut maintenant terminer complètement son travail, mais doit attendre une collision réseau (?) (Time Wait), il se peut qu’il doive à nouveau envoyer le Ack final.
5. B reçoit enfin le Ack final et détruit (tue) la connexion.

Cela fonctionne bien dans un monde parfait. Mais qu’arrive-t-il lorsqu’une partie de la conversation est cassée ? C’est pourquoi il existe un Reset (RST) du paquet.

Ces terminaisons anormales (que ce soit des lancements avortés ou des déconnexions) pourraient apparaître à cause de :

• Un manque de ressources ou une coupure réseau,
• Un crash / bug pendant la session,
• L’une des parties a de son côté déjà fermé la connexion alors que la seconde continue d’envoyer des données,
• Le serveur refuse d’ouvrir une connexion au client.

PV  fournit des métrics pour voir si les connexions TCP se terminent correctement ou non. En sélectionnant la thème « Événements TCP », vous obtenez le nombre de paquets FIN et RST dans les deux sens.

Si les taux de SYN par connexion et de RST serveur sont tous deux élevés (Fig3 – 1ère rangée), cela signifie que le serveur refuse les demandes de connexion client. En forant dans les conversations (Fig4), vous aurez les détails des ports serveur et les applications qui causent ce problème. Par la suite, nous voyons des tentatives de connexion à un VPN à partir d’une adresse IP utilisant le port ‘1194’.

Pour les utilisateurs avancés de PerformanceVision

Si vous souhaitez filtrer les données avec ou sans paquets RST ou FIN, PV fournit des filtres personnalisés. Dans l’article précédent, nous avons déjà vu comment filtrer les connexions.

• FIN: fin.count, fin.count.srv, fin.count.clt
• RST: rst.count, rst.count.srv, rst.count.clt

Exemples:

• Flux avec un RST mais pas de FIN: rst.count > 0 and fin.count = 0

Flux avec un RST mais pas de connexions: rst.count > 0 and ct.count = 0

Parfois, les paquets RST sont plutôt «normaux». Par exemple, lorsque l’utilisateur interrompt manuellement un énorme transfert de données. La session TCP envoyait des paquets aussi rapidement que possible, alors, lorsque le client envoie le FIN et ferme sa partie, le serveur est toujours en train d’envoyer beaucoup de données pendant un long moment. Dans ce cas, le client envoie des paquets RST jusqu’à ce que le serveur cesse d’envoyer des données. Dans ce cas, ???? c’est comme client FIN (que le serveur FIN), mais en plus, vous verrez des paquets RST.

Il est également important de noter que certaines applications ne ferment pas correctement la session et utilisent simplement un RST pour fermer chaque session. Ce n’est pas une bonne pratique, mais vous devez savoir que certaines applications sont développées de cette façon.

Il pourrait également être pertinent de représenter quelques métriques de RST ou FIN au fil du temps. PV fournit une métrique pour représenter graphiquement le taux de RST par connexion au fil du temps en utilisant des graphiques personnalisés (Fig. 5).

Conclusion

Nous avons vu que le processus de fermeture d’une connexion TCP peut être plus complexe l’ouverture. La session peut être fermée par un double FIN, par un mélange FIN + RST, ou uniquement par des paquets RST. Mais les paquets RST peuvent également être envoyés sans aucune connexion.

PerformanceVision aide à diagnostiquer les problèmes de session en remontant des statistiques sur les FIN, RST, SYN et les Connexions. PV est également capable de représenter graphiquement toutes les métriques au fil du temps, et particulièrement le RST par Connexion.

Comme nous l’avons vu dans le premier article, nous pouvons utiliser des pages telles que Top Client Zone et Top Servers pour analyser d’où vient le problème.

Dans un prochain article, nous examinerons comment fonctionne la retransmission TCP, et quand cela peut être un problème ou non.