Combinando el protocolo TCP de la red informática

Prefacio

Este artículo combina el protocolo
TCP TCP: Protocolo de control de transmisión, protocolo de control de transmisión

Características principales de TCP

El protocolo de transmisión orientado a la conexión
significa que el programa de aplicación debe establecer primero una conexión de transmisión TCP antes de utilizar TCP. Una vez completada la transmisión de datos, la conexión de transmisión TCP establecida debe liberarse.
Solo admite transmisión de unidifusión.Cada
conexión de transmisión TCP solo puede tener dos puntos finales (socket), y solo puede realizar transmisión de datos punto a punto, y no admite métodos de transmisión de multidifusión y difusión.
Proporcionar un servicio de entrega confiable
TCP puede estar libre de errores, sin pérdidas, no repetitivo y llegar al extremo opuesto de acuerdo con la secuencia de tiempo.
La unidad de transmisión es el segmento de datos.
TCP todavía utiliza el "segmento de datos" tradicional como unidad de transmisión de datos.
El segmento de datos se refiere al bloque de datos obtenido por TCP segmentando los datos recibidos de la capa de aplicación.
Solo un formato de TPDU
Debido a que el encabezado del segmento de datos TCP ha incluido los campos característicos requeridos por varias TPDU, se realiza principalmente mediante múltiples acciones de control entre ellos.
Ambos extremos de la conexión TCP que admiten la comunicación full-duplex están equipados con envío y almacenamiento en búfer para almacenar datos temporalmente para la comunicación bidireccional.
Las conexiones TCP se basan en flujos de bytes, no en flujos de mensajes.
TCP no transmite mensajes individuales de forma independiente como UDP, sino que transmite en flujos de bytes sin preservar los límites del mensaje.
El tamaño del segmento de datos TCP y el número de segmentos de datos enviados cada vez son variables.
El tamaño del segmento de datos de la transmisión TCP se determina de acuerdo con el tamaño de la ventana proporcionado por la otra parte y la ventana de envío disponible actualmente (la congestión actual de la red); también está sujeto a El tamaño del mensaje transmitido por la capa de aplicación está determinado por el tamaño del valor de MTU en la red que se
enruta ; de esta manera, el número de segmentos de datos TCP que se pueden enviar a la vez tampoco es fijo; puede enviar solo un segmento de datos TCP a la vez, o puede enviar varios datos TCP a la vez, segmento, siempre que esté dentro de los 发送窗口大小límites disponibles actualmente .
Además, si los datos transmitidos al búfer de TCP por el proceso de la aplicación son demasiado largos, TCP puede segmentarlos; a la inversa, si los datos transmitidos al búfer de TCP son demasiado pequeños, el TCP esperará suficientes datos en el búfer para ensamblar. Se envía a un segmento de datos juntos (inmersión y desembalaje).

Segmento TCP

Mensaje

Las palabras en mayúsculas de ACK, SYN y FIN representan bits de bandera, y su valor es 1 o 0;
las palabras en minúscula de ack y seq representan números de secuencia.

El puerto de origen y el puerto de destino
representan respectivamente los números de puerto TCP de la parte que llama y la parte llamada. Un puerto y su dirección IP de host pueden identificar completamente un punto final, es decir, Socket.
Puerto es el concepto de la capa de transporte. La IP de origen y la IP de destino se agregarán al encabezado IP en la capa de red.
Sequence number seq:
ocupa 4 bytes, se utiliza para marcar la secuencia del segmento de datos, TCP codifica todos los bytes de datos enviados en la conexión con un número de secuencia, y el número del primer byte se genera de forma aleatoria localmente; codifica el byte después de la secuencia se agrega un número, se asigna un número de secuencia a cada segmento; el número de secuencia seq es el número de datos del primer byte de este segmento.
Número de acuse de recibo ack:
ocupa 4 bytes, esperando recibir el
número de secuencia del primer byte de datos del siguiente segmento de mensaje de la otra parte; el número de secuencia representa el número del primer byte de datos transportados en el segmento de mensaje; y el número de confirmación se refiere a Es el número del próximo byte que se espera recibir; por lo tanto, el número del último byte del segmento actual +1 es el número de confirmación.
Sincronización SYN: se utiliza para sincronizar el número de serie cuando se establece la conexión.
Cuando SYN = 1 y ACK = 0, significa: este es un segmento de solicitud de conexión. Si se acuerda la conexión, SYN = 1 y ACK = 1 en el segmento de respuesta.
Por lo tanto, SYN = 1 significa que se trata de una solicitud de conexión o un mensaje de aceptación de conexión.
El indicador SYN se establecerá en 1 solo cuando se establezca la conexión TCP, y el indicador SYN se establecerá en 0 después de que se complete el protocolo de enlace.
Acuse de recibo ACK:
ocupa 1 bit, solo cuando ACK = 1, el campo del número de confirmación es válido. Cuando ACK = 0, el número de confirmación no es válido
Finalizar FIN: se
utiliza para liberar una conexión.
FIN = 1 significa: los datos del remitente de este segmento se han enviado y se requiere liberar la conexión de transporte
Tamaño de ventana
Indica el tamaño de ventana utilizado para almacenar el segmento de datos entrantes en el host que envía este segmento de datos TCP, es decir, el número máximo de bytes que el remitente puede recibir actualmente. El valor del campo "tamaño de la ventana" le dice al host que recibe este segmento de datos que, a partir del valor del "número de confirmación" establecido en este segmento de datos, el número de bytes que el extremo local actualmente permite que el extremo opuesto envíe es se utiliza como configuración para que el otro extremo envíe La base del tamaño de la ventana.

Por qué TCP es una conexión confiable

Verificación, número de serie, confirmación, retransmisión.

Mecanismo de numeración de bytes El
segmento de datos TCP se 数据部分numera uno por uno en el segmento de datos en bytes para garantizar que los datos de cada byte se puedan transmitir y recibir en orden.
En la parte de "datos" del segmento de datos enviado por TCP (excluyendo el encabezado del segmento de datos TCP), cada byte tiene un número de secuencia, y el campo "número de secuencia" en cada segmento de datos se basa en el primer byte en el segmento de datos Se completa el número de serie.
El mecanismo de reconocimiento de segmento de datos
TCP requiere que cada vez que se recibe un segmento de datos, el receptor debe devolver un segmento de datos de reconocimiento ACK al remitente. El número de reconocimiento indica el número de secuencia del segmento de datos de la interfaz correcta en el receptor (todos los segmentos de datos antes del número de confirmación).
ACK es una bandera que indica si el campo "número de reconocimiento" es válido. Solo el valor del campo ACK es 1, el "número de confirmación" en el segmento de datos es significativo; de lo contrario, el "número de confirmación" en el segmento de datos no tiene sentido, es decir, no tiene el significado del "número de confirmación" mencionado anteriormente.
- TCP puede enviar varios segmentos de datos de forma continua a la vez. TCP puede enviar varios segmentos de datos de forma continua a la vez
  sin esperar a recibir el segmento de datos de confirmación enviado por la otra parte (el segmento de datos con el campo "ACK" es 1), que puede mejorar en gran medida la eficiencia de la transmisión de datos. Sin embargo, el número de segmentos de datos que se pueden enviar a la vez está limitado por el valor del campo "tamaño de ventana" devuelto por la otra parte y el tamaño de "ventana de envío" disponible actualmente. Debido a que el remitente necesita almacenar en búfer el segmento de datos que aún no ha recibido la confirmación, debe ocupar un cierto tamaño de "ventana de envío".
- Sólo se confirman los segmentos de datos recibidos de forma continua.
  Suponiendo que la longitud de cada segmento de datos es de 100 bytes, el extremo receptor ha recibido cuatro segmentos de datos con los números de secuencia 1, 101, 201 y 401. El segmento de datos con el número de secuencia 301 no se ha recibido temporalmente. En este momento, el "número de confirmación" en el segmento de datos de confirmación devuelto por el extremo receptor solo puede ser 301, no 501, es decir, solo los tres primeros segmentos de datos son El siguiente segmento de datos 401 se confirmará porque no se ha recibido el segmento de datos 301 del medio. Cuando el segmento de datos 301 se recibe más tarde, se puede devolver un segmento de datos con un "número de confirmación" de 501, lo que significa que los segmentos de datos 301 y 401 se han recibido correctamente.
- Los datos con números de serie no contiguos se almacenarán en caché primero. Por
  ejemplo, un host ha recibido sucesivamente segmentos de datos con los números de serie 1, 101, 201, 301, 601, 401, 801 y 501 del extremo opuesto (suponiendo que los datos los segmentos tienen un tamaño de 100 bytes), el host envía primero los cuatro segmentos de datos 1, 101, 201 y 301 a la capa de aplicación, y envía un segmento de datos de confirmación con un "número de confirmación" de 401 al remitente, de modo que esto se puede eliminar de la "ventana de recepción" Cuatro segmentos de datos, liberar la "ventana de recepción"; luego, los tres segmentos de datos 601, 401 y 801 se almacenan primero en la "ventana de recepción" hasta que se recibe el segmento de datos 501, y luego reorganizado en el orden de 401, 501 y 601 Y enviarlo a la capa de aplicación, y luego enviar un segmento de datos de confirmación con un "número de confirmación" de 701, para que estos tres segmentos de datos se puedan eliminar de la "ventana de recepción" y la "ventana de recepción" se libera, pero en este momento en la "ventana de recepción" todavía hay segmento de datos 801 en la caché porque el segmento de datos 701 aún no ha sido confirmado.
Hay un temporizador de retransmisión en el mecanismo de retransmisión de tiempo de espera TCP, que también se inicia al enviar un segmento de datos. Si el segmento de datos no ha sido confirmado por la otra parte antes de que expire el temporizador, el temporizador se detiene y se retransmite el segmento de datos correspondiente al número de secuencia.
TCP utiliza un algoritmo adaptativo para cambiar dinámicamente el tiempo de retransmisión del tiempo de espera.
Al mismo tiempo, también hay un mecanismo de retransmisión rápida, que se puede enviar inmediatamente sin esperar a que expire el temporizador.
Mecanismo de ACK selectivo (SACK)
Con el apoyo de SACK, solo se puede retransmitir la parte faltante de los datos, pero los datos que se han recibido correctamente no se retransmitirán.
Suponiendo que el extremo receptor ha recibido los segmentos de datos de los cinco números de secuencia 1, 101, 201, 401 y 501, al enviar el segmento de datos de confirmación con el número de confirmación 301, marque 401 en la opción de extensión SACK (el número de secuencia inicial es 401, final El número de serie es 500) y 501 (el número de serie inicial es 501, el número de serie final es 600) estos dos segmentos de datos discontinuos. En este momento, el remitente sabrá que no es necesario enviar los dos segmentos de datos 401 y 501, simplemente envíe el segmento de datos 301. Esto ahorra en gran medida los recursos de la red y también mejora la eficiencia de transmisión de datos.

control de flujo

流量控制Se basa en las consideraciones de coincidencia de velocidad de envío y recepción de datos de las dos partes de la comunicación. El objetivo final es no enviar datos demasiado rápido para que el extremo receptor pueda recibirlos a tiempo. Es un comportamiento punto a punto en ambos extremos de un enlace. Eso es para evitar que el remitente envíe datos demasiado rápido y permitir que el receptor tenga tiempo para recibirlos.

El propósito del control de flujo: no enviar datos demasiado rápido, para que el extremo receptor pueda recibirlos a tiempo
Esquema de control de flujo: TCP utiliza un mecanismo de ventana deslizante para lograr el control de flujo .
En el proceso de comunicación, el receptor ajusta dinámicamente el tamaño de la ventana de envío del remitente de acuerdo con el tamaño de su búfer de recepción, es decir, la ventana de interfaz rwnd (el receptor establece el campo de ventana del segmento de confirmación para notificar al remitente de rwnd), y El remitente envía el valor mínimo de la 取接收窗口rwndsuma 拥塞窗口cwndde la ventana .
El temporizador de persistencia
TCP establece un temporizador de persistencia para cada conexión. Siempre que una parte de la conexión TCP reciba la notificación de ventana cero de la otra parte, se inicia el temporizador de persistencia. Si el tiempo establecido por el temporizador continuo expira, se envía un segmento de la sonda con una ventana cero, y el receptor dará el valor de la ventana actual cuando reciba el segmento de la sonda. Si la ventana sigue siendo 0, el remitente restablece el temporizador de duración.

Control de congestion

Condiciones de congestión: suma de los requisitos de recursos> recursos disponibles. El
control de la congestión se basa en el ancho de banda de cada enlace en la red y las capacidades de procesamiento de datos de los dispositivos intermedios. No bloquee la transmisión de datos en la red, es decir, no envíe el los datos enviados por el extremo son mayores que la capacidad de procesamiento de datos del extremo receptor, que es un comportamiento de extremo a extremo.
Las causas de la congestión pueden ser complejas. Por ejemplo, en todo el enlace de la conexión TCP, el espacio de búfer del dispositivo de nodo es demasiado pequeño, la capacidad de reenvío de datos es demasiado baja, el ancho de banda de un determinado enlace es demasiado pequeño y la capacidad de recepción de datos de pares es baja. etc., lo que puede causar congestión en la red.
Por ejemplo, un usuario desea mejorar unilateralmente la capacidad de reenvío de datos del nodo del enrutador intermedio, pero ignora el ancho de banda de cada enlace a lo largo de la ruta. Como resultado, aunque el rendimiento de reenvío del enrutador mejora, la velocidad de reenvío de datos también aumenta. pero al mismo tiempo Como resultado, los datos en cola en el enlace continúan aumentando, lo que no solo no resuelve el problema de congestión de la red, sino que la agrava.
Para otro ejemplo, el usuario desea mejorar unilateralmente la capacidad de la caché del enrutador, pero no considera simultáneamente la capacidad de reenvío de datos del enrutador y el ancho de banda del enlace. Como resultado, aunque se pueden almacenar más datos temporalmente en el enrutador, se ponen en cola en la caché. El tiempo de espera de los datos será más largo, porque la cola es más larga que antes y, como resultado, los datos se retransmitirán debido al tiempo de espera. Cuantos más datos se retransmiten, la carga de la red será mayor, lo que eventualmente provocará una congestión más grave.
El propósito del control de la congestión: evitar que se inyecten datos excesivos en la red.
El esquema de control de congestión es:
inicio lento, evitación de congestión; retransmisión rápida, recuperación rápida
Ventana de envío = min (ventana de recepción rwnd, ventana de congestión cwnd)
Ventana de recepción: el receptor notificará al remitente de acuerdo con el valor establecido por el búfer de recepción, reflejando la capacidad del receptor.
Ventana de congestión: El valor de la ventana establecido por el remitente según el grado de congestión de la red estimado por él mismo, que refleja la capacidad actual de la red.

Inicio lento y prevención de la congestión

El inicio lento se refiere a un programa de prevención de congestión TCP inicial para evitar la congestión de la red. La idea básica es que cuando la conexión TCP transmite datos oficialmente, el tamaño 拥塞窗口de los datos que se pueden enviar cada vez se incrementa gradualmente, es decir, primero se envían algunos pequeños bytes de datos tentativos, y luego de recibir la confirmación de estos segmentos de datos. , Aumente lentamente la cantidad de datos enviados hasta que alcance un cierto límite establecido originalmente 慢启动阈值SSTHRESH.
Cuando 拥塞窗口大小CWNDes mayor o igual a SSTHRESH nuevamente, se inicia la solución de "evitación de congestión". La idea básica es que cuando el valor CWND alcanza SSDHRESH por segunda vez, el tamaño de la "ventana de congestión" solo aumentará en 1 (el nuevo CWND) después de cada RTT (el tiempo necesario para que un segmento de datos vaya y venga entre el extremo receptor y extremo emisor). Solo aumente el tamaño de un MSS en lugar de varias veces el CWND original), hágalo aumentar lentamente de manera lineal, en lugar de continuar aumentando exponencialmente como en el esquema de "inicio lento". Obviamente, esta tasa de crecimiento de CWND es obviamente más lenta que la tasa de crecimiento de CWND en el esquema de "inicio lento". Cuando la pérdida de datos vuelva a ocurrir, SSTHRESH se reducirá a la mitad del CWND actual y CWND se establecerá en 1, vuelva a ingresar al proceso de envío de datos de "inicio lento", y así sucesivamente.

El inicio lento aumenta exponencialmente hasta que se alcanza 慢启动阈值SSTHRESH, y se realiza la evasión de congestión 加法增大(lineal). Cuando se produce la pérdida de datos, la SSTHRESHmultiplicación se reduce a la mitad del valor original y, al mismo tiempo, se cwndestablece en 1 y el lento se vuelve a entrar en la fase de inicio.

Retransmisión rápida y recuperación rápida

Retransmisión rápida
Cuando el extremo receptor recibe un segmento de datos que no llega en orden, la entidad TCP envía rápidamente un segmento de datos ACK repetido, en lugar de esperar a que se envíen los datos, y envía un acuse de recibo; cuando se reciben tres segmentos de datos ACK repetidos recibido repetidamente Más tarde, se considera que el segmento de datos correspondiente al campo "número de acuse de recibo" se ha perdido y TCP no espera a que expire el temporizador de retransmisión antes de retransmitir el segmento de datos que parece haberse perdido.
La idea básica del algoritmo de recuperación rápida de recuperación rápida: cuando se recibe el tercer ACK repetido, el valor actual de CWND se establece en la mitad del valor actual de SSTHRESH para reducir la carga de la red, y luego el algoritmo de "prevención de congestión" introducido anteriormente se ejecuta para hacer que el valor CWND aumente lentamente para evitar nuevamente la congestión de la red.

Referencia:
control de flujo TCP, control de congestión

Protocolo de enlace de tres vías TCP

Tres apretón de manos

Al establecer una conexión: el
cliente envía un paquete de sincronización (seq = x, SYN = 1) al servidor y entra en el estado SYN_SENT , esperando que el servidor confirme.
El servidor recibe el paquete syn:
debe confirmar el SYN del cliente y al mismo tiempo enviar un paquete SYN, a saber, paquete SYN + ACK (seq = y, ack = x + 1, SYN = 1, ACK = 1), y el servidor entra en el estado SYN_RECV ;
El cliente recibe el paquete SYN + ACK
del servidor : envía un paquete de acuse de recibo ACK (seq = x + 1, ack = y + 1, ACK = 1) al servidor, este paquete se envía y el cliente y el servidor ingresan ESTABLISHED (La conexión TCP es exitosa) Estado , complete el protocolo de enlace de tres vías.

Saludar cuatro veces

El proceso del cliente envía un mensaje de liberación de conexión (seq = u, FIN = 1) y deja de enviar datos.
En este momento, el cliente entra en el estado FIN-WAIT-1 (terminación en espera 1) .
TCP estipula que incluso si el segmento FIN no transporta datos, consumirá un número de secuencia.
El servidor recibe el mensaje de liberación de conexión y envía un mensaje de confirmación (seq = v, ack = u + 1, ACK = 1)
En este momento, el servidor entra en el estado CERRAR-ESPERA .
El servidor TCP notifica al proceso de aplicación de alto nivel que el cliente se libera en la dirección del servidor. En este momento, está en un estado medio cerrado, es decir, el cliente no tiene datos para enviar, pero si el servidor envía datos, el cliente aún tiene que aceptarlos . Este estado continuará por un tiempo, es decir, la duración de todo el estado CLOSE-WAIT.
Después de que el cliente recibe la solicitud de confirmación del servidor, el cliente ingresa al estado FIN-WAIT-2 (terminación en espera 2) y
espera que el servidor envíe un mensaje de liberación de conexión (antes de eso, debe aceptar los últimos datos enviados por el servidor ).
Después de que el servidor envía los datos finales, envía un mensaje de liberación de conexión al cliente (seq = v + 1, ack = u + 1, FIN = 1, ACK = 1). Dado que el servidor está en un estado semicerrado, es probable que el servidor sea Se envían algunos datos, asumiendo que el número de serie en este momento es seq = w, en este momento, el servidor entra en el estado LAST-ACK (última confirmación) , esperando la confirmación del cliente.
Una vez que el cliente recibe el mensaje de liberación de conexión del servidor, debe enviar un acuse de recibo (seq = u + 1, ack = w + 1, ACK = 1) y entrar en el estado TIME-WAIT . Tenga en cuenta que la conexión TCP no se ha liberado en este momento. Debe pasar 2 * MSL (la vida más larga del segmento de mensaje) y el cliente puede ingresar al estado CERRADO después de cancelar el mensaje correspondiente.
Siempre que el servidor reciba la confirmación del cliente, ingresará inmediatamente al estado CERRADO . De manera similar, después de que se retira la TCB, la conexión TCP finaliza. Como puede ver, el servidor finaliza la conexión TCP antes que el cliente.

Introducción a TCP Fast Open

La primera vez que el
usuario envía un paquete SYN al servidor y solicita una cookie TFO, el
servidor genera una cookie de acuerdo con el cifrado de IP del usuario y la envía al usuario junto con el SYN-ACK El
usuario almacena la cookie TFO
Tercero: el
usuario envía un paquete SYN (que lleva una cookie TCP) al servidor con una solicitud; el
servidor comprueba la cookie (descifra la cookie y compara la dirección IP o vuelve a cifrar la dirección IP para compararla con la cookie recibida).
Si la verificación es exitosa, envíe SYN + ACK al usuario, antes de que el usuario responda ACK, pueda transmitir datos al usuario; (1RTT)
Si la verificación falla, descarte los datos transportados en la solicitud TFO, responda SYN-ACK para confirmar SYN Seq, y la finalización es un protocolo de enlace de tres normal.
Dos beneficios principales de TFO:
mejorar la utilización de la red (los datos de la aplicación se pueden transmitir durante el protocolo de enlace de tres vías, 1RTT) y
mejorar la seguridad de la red (puede evitar los ataques de inundación SYN).

Síndrome de la ventana tonta

Los esquemas de control de flujo basados en ventanas, como los que utiliza TCP, pueden conducir a una situación conocida como "Síndrome de la ventana tonta (SWS)". Si esto sucede, se intercambiará una pequeña cantidad de datos a través de la conexión en lugar de un mensaje completo.
Este fenómeno puede ocurrir en cualquier extremo: el receptor puede anunciar una ventana pequeña (en lugar de esperar hasta que haya una ventana grande), y el remitente también puede enviar una pequeña cantidad de datos (en lugar de esperar otros datos) para enviar un gran segmento). Se pueden tomar medidas en cualquier extremo para evitar el fenómeno del síndrome de la ventana confusa.

Este problema se puede atribuir al problema de los paquetes pequeños, que se debe a la inconsistencia del procesamiento en el extremo emisor y el extremo receptor, lo que resulta en muchos paquetes pequeños en la red. Las medidas para evitar demasiados paquetes pequeños en la red han introducido antes, como el algoritmo de Nagle. Bajo el mecanismo de ventana deslizante, si las tasas del remitente y el receptor son muy inconsistentes, también ocurrirá este tipo de estado tonto: los datos enviados por el remitente solo necesitan un encabezado grande y contienen muy pocos datos.
Para el extremo receptor, si el extremo receptor es muy lento, recibiendo 1 byte o varios bytes a la vez, el búfer del extremo receptor se llenará rápidamente en este momento, y luego la ventana se anunciará como 0 bytes y el el final del envío se detendrá en este momento El envío, después de que la aplicación reciba 1 byte, la ventana de notificación es de 1 byte. Después de que el remitente recibe la notificación, envía 1 byte de datos. De esta manera, la eficiencia de transmisión será muy baja.
Al mismo tiempo, si el programa remitente envía un byte a la vez, aunque la ventana es lo suficientemente grande, la transmisión sigue siendo byte a byte, lo cual es muy ineficiente.

Referencia:
Lectura rápida de TCP / IP original (síndrome de ventana confusa)
TCP-IP detallado: síndrome de ventana confusa

Preguntas y respuestas

1. ¿Por qué hay un apretón de manos de tres vías cuando se conecta, pero un apretón de manos de cuatro vías cuando se cierra?

Porque cuando el lado del servidor recibe el mensaje de solicitud de conexión SYN del lado del cliente, puede enviar un mensaje SYN + ACK directamente.
Sin embargo, cuando se cierra la conexión, cuando el servidor recibe un mensaje FIN, es posible que no cierre inmediatamente SOCKET, por lo que solo puede responder con un mensaje ACK y decirle al cliente: "Recibí el mensaje FIN que enviaste". Solo después de que se hayan enviado todos los mensajes de mi servidor, puedo enviar mensajes FIN, por lo que no puedo enviarlos juntos. Por lo tanto, se requiere un apretón de manos de cuatro pasos.

2. ¿Por qué el estado TIME_WAIT necesita pasar 2MSL (tiempo máximo de supervivencia del segmento) antes de volver al estado CLOSE?

Aunque es razonable decir que se han enviado los cuatro paquetes, podemos entrar directamente en el estado CERRAR, pero debemos asumir que la red no es confiable y se puede perder el último ACK. Por tanto, el estado TIME_WAIT se utiliza para retransmitir los paquetes ACK que pueden perderse.
El cliente envía la respuesta ACK final, pero el ACK puede perderse. ** Si el servidor no recibe un ACK, continuará enviando fragmentos FIN repetidamente. ** Por lo tanto, el Cliente no se puede cerrar inmediatamente, debe confirmar que el Servidor ha recibido el ACK.
El Cliente entrará en el estado TIME_WAIT después de enviar el ACK. El cliente establecerá un temporizador para esperar 2MSL. Si el FIN se recibe nuevamente dentro de este tiempo, el Cliente reenviará el ACK y esperará 2MSL nuevamente.
Si el Cliente no recibe el FIN nuevamente hasta 2MSL, el Cliente concluye que el ACK se ha recibido correctamente y finaliza la conexión TCP.
El llamado 2MSL es el doble del MSL (Duración máxima del segmento). MSL se refiere al tiempo máximo de supervivencia de un segmento en la red, y 2MSL es el tiempo máximo requerido para una transmisión y una respuesta.

3. ¿Qué pasa si se ha establecido la conexión, pero el cliente falla repentinamente?

TCP tiene un temporizador de mantenimiento de vida Obviamente, si el cliente falla, el servidor no puede esperar eternamente y se desperdician recursos. El servidor restablecerá este temporizador cada vez que reciba una solicitud del cliente. El tiempo generalmente se establece en 2 horas. Si no ha recibido ningún dato del cliente durante dos horas, el servidor enviará un segmento de sondeo y luego cada 75 enviados cada segundo. Si aún no hay respuesta después de enviar 10 paquetes de sondeo, el servidor considera que el cliente está defectuoso y luego cierra la conexión.

4. ¿Por qué no puedo conectarme con dos apretones de manos?

En primer lugar, debemos saber que el canal no es confiable, pero debemos establecer una conexión confiable para enviar datos confiables, es decir, la transmisión de datos debe ser confiable. En este momento, el protocolo de enlace de tres vías es un mínimo teórico, por no decir que es requerido por el protocolo tcp, pero para cumplir con los requisitos para transmitir datos confiables en canales no confiables.
En el libro "Computer Network" se menciona que el propósito del protocolo de enlace de tres vías es "evitar que el segmento de solicitud de conexión no válida se transmita al servidor de repente, lo que provoca un error .
Esta situación es: cliente A La primera conexión El mensaje de solicitud enviado no se perdió, pero se atascó en un determinado nodo de red debido a alguna razón desconocida, lo que provocó que la demora llegara al otro extremo (servidor) B hasta cierto tiempo después de que se liberó la conexión. Originalmente, esto no era válido segmento de mensaje, pero después de que B recibió el mensaje inválido, pensó erróneamente que era una nueva solicitud de conexión enviada por A nuevamente, por lo que el lado B envió un mensaje de confirmación a A nuevamente, expresando su acuerdo Establezca una conexión. Si el "protocolo de enlace de tres vías "no se usa, entonces mientras el lado B envíe un mensaje de acuse de recibo, pensará que se ha establecido la nueva conexión, pero el lado A no ha enviado una solicitud de establecimiento de conexión, por lo que no enviará datos al lado B . Si el extremo no recibe los datos, esperará para siempre, por lo que el extremo B desperdiciará muchos recursos.
Si se usa el "apretón de manos de tres vías", esto no sucederá. Después de que el extremo B reciba un mensaje obsoleto y segmento inválido, lo hará El lado A envía una confirmación. En este momento, A no solicita establecer una conexión, por lo que no enviará una confirmación al lado B. En este momento, el lado B también puede saber que la conexión no está establecido.

Referencia:
Apretón de manos de tres vías de TCP y preguntas de entrevista y comprensión de cuatro manos agitadas