Perché sono necessari diversi minuti per pulire una porta TCP in ascolto dopo la fine di un programma?

Se uccido un programma in ascolto su una porta TCP, ci vogliono diversi minuti prima che la porta venga recuperata dal sistema e riutilizzabile. Ho visto diversi Q / A menzionare questo fenomeno, ma senza una spiegazione. Perché succede, perché il sistema non recupera subito la porta? Succede anche su altri sistemi, come Windows o Mac?

networking tcp resources

— Petr Pudlák
fonte

L'idea alla base di ciò è quella di assicurarsi di non ricevere pacchetti destinati al programma precedente in ascolto su quella porta. Questo TIME_WAITstato è definito in RFC793 come due volte la durata massima del segmento.

Non conosco altri sistemi operativi, ma presumo che tutti abbiano un comportamento simile.

Una soluzione alternativa a questo problema consiste nell'impostare SO_REUSEADDRsul socket che dovrebbe ignorare lo TIME_WAITstato.

— Ulrich Dangel
fonte

Controllando il mio fidato diagramma di stato TCP, posso vedere che TIME_WAIT è l'ultimo stato di un socket e generalmente persiste per 2MSL, che è il doppio della durata massima del segmento. Le specifiche (RFC793) lo indicano come 2 minuti, per un totale di 4 minuti. Ciò consente un tempo sufficiente per l'elaborazione di tutte le richieste e le risposte ancora "in volo" e l'arrivo al programma giusto, oppure per essere scartato se il socket è in TIME_WAIT.

— Faelkle

Posso confermare che ciò accade anche in Windows.

— Thomas Bratt,