1. Tres apretones de manos y cuatro ondas

A continuación se muestra el diagrama de transición de estado de tres apretones de manos y cuatro manos de onda:

(1) Estado de protocolo de enlace de tres vías

ESCUCHAR: el servidor comienza a entrar en el estado ESCUCHAR después de llamar a la función de escucha;
SYN_SENT: después de que el cliente llama a la función de conexión, entra en el estado SYN-SENT antes de que vuelva la función de conexión;
SYN_RECEIVED: el servidor entra en el estado SYN_RECEIVED después de recibir el SYN y enviar un ACK;
ESTABLECIDO: Representa una conexión abierta. Una vez que regresa la función de conexión del cliente, ingresa al estado ESTABLECIDO y el servidor ingresa al estado ESTABLECIDO después de recibir la confirmación ACK del cliente.

(2) Estado de cuatro ondas

FIN_WAIT1: Cuando el Cliente llama a la función de cierre, entra en el estado FIN_WAIT1;
FIN_WAIT2: Cuando vuelve la función de cierre del cliente, entra en el estado de FIN_WAIT2;
CLOSE_WAIT: El servidor entra en el estado CLOSE_WAIT después de recibir la solicitud FIN del Cliente, y este estado continúa hasta que el servidor llama a la función de cierre;
LAST_ACK: el servidor entra en el estado LAST_ACK después de llamar a la función de cierre;
TIME_WAIT: el cliente entra en el estado TIME_WAIT después de recibir la solicitud de conexión del servidor y luego responde con un ACK al servidor;
CERRADO: el cliente entra en el estado CERRADO después de esperar 2MSL y el servidor entra en el estado CERRADO después de recibir la confirmación ACK del cliente.

2. ¿Por qué necesita un apretón de manos de tres vías?

El propósito del protocolo de enlace de tres vías es " para evitar que el segmento de solicitud de conexión no válida se transmita repentinamente al servidor, lo que resultará en errores ":

Esta situación es: el primer mensaje de solicitud de conexión enviado por el cliente A no se pierde, pero se atasca en un nodo de red por alguna razón desconocida, lo que resulta en un retraso hasta cierto tiempo después de que se libera la conexión. fin (servidor) B. Originalmente, este era un segmento de mensaje inválido, pero después de que B recibió el mensaje inválido, creyó 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 para establecer conexión. Si no se utiliza el "protocolo de enlace de tres vías", siempre que el lado B envíe un mensaje de acuse de recibo, considerará que se ha establecido la nueva conexión, pero el lado A no ha enviado una solicitud para establecer una conexión, por lo que no enviará datos al lado B, y el lado B no los ha recibido. Hasta que se alcancen los datos, esperará eternamente, por lo que el lado B desperdiciará muchos recursos en vano. Si se usa el "protocolo de enlace de tres vías", esta situación no ocurrirá. Después de recibir un segmento desactualizado e inválido, el lado B envía un acuse de recibo al lado A. En este momento, A no solicita establecer una conexión, por lo que no enviará al lado B. Envíe la confirmación, en este momento el extremo B también puede saber que la conexión no está establecida.

3. ¿Por qué necesitas TIME_WAIT?

(1) Asegúrese de que la conexión full-duplex del protocolo TCP se pueda cerrar de manera confiable

Permítanme hablar sobre el primer punto: si el Cliente está CERRADO directamente, entonces el Servidor no recibió el último ACK del Cliente debido a la falta de confiabilidad del protocolo IP u otras razones de la red. Luego, el servidor continuará enviando el FIN después del tiempo de espera. En este momento, dado que el cliente está CERRADO, no se puede encontrar la conexión correspondiente al FIN retransmitido. Finalmente, el servidor recibirá un RST en lugar de un ACK, y el servidor pensará que es un error de conexión Informe el problema a la alta dirección. Aunque tal situación no causará pérdida de datos, sí hace que el protocolo TCP no cumpla con los requisitos de una conexión confiable. Por lo tanto, el Cliente no ingresa CLOSED directamente, sino que mantiene TIME_WAIT, al recibir FIN nuevamente, puede asegurarse de que la otra parte reciba ACK y finalmente cierre la conexión correctamente.

(2) Asegúrese de que el segmento de datos repetidos de esta conexión desaparezca de la red

Permítanme hablar sobre el segundo punto: si el Cliente CERRÓ directamente y luego inicia una nueva conexión con el Servidor, no podemos garantizar que el número de puerto de esta nueva conexión sea diferente del número de puerto de la conexión recién cerrada. En otras palabras, es posible que los números de puerto de la nueva conexión y la antigua sean los mismos. En términos generales, no se producirán problemas, pero aún existen circunstancias especiales: suponiendo que el número de puerto de la nueva conexión y la antigua conexión que se ha cerrado son los mismos, si algunos datos de la conexión anterior siguen atascados en la red, estos datos retrasados se están estableciendo El servidor llega después de la nueva conexión. Debido a que los números de puerto de la nueva conexión y la conexión anterior son los mismos, y debido a que el protocolo TCP juzga diferentes conexiones según el par de sockets, el protocolo TCP considera el retraso los datos pertenecen a la nueva conexión y se confunden con el paquete de datos de la nueva conexión real. Por lo tanto, la conexión TCP tiene que esperar 2 veces el MSL en el estado TIME_WAIT, para asegurarse de que todos los datos de esta conexión desaparezcan de la red.

4. Razones para CLOSE_WAIT

Cuándo aparece CLOSE_WAIT: después de recibir el mensaje FIN del Cliente en el lado del servidor;
¿Cuándo CLOSE_WAIT pasa al siguiente estado: después de que el servidor envía un mensaje FIN al cliente?

Si el servidor no ha enviado un mensaje FIN al cliente (llamando a la API close ()), entonces este CLOSE_WAIT siempre existirá. Se puede ver que aparece CLOSE_WAIT, que es básicamente un problema con el programa del lado del servidor del usuario; generalmente, el servidor está esperando que el cliente acceda, si el cliente sale y solicita cerrar la conexión, el lado del servidor se cierra conscientemente ( ) la conexión correspondiente.

Solución:

Cuando el servidor no lee o escribe, puede optar por cerrar la conexión;
Envíe periódicamente datos de consulta a la conexión y verifique el paquete de datos de respuesta recibido (el hilo Heart-Beat envía un paquete de datos de latido en el formato especificado);
Modifique los parámetros de mantenimiento en vivo (tiempo de espera, tiempo de intervalo de verificación de tcp: el intervalo entre el envío de paquetes de sondeo de keeplive, tiempos de verificación de tcp: si la otra parte no responde, el número de paquetes de sondeo enviados);

5 、 TCP 之 Keepalive

Usando el software de modo C / S para la conexión TCP, cuando ambas partes de la conexión están en estado inactivo, si alguna de las partes falla inesperadamente, falla, el cable de red está desconectado o el enrutador falla, la otra parte no puede saber que la conexión TCP ha fallado, a menos que la conexión continúe aquí. El envío de datos provoca la devolución de un error. Muchas veces, esto no es lo que necesitamos. Esperamos que tanto el servidor como el cliente puedan detectar la falla de conexión de manera oportuna y efectiva, y luego completar con gracia un trabajo de limpieza e informar el error al usuario. Cómo detectar la desconexión anormal de una de las partes de manera oportuna y efectiva, siempre ha habido dos técnicas que se pueden utilizar. Uno es el Keepalive implementado por la capa de protocolo TCP y el otro es el paquete de latido implementado por la propia capa de aplicación.

A y B ambos lados establecieron una conexión TCP a través de un apretón de manos de tres vías, y luego repentinamente B cayó. Después de eso, B nunca volvió a levantarse. Si A y B no tienen requisitos de comunicación de datos después de que B deja de funcionar, A nunca encontrará que B ha colgado, entonces el kernel de A también mantiene información sobre la conexión TCP entre A&B, lo que desperdicia recursos del sistema. Por lo tanto, se introduce un mecanismo keepalive a nivel TCP. A enviará periódicamente paquetes de datos vacíos a B, que es un paquete de latido en términos sencillos. Una vez que encuentra que la red de B no está disponible, cierra la conexión. Esto es especialmente obvio en LVS, porque LVS mantiene una gran cantidad de información sobre el estado de la conexión en ambos lados, y la conexión debe liberarse una vez que se agota el tiempo de espera. TCP no habilita la función Keepalive de forma predeterminada, porque habilitar la función Keepalive requiere ancho de banda y tráfico adicionales. Aunque esto es trivial, aumenta el costo en un entorno basado en el tráfico. Por otro lado, si la configuración de Keepalive no es razonable, puede ser de corta duración La red fluctúa y la conexión TCP en buen estado se desconecta.

El ajuste de tcp keepalive por el kernel de Linux tiene principalmente los siguientes tres parámetros:

$ cat /proc/sys/net/ipv4/tcp_keepalive_time
  7200
$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl
  75
$ cat /proc/sys/net/ipv4/tcp_keepalive_probes
  9

Cuando tcp descubre que tcp_keepalive_time (7200) segundos no ha recibido datos del par, comienza a enviar paquetes de latidos huecos en un intervalo de tcp_keepalive_intvl (75) segundos. Si tcp_keepalive_probes (9) veces consecutivas no han respondido al código, el par ha estado inactivo, cierre la conexión.

Cosas de TCP

1. Tres apretones de manos y cuatro ondas

2. ¿Por qué necesita un apretón de manos de tres vías?

3. ¿Por qué necesitas TIME_WAIT?

4. Razones para CLOSE_WAIT

5 、 TCP 之 Keepalive

Supongo que te gusta