Cuando una conexión TCP se cierra en un extremo de la conexión, el otro extremo recibe un FINy responde con un ACK. Este extremo de la conexión entra entonces en el CLOSE_WAITestado. Una vez que close()se llama a este extremo, el TCP envía un FINpaquete y entra en el LAST_ACKestado. Sin embargo, nunca ingresa al TIME_WAITestado.
Ahora, supongamos que el Host A llama close()al socket y envía un FINpaquete al Host B. El Host A ingresa al FIN_WAIT_1estado. El host B recibe el FINpaquete, envía un ACKy luego ingresa al CLOSE_WAITestado. Sin embargo, el ACK se coloca en algún lugar de un enrutador ascendente.
Mientras tanto, el Host B llama close()(recuerde que el Host B está en el CLOSE_WAITestado) y envía un FINpaquete al Host A. El Host B ahora ingresa al LAST_ACKestado. El host A recibe el FINpaquete y responde con un archivo ACK. Luego ingresa al CLOSINGestado.
En el otro extremo, el anfitrión B todavía está en el LAST_ACKestado. Luego recibe el ACKmensaje del Host A y entra en el CLOSEDestado. Recuerde que el ACKenvío del Host B al Host A se eliminó y que el Host A no ha reenviado su FINpaquete. El host A reenvía su FINpaquete cuando se agotó el tiempo de espera; sin embargo, el host B cerró la conexión.
¿El Host A ahora está atrapado en el CLOSINGestado? ¿Puede continuar la interrupción de la conexión? ¿Qué pasa después?
Respuesta1
Mi TCP está un poco oxidado pero creo que funciona así:
Cuando el Host B llama close()y envía su mensaje FIN, el número de secuencia FINle revelará al Host A que perdió un paquete del Host B. Por lo tanto, el Host A no confirmará el Host B FIN, seguirá confirmando el último segmento TCP que recibió. recibido exitosamente del Host B. Esto solicitará al Host B que retransmita el archivo faltante ACK.
Por lo tanto, el Host A no alcanzará el CLOSINGestado, porque no considerará que el desorden FINse haya recibido verdaderamente hasta que reciba el estado faltante ACKque lo precedió.