À quoi sert TIME WAIT dans la connexion TCP?

J'ai trouvé que la raison pour laquelle le plus proche actif entre dans TIME WAIT est de s'assurer que le dernier ACK n'est pas perdu. Mais comment savoir si l'ACK final est perdu? Le plus proche passif renverra-t-il le FIN et le plus proche actif saura-t-il que l'ACK a été perdu? Voici une image du TCP FSM.

Le plus proche passif renverra-t-il le FIN et le plus proche actif saura-t-il que l'ACK a été perdu?

Oui. Citant du volume illustré TCP / IP 1 , dans la section Gestion de la connexion TCP:

3. Pour terminer la fermeture, le segment final contient un ACK pour la dernière FIN. Notez que si un FIN est perdu, il est retransmis jusqu'à ce qu'un ACK soit reçu.

Il y a un délai d'attente. Une fois dedans LAST_ACK, le plus proche passif renverra FINquand il y a un timeout, en supposant qu'il a été perdu. S'il était en effet perdu, alors le plus proche actif recevra finalement le retransmis FINet entrera TIME_WAIT. Si le FINn'a pas été perdu mais que la finale a ACKété perdue, alors le plus proche actif est dedans TIME_WAITet reçoit à FINnouveau. Lorsque cela se produit - recevoir un FINin TIME_WAIT- le ACKest retransmis.

La valeur de délai d'attente dans TIME_WAITn'est PAS utilisée à des fins de retransmission. Lorsqu'il y a un délai d'attente TIME_WAIT, il est supposé que la finale a ACKété livrée avec succès car le plus proche passif n'a pas retransmis les FINpaquets. Donc, le délai d'attente TIME_WAITn'est qu'une période de temps après laquelle nous pouvons supposer que si l'autre extrémité n'a rien envoyé, c'est parce qu'il a reçu la finale ACKet fermé la connexion.

Mais comment savoir si l'ACK final est perdu?

Parce qu'il ne l'a pas reçu dans le délai imparti. Je sais que c'est une réponse "duh", mais c'est exactement pourquoi ces états et délais d'expiration existent.

Le plus proche passif renverra-t-il le FIN

Non, sauf si d'autres paquets arrivent pour ce flux, ce qui entraînerait l'envoi de "RST" (réinitialisation).

L'ensemble du processus est une machine à états compliquée pour exécuter un arrêt ordonné malgré la possibilité de pannes de réseau. Les réseaux se rompent, les liens rencontrent des erreurs, les liens deviennent saturés et doivent abandonner les paquets, les appareils tombent en panne, etc. En tant qu'exercice, exécutez l'arborescence d'état pour une connexion active lorsque l'un des points finaux disparaît juste (par exemple, panne de courant).

TL; DR Cet arbre d'état est conçu pour gérer tous les modes de défaillance possibles.

Le but de TIME_WAIT est de permettre au réseau de distinguer les paquets qui arrivent comme appartenant à la "vieille connexion existante" d'une nouvelle. La recommandation est de régler le temporisateur TIME_WAIT sur deux fois la durée de vie maximale du segment (MSL), sur mon système, le MSL est de 1 minute, donc les connexions restent dans l'état TIME_WAIT pendant 2 minutes.

Passé ce délai, les paquets qui arrivent ne sont plus associés à l'ancienne connexion.

TIME_WAIT n'est pas directement attendu pour envoyer des paquets ACK; qui est piloté par les états CLOSE_WAIT et FIN_WAIT. Lorsque vous arrivez à l'état TIME_WAIT, le socket est déjà fermé.

Références: http://www.tcpipguide.com/free/t_TCPConnectionTermination-3.htm https://en.wikipedia.org/wiki/Maximum_segment_lifetime http://www.lognormal.com/blog/2012/09/27/ linux-tcpip-tuning /