¿Cómo termina la conexión TCP si una de las máquinas muere?

Question

Si se establece una conexión TCP entre dos hosts (A & B), y digamos que el host A ha enviado 5 octetos al host B, y luego el host B falla (debido a un motivo desconocido). El host A esperará acuses de recibo, pero al no obtenerlos, volverá a enviar los octetos y también reducirá el tamaño de la ventana del remitente. Esto repetirá un par de veces hasta que el tamaño de la ventana se reduzca a cero debido a la pérdida de paquetes. Mi pregunta es, ¿qué pasará después?

Answer 1

En este caso, TCP agota el tiempo de espera de la confirmación y devuelve un error a la aplicación. La aplicación tiene que leer/recv desde el socket TCP para obtener información sobre ese error, una llamada posterior de escritura/envío también fallará. Hasta el momento en que TCP determinó que la conexión se ha ido, las llamadas de escritura/envío no fallarán, tendrán éxito como se ve desde la aplicación o bloqueará si el buffer de socket está lleno.

En el caso de que su host B desaparece después de haber enviado sus ACK, el host A no se enterará hasta que envíe algo a B, que eventualmente también expirará o provocará un error ICMP. (Por lo general, la primera llamada de escritura/envío no fallará ya que TCP no interrumpirá la conexión de inmediato, y tenga en cuenta que las llamadas de escritura/envío no esperan los ACK hasta que se completen).

Tenga en cuenta también que la retransmisión no reduce el tamaño de la ventana.

Answer 2

favor, siga este link

ahora una respuesta muy simple a su pregunta en mi opinión es, la conexión será cronometrado a cabo y será cerrado. existe otra posibilidad de que se genere algún error de ICMP debido a la falta de respuesta de la máquina.

Además, si la máquina accidentada vuelve a estar en línea, se observará el procedimiento descrito en el enlace que acabo de pegar arriba.

Answer 3

Depende de la implementación del sistema operativo. En resumen, esperará ACK y volverá a enviar los paquetes hasta que finalice el tiempo de espera. Entonces su conexión será derribada. Para ver exactamente lo que sucede en Linux, busque here otros sistemas operativos siguen un algoritmo similar.

Answer 4

en su caso, se generará un FIN (por el nodo superviviente) y la conexión migrará eventualmente al estado CERRADO. Si mantiene grep-ing para la salida netstat en la dirección IP de destino, verá la migración desde el estado ESTABLECIDO a TIMED_WAIT y finalmente desaparecerá.

En su caso, esto sucederá ya que TCP mantiene un temporizador para obtener el ACK del paquete que ha enviado. Este temporizador no es lo suficientemente largo para que la detección ocurra rápidamente.

Sin embargo, si la máquina B muere después de que A recibe ACK y después de eso A no envía nada, entonces el temporizador anterior no puede detectar el mismo evento, sin embargo otro temporizador (tiempo de espera inactivo) detectará esa condición y la conexión se cerrará entonces. Este período de tiempo de espera es alto por defecto. Pero normalmente este no es el caso, la máquina A intentará enviar cosas intermedias y detectará la condición de error en la ruta de envío.

En resumen, TCP es lo suficientemente inteligente como para cerrar la conexión por sí mismo (y dejar que la aplicación lo sepa), excepto en un caso (tiempo de espera inactivo: que por defecto es muy alto).

cforfun

Answer 5

En casos normales, cada lado de su terminación final de la conectividad mediante el envío de un mensaje especial con una aleta (acabado) bit establecido. El dispositivo que recibe este FIN responde con un acuse de recibo al FIN para indicar que se ha recibido. La conexión como un todo no se considera terminada hasta que ambos dispositivos completen el procedimiento de apagado enviando un FIN y recibiendo un acuse de recibo.