Pourquoi le nettoyage d'un port TCP d'écoute prend-il plusieurs minutes après la fin d'un programme?

27

Si je tue un programme qui écoute sur un port TCP, cela peut prendre plusieurs minutes jusqu'à ce que le port soit récupéré par le système et réutilisable. J'ai vu plusieurs Q / A mentionner ce phénomène, mais sans explication. Pourquoi cela se produit-il, pourquoi le système ne récupère-t-il pas le port tout de suite? Cela se produit-il également sur d'autres systèmes, tels que Windows ou Mac?

networking  tcp  resources 
— Petr Pudlák
source

Réponses:

25

L'idée derrière cela est de s'assurer que vous ne recevez pas de paquets ciblés pour le programme précédent en écoutant sur ce port. Cet TIME_WAITétat est défini dans la RFC793 comme deux fois la durée de vie maximale d'un segment.

Je ne connais pas les autres systèmes d'exploitation, mais je suppose que tous ces systèmes ont une sorte de comportement similaire.

Une solution de contournement pour ce problème consiste à définir SO_REUSEADDRsur le socket qui doit ignorer l' TIME_WAITétat.

— Ulrich Dangel
source
3
En vérifiant mon diagramme d'état TCP fiable, je peux voir que TIME_WAIT est le dernier état d'une socket et persiste généralement pour 2MSL - ce qui est deux fois la durée de vie maximale d'un segment. La spécification (RFC793) indique que 2 minutes, soit 4 minutes au total. Cela laisse suffisamment de temps pour que toutes les demandes et réponses encore "en cours" soient traitées et atterrissent au bon programme - ou soient rejetées si le socket est dans TIME_WAIT.
— Faelkle
Je peux confirmer que cela se produit également sous Windows.
— Thomas Bratt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.