¿Cuál es el propósito de TIME WAIT en la conexión TCP?

Descubrí que la razón por la que el cerrador activo ingresa TIME WAIT es para asegurarse de que el ACK final no se pierda. Pero, ¿cómo sabe si se pierde el ACK final? ¿El cerrador pasivo reenviará el FIN y luego el cerrador activo sabrá que se perdió el ACK? Aquí hay una imagen del TCP FSM.

¿El cerrador pasivo reenviará el FIN y luego el cerrador activo sabrá que se perdió el ACK?

Si. Citando de TCP / IP Ilustrado Volumen 1 , en la sección Administración de la conexión TCP:

3. Para completar el cierre, el segmento final contiene un ACK para el último FIN. Tenga en cuenta que si se pierde un FIN, se retransmite hasta que se recibe un ACK.

Hay un tiempo de espera. Cuando está dentro LAST_ACK, el cerrador pasivo se reenviará FINcuando haya un tiempo de espera, suponiendo que se haya perdido. Si realmente se perdió, el cerrador activo eventualmente recibirá el retransmitido FINy entrará TIME_WAIT. Si FINno se perdió pero se perdió la final ACK, entonces el cerrador activo entra TIME_WAITy recibe de FINnuevo. Cuando esto sucede - recepción de una FINen TIME_WAIT- el ACKse retransmite.

El valor de tiempo de espera TIME_WAITes NO utiliza con fines de retransmisión. Cuando se agota el tiempo de espera TIME_WAIT, se supone que la final ACKse entregó correctamente porque el cerrador pasivo no retransmitió los FINpaquetes. Entonces, el tiempo de espera TIME_WAITes solo una cantidad de tiempo después del cual podemos asumir con seguridad que si el otro extremo no envió nada, es porque recibió la final ACKy cerró la conexión.

Pero, ¿cómo sabe si se pierde el ACK final?

Porque no lo recibió dentro del período de tiempo de espera. Sé que es una respuesta "duh", pero eso es exactamente por qué existen estos estados y tiempos de espera.

¿El pasivo más cercano reenviará el FIN?

No. No, a menos que lleguen más paquetes para ese flujo, y eso resultaría en el envío de "RST" (reinicio).

Todo el proceso es una máquina de estado complicada para ejecutar un apagado ordenado a pesar de la posibilidad de fallas en la red. Las redes se rompen, los enlaces experimentan errores, los enlaces se saturan y tienen que soltar paquetes, los dispositivos fallan, etc. Como ejercicio, ejecute el árbol de estado para una conexión activa cuando uno de los puntos finales simplemente desaparece (por ejemplo, falla de energía).

TL; DR Ese árbol de estado está diseñado para manejar todos los modos de falla posibles.

El propósito de TIME_WAIT es permitir que la red distinga los paquetes que llegan como pertenecientes a la conexión 'antigua y existente' de una nueva. La recomendación es configurar el temporizador TIME_WAIT al doble de la vida útil máxima del segmento (MSL), en mi sistema el MSL es de 1 minuto, por lo que las conexiones permanecen en el estado TIME_WAIT durante 2 minutos.

Después de este período de tiempo, los paquetes que llegan ya no están asociados con la conexión anterior.

TIME_WAIT no se espera directamente para enviar paquetes ACK; eso es impulsado por los estados CLOSE_WAIT y FIN_WAIT. Cuando llegas al estado TIME_WAIT, el socket ya está cerrado.

Referencias: 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 /