Lanzamiento de la conexión TCP: ¿Por qué ambas partes deben enviar un FIN y recibir el reconocimiento?

Vea la respuesta de Kelly Martin primero. Entonces sigue leyendo.

La conexión bidireccional TCP se construye realmente como dos conexiones unidireccionales separadas en direcciones opuestas. Cada extremo es el emisor de una dirección y el receptor de la otra dirección. Hay estados mantenidos en TCP para cada par de emisor-receptor que se distribuye dentro de las máquinas de estado TCP en ambos lados.

Por lo tanto, cada lado de la conexión TCP mantiene una parte de dos estados de conexión distintos. Para derribar la conexión general, cada conexión se debe derribar por separado desde el punto de vista de las máquinas de estado TCP individuales. Es por eso que cada lado emisor debe enviar su propio FIN para indicar su intención de terminar la conversación, y el lado receptor correspondiente debe ACEPTARLO y establecer su estado en CLOSE-WAIT (o TIME-WAIT).

Tenga en cuenta que la aplicación que inició la conexión TCP también tuvo un papel que desempeñar aquí. Las aplicaciones en los dos lados que abrieron la conexión pueden no comportarse simétricamente. Un lado pide que finalice la conexión cerrando el socket TCP, que activa la máquina de estado de envío TCP para enviar FIN. El TCP receptor notifica a su aplicación final acerca de esto mediante una convención conocida como READ-ZERO en su próxima lectura , diciéndole a la aplicación que el extremo remoto se cerró. Si la aplicación lo elige, puede continuar escribiendo en el socket y se requiere que la máquina de envío TCP en su extremo continúe enviando los segmentos al extremo remoto. En la práctica, esto es inútil ya que el otro extremo ha cerrado su socket, lo que significa que las funciones de envío y recepción están inactivas. Por lo tanto, un FIN iniciado desde un lado también debe dar como resultado FIN desde el otro extremo, y cada FIN requiere su propio ACK para que la conexión se cierre de manera ordenada.

Un socket TCP cerrado entra en uno de dos estados; CLOSE-WAIT o TIME-WAIT, bajo condiciones ligeramente diferentes, cuyos detalles se me escapan ahora, pero está bien documentado en cualquier buen libro de TCP.

También vea mi respuesta relacionada: la respuesta de Diwakar Tundlam a En TCP, el cliente envía un SYN y luego el servidor responde con un ACK del SYN. Pero luego el cliente regresa y envía otro ACK antes de enviar datos. ¿Cuál es el punto del segundo ACK?

Un FIN cierra la conexión en una sola dirección. La parte que envía el FIN dice “No tengo nada más que decir”. No está diciendo “He terminado de escucharte” y la otra parte puede continuar enviando datos hasta que también se haga, en ese momento enviará un FIN por sí mismo. Una vez que ambas partes han indicado que han terminado de hablar y han reconocido la indicación de la otra parte, no hay nada más que pueda suceder en la conexión, y deja de existir.

Si un par desea terminar por la fuerza las dos mitades de la conexión, debe hacerlo enviando un RST.

Reconocer el FIN puede reducir el desperdicio de recursos del servidor. Piense en eso, si el paquete de FIN del cliente se pierde (debido a Internet inestable, todos los protocolos de Internet deben preocuparse por la pérdida del paquete) en el protocolo de no reconocimiento, el servidor mantiene los servicios relacionados en ejecución mientras los servicios del cliente están cerrado. Por lo tanto, necesitamos el ACK para FIN.

Todos los apretones de manos de tres vías en TCP tienen como objetivo garantizar que la conexión aún funcione en ambas direcciones. La comunicación unidireccional es un modo típico de falla de red.

Cuando la Parte # 1 envía un FIN, la Parte # 2 envía un ACK, pero la Parte # 2 no tiene forma de saber si la Parte # 1 recibió el ACK. El último ACK asegura que la conexión sigue siendo bidireccional y que se recibió cualquier último dato enviado durante la fase de cierre.

FIN es un cierre elegante y una descarga de datos restantes. Si una conexión se va a abandonar abruptamente y la pérdida de datos es aceptable, RST es una mejor opción que FIN.