Apretón de manos TCP de tres vías y apretón de manos de cuatro vías, ¿qué sucede si falla en el medio?

Autor: Fundación informática gráfica de codificación Kobayashi (sistema operativo, red informática, composición informática, base de datos, etc.) Sitio web: https://xiaolincoding.com

Hola a todos, soy Xiaolin.

He escrito un artículo sobre lo que sucede cuando un paquete se pierde en un determinado paso durante el protocolo de enlace de tres vías y el protocolo de enlace de cuatro vías de TCP.

En ese momento, era principalmente una descripción de texto, que puede no ser fácil de recordar, por lo que volví a dibujar la imagen para la situación anormal de cada paso, para que todos puedan entender y recordar.

¡Vamos!

imagen

Pérdida de paquete de protocolo de enlace de tres vías TCP

Se pierde el primer apretón de manos, ¿qué pasa?

Cuando el cliente quiere establecer una conexión TCP con el servidor, lo primero que debe enviar es el mensaje SYN, para luego ingresar SYN_SENTel estado .

Después de eso, si el cliente no recibe el mensaje SYN-ACK del servidor (el segundo protocolo de enlace), activará el mecanismo de "retransmisión de tiempo de espera" para retransmitir el mensaje SYN, y el mensaje SYN retransmitido Los números de serie son los mismos .

Las diferentes versiones del sistema operativo pueden tener diferentes tiempos de espera, algunos son de 1 segundo y otros de 3 segundos. Este tiempo de espera está codificado en el kernel. Si desea cambiarlo, debe volver a compilar el kernel, lo cual es problemático.

Cuando el cliente no recibe el mensaje SYN-ACK del servidor después de 1 segundo, el cliente reenviará el mensaje SYN, ¿cuántas veces se reenviará?

En Linux, el número máximo de retransmisiones del mensaje SYN del cliente está controlado por un parámetro tcp_syn_retriesdel kernel , que se puede personalizar, y el valor predeterminado es generalmente 5.

# cat /proc/sys/net/ipv4/tcp_syn_retries
5

Por lo general, la primera retransmisión de tiempo de espera es después de 1 segundo, la segunda retransmisión de tiempo de espera es después de 2 segundos, la tercera retransmisión de tiempo de espera es después de 4 segundos, la cuarta retransmisión de tiempo de espera es después de 8 segundos y la segunda retransmisión de tiempo de espera es después de 8 segundos. después de retransmitir con un tiempo de espera de 16 segundos. Así es, cada tiempo de espera tarda el doble que el anterior .

Después de la quinta retransmisión de tiempo extra, continuará esperando durante los segundos 32. Si el servidor aún no responde con ACK, el cliente ya no enviará paquetes SYN y luego desconectará la conexión TCP.

Por lo tanto, el tiempo total que consume es 1+2+4+8+16+32=63 segundos, aproximadamente 1 minuto.

Por ejemplo, asumiendo que el valor del parámetro de tcp_syn_retries es 3, entonces cuando el mensaje SYN del cliente siempre se pierde en la red, ocurrirá el siguiente proceso:

imagen

Proceso específico:

Cuando el cliente retransmite el mensaje SYN 3 veces extra, ya que tcp_syn_retries es 3, se ha alcanzado el número máximo de retransmisiones, así que espere un momento (el tiempo es el doble del tiempo de espera anterior), si el servidor aún no recibe El segundo apretón de manos (mensaje SYN-ACK), luego el cliente se desconectará.

Se pierde el segundo apretón de manos, ¿qué sucede?

Cuando el servidor recibe el primer protocolo de enlace del cliente, devolverá un mensaje SYN-ACK al cliente. Este es el segundo protocolo de enlace, y el servidor entrará SYN_RCVDen el estado

El segundo SYN-ACKmensaje en realidad tiene dos propósitos:

El ACK en el segundo protocolo de enlace es el mensaje de confirmación para el primer protocolo de enlace;
El SYN en el segundo protocolo de enlace es un mensaje iniciado por el servidor para establecer una conexión TCP;

Entonces, si se pierde el segundo apretón de manos, sucederá algo más interesante.

Debido a que el segundo mensaje de protocolo de enlace contiene el mensaje de confirmación ACK del primer protocolo de enlace al cliente, si el cliente no ha recibido el segundo protocolo de enlace durante mucho tiempo, entonces el cliente piensa que su propio mensaje SYN (El primer protocolo de enlace) se ha perdido, por lo que el cliente activará el mecanismo de retransmisión de tiempo de espera y retransmitirá el mensaje SYN .

Luego, debido a que el segundo protocolo de enlace contiene el mensaje SYN del servidor, cuando el cliente lo recibe, debe enviar un mensaje de confirmación ACK al servidor (el tercer protocolo de enlace), y el servidor pensará que el mensaje SYN ha sido recibido por el cliente. .fin recibido.

Luego, si se pierde el segundo protocolo de enlace, el servidor no recibirá el tercer protocolo de enlace, por lo que el servidor activará un mecanismo de retransmisión de tiempo de espera para retransmitir el mensaje SYN-ACK .

En Linux, la cantidad máxima de retransmisiones de paquetes SYN-ACK está determinada por los parámetros tcp_synack_retriesdel kernel y el valor predeterminado es 5.

# cat /proc/sys/net/ipv4/tcp_synack_retries
5

Por lo tanto, cuando se pierde el segundo protocolo de enlace, tanto el cliente como el servidor retransmiten:

El cliente retransmitirá el mensaje SYN, que es el primer protocolo de enlace, y el número máximo de retransmisiones está determinado por los parámetros tcp_syn_retriesdel kernel ;
El servidor retransmitirá el mensaje SYN-ACK, que es el segundo protocolo de enlace, y el número máximo de retransmisiones está determinado por los parámetros tcp_synack_retriesdel kernel .

Por ejemplo, suponga que el valor del parámetro de tcp_syn_retries es 1 y el valor del parámetro de tcp_synack_retries es 2, luego, cuando el segundo protocolo de enlace siempre se pierde, el proceso que ocurre es el siguiente:

imagen

Proceso específico:

Cuando el cliente retransmite un mensaje SYN una vez extra, dado que tcp_syn_retries es 1, se ha alcanzado el número máximo de retransmisiones, así que espere un momento (el tiempo es el doble del tiempo de espera anterior), si aún no recibe el SYN mensaje del servidor El segundo protocolo de enlace (mensaje SYN-ACK), luego el cliente se desconectará.
Cuando el servidor retransmite el mensaje SYN-ACK 2 veces extra, ya que tcp_synack_retries es 2, se ha alcanzado el número máximo de retransmisiones, así que espere un momento (el tiempo es el doble del tiempo de espera anterior), si aún falla recibe el tercer protocolo de enlace del cliente (mensaje ACK), luego el servidor se desconectará.

Se pierde el tercer apretón de manos, ¿qué pasa?

Después de que el cliente recibe el mensaje SYN-ACK del servidor, devolverá un mensaje ACK al servidor, que es el tercer protocolo de enlace, y el estado del cliente ingresa ESTABLISHal estado

Debido a que el ACK del tercer protocolo de enlace es el mensaje de confirmación del SYN del segundo protocolo de enlace, cuando se pierde el tercer protocolo de enlace, si el lado del servidor no recibe el mensaje de confirmación, se activará un reinicio de tiempo de espera. mensaje SYN-ACK hasta que se recibe el tercer protocolo de enlace o se alcanza el número máximo de retransmisiones.

Tenga en cuenta que el mensaje ACK no se retransmitirá. Cuando se pierda el ACK, la otra parte retransmitirá el mensaje correspondiente .

Por ejemplo, suponiendo que el valor del parámetro de tcp_synack_retries es 2, cuando se pierde el tercer protocolo de enlace, el proceso que se produce es el siguiente:

imagen

Proceso específico:

Cuando el servidor retransmite el mensaje SYN-ACK 2 veces extra, ya que tcp_synack_retries es 2, se ha alcanzado el número máximo de retransmisiones, así que espere un momento (el tiempo es el doble del tiempo de espera anterior), si aún falla recibe el tercer protocolo de enlace del cliente (mensaje ACK), luego el servidor se desconectará.

Situación de pérdida de paquetes de cuatro ondas TCP

La primera oleada se pierde, ¿qué sucede?

Cuando el cliente (cerrando activamente la fiesta) llama a la función de cierre, enviará un mensaje FIN al servidor, tratando de desconectarse del servidor, y la conexión del cliente ingresa FIN_WAIT_1al estado

En circunstancias normales, si el ACK del servidor (la parte pasiva de cierre) se puede recibir a tiempo, cambiará rápidamente al FIN_WAIT2estado .

Si se pierde la primera onda y el cliente no recibe el ACK de la parte pasiva, activará el mecanismo de retransmisión de tiempo de espera y retransmitirá el mensaje FIN. El número de retransmisiones se controla mediante tcp_orphan_retriesparámetros

Cuando la cantidad de veces que el cliente retransmite el mensaje FIN tcp_orphan_retriesexcede , ya no enviará el mensaje FIN y esperará un período de tiempo (el tiempo es el doble del tiempo de espera anterior), si aún no recibe el mensaje segunda ola, luego ir directamente al closeestado .

Por ejemplo, asumiendo que el valor del parámetro de tcp_orphan_retries es 3, cuando la primera ola siempre se pierde, el proceso que ocurre es el siguiente:

imagen

Proceso específico:

Cuando el cliente retransmite el mensaje FIN 3 veces después del tiempo de espera, porque tcp_orphan_retries es 3, se alcanzó el número máximo de retransmisiones, así que espere un momento (el tiempo es el doble del tiempo de espera anterior), si el servidor sigue fallando para recibir la segunda ola (mensaje ACK), luego el cliente se desconectará.

La segunda ola se pierde, ¿qué pasa?

Cuando el servidor recibe el primer saludo del cliente, primero devolverá un mensaje de confirmación ACK, y la conexión del servidor ingresa CLOSE_WAITal estado .

También mencionamos anteriormente que el mensaje ACK no se retransmitirá, por lo que si se pierde la segunda onda del servidor, el cliente activará el mecanismo de retransmisión de tiempo de espera y retransmitirá el mensaje FIN hasta que reciba la primera onda del servidor. número de retransmisiones.

Por ejemplo, asumiendo que el valor del parámetro de tcp_orphan_retries es 2, cuando la segunda ola siempre se pierde, el proceso que ocurre es el siguiente:

imagen

Proceso específico:

Cuando el cliente retransmite el mensaje FIN 2 veces extra, porque tcp_orphan_retries es 2, se ha alcanzado el número máximo de retransmisiones, así que espere un período de tiempo (el tiempo es el doble del tiempo de espera anterior), si el servidor sigue fallando para recibir la segunda ola (mensaje ACK), luego el cliente se desconectará.

Permítanme mencionar aquí que cuando el cliente recibe la segunda ola, es decir, después de recibir el mensaje ACK enviado por el servidor, el cliente estará en FIN_WAIT2el estado En este estado, debe esperar a que el servidor envíe la tercera ola , es decir, el final del servicio del mensaje FIN.

Para la conexión cerrada por la función de cierre, dado que ya no se pueden enviar ni recibir datos, FIN_WAIT2el estado no puede durar demasiado y tcp_fin_timeoutcontrola la duración de la conexión en este estado, y el valor predeterminado es 60 segundos.

Esto significa que para la conexión cerrada llamando a close, si no se recibe mensaje FIN después de 60 segundos, la conexión del cliente (cierre activo) se cerrará directamente, como se muestra en la siguiente figura:

imagen

Tenga en cuenta, sin embargo, que si la parte de cierre activa usa la función de cierre para cerrar la conexión, especificando que solo se cierra la dirección de envío, pero la dirección de recepción no está cerrada, significa que la parte de cierre activa aún puede recibir datos.

En este momento, si el cierre activo no ha recibido la tercera onda, la conexión del cierre activo siempre estará en FIN_WAIT2el estado ( tcp_fin_timeoutla conexión cerrada por apagado no se puede controlar). Como se muestra abajo:

imagen

La tercera ola se pierde, ¿qué pasa?

Cuando el servidor (parte de cierre pasiva) recibe el mensaje FIN del cliente (parte de cierre activa), el kernel responderá automáticamente ACK, y la conexión está en CLOSE_WAITel estado de

En este momento, el kernel no tiene derecho a reemplazar el proceso para cerrar la conexión, y el proceso debe llamar activamente a la función de cierre para que el servidor envíe un mensaje FIN.

Cuando el servidor está en el estado CLOSE_WAIT y se llama a la función de cierre, el núcleo enviará un mensaje FIN y la conexión entrará en el estado LAST_ACK al mismo tiempo, esperando que el cliente devuelva ACK para confirmar que la conexión está cerrada.

Si el ACK no se recibe durante mucho tiempo, el servidor reenviará el mensaje FIN, y el número de retransmisiones todavía está tcp_orphan_retriecontrolado por el parámetro s, que es el mismo que el método de control del número de retransmisiones del mensaje FIN reenviado. por el cliente

Por ejemplo, suponiendo tcp_orphan_retries = 3, cuando la tercera onda siempre se pierde, el proceso que ocurre es el siguiente:

imagen

Proceso específico:

Cuando la cantidad de veces que el servidor retransmite el tercer mensaje de activación llega a 3 veces, dado que tcp_orphan_retries es 3, se alcanza la cantidad máxima de retransmisiones, así que espere un momento (el tiempo es el doble del tiempo de espera anterior), si todavía Si la cuarta onda (mensaje ACK) del cliente no se recibe, el servidor se desconectará.
Debido a que el cliente cierra la conexión a través de la función de cierre, existe un límite de tiempo en el estado FIN_WAIT_2.Si aún no se recibe la tercera ola (mensaje FIN) del servidor dentro del tiempo tcp_fin_timeout, el cliente se desconectará.

La cuarta ola se pierde, ¿qué pasa?

Cuando el cliente recibe el mensaje FIN de la onda de la tercera mano del servidor, devolverá un mensaje ACK, es decir, la onda de la cuarta mano, y la conexión del cliente ingresa TIME_WAITal estado

En el sistema Linux, el estado TIME_WAIT durará 2MSL antes de entrar en el estado cerrado.

Entonces, antes de que el servidor (parte de cierre pasivo) no reciba el mensaje ACK, todavía está en el estado LAST_ACK.

Si el mensaje ACK de la onda de la cuarta mano no llega al servidor, el servidor reenviará el mensaje FIN, y el número de retransmisiones todavía está controlado por tcp_orphan_retrieslos parámetros

Por ejemplo, suponiendo que tcp_orphan_retries es 2, cuando la cuarta ola siempre se pierde, el proceso que ocurre es el siguiente:

imagen

Proceso específico:

Cuando el servidor retransmite el mensaje de onda por tercera vez y llega a 2, porque tcp_orphan_retries es 2, se alcanza el número máximo de retransmisiones, así que espere un momento (el tiempo es el doble del tiempo de espera anterior), si aún falla para recibir la cuarta ola del cliente (mensaje ACK), luego el servidor se desconectará.
Después de recibir la tercera ola, el cliente ingresará al estado TIME_WAIT e iniciará un cronómetro con una duración de 2MSL. Si el cliente recibe la tercera ola (mensaje FIN) nuevamente en el camino, reiniciará el cronómetro. Cuando espera después de la duración de 2MSL , el cliente se desconectará.

¡encima!

¿Qué tal, está claro ahora?

Más artículos web

imagen Sitio web: xiaolincoding.com