¿Por qué lleva varios minutos limpiar un puerto TCP de escucha después de que un programa muere?

Si elimino un programa que está escuchando en un puerto TCP, el sistema demorará varios minutos en recuperar el puerto y volver a utilizarlo. He visto varias preguntas y respuestas que mencionan este fenómeno, pero sin una explicación. ¿Por qué sucede eso? ¿Por qué el sistema no reclama el puerto de inmediato? ¿También ocurre en otros sistemas, como Windows o Mac?

networking tcp resources

— Petr Pudlák
fuente

La idea detrás de esto es asegurarse de que no reciba paquetes destinados al programa anterior que escucha en ese puerto. Este TIME_WAITestado se define en RFC793 como dos veces la vida útil máxima del segmento.

No sé acerca de otros sistemas operativos, pero supongo que todos estos tienen algún tipo de comportamiento similar.

Una solución para este problema es establecer SO_REUSEADDRen el zócalo que debe ignorar el TIME_WAITestado.

— Ulrich Dangel
fuente

Al revisar mi confiable diagrama de estado TCP, puedo ver que TIME_WAIT es el último estado de un socket y generalmente persiste para 2MSL, que es el doble de la vida útil máxima del segmento. La especificación (RFC793) establece esto como 2 minutos, dando 4 minutos en total. Esto permite suficiente tiempo para que cualquier solicitud y respuesta aún "en vuelo" se procese y aterrice en el programa correcto, o se descarte si el socket está en TIME_WAIT.

— Faelkle

Puedo confirmar que esto también sucede en Windows.

— Thomas Bratt