TCP tres apretón de manos y cuatro ondas y respuesta

El protocolo de enlace de tres vías de TCP se utiliza para establecer una conexión. Al
establecer una conexión de TCP, el cliente y el servidor deben enviar un total de 3 paquetes para confirmar el establecimiento de la conexión
. En la programación del socket, el cliente ejecuta este proceso para activar
Inserte la descripción de la imagen aquí
el primer protocolo de enlace : El cliente establece SYN en 1 y genera aleatoriamente un valor seq = j y envía el paquete de datos al servidor.El cliente ingresa al estado SYN_SENT y espera a que el servidor confirme el
segundo protocolo de enlace : Después de que el servidor recibe el paquete, SYN = 1 sabe que el cliente solicita establecer una conexión. ACK se establece en 1 ack = j + 1 Genera aleatoriamente un valor seq = k y envía el paquete al cliente para confirmar la solicitud de conexión. El servidor ingresa al estado SYN_RCVD. El
tercer apretón de manos : después de que el cliente recibe la confirmación, verifique si el ack es +1 ack es 1. Si es correcta, entonces el ACK se establece en 1 ack = k + 1 y el paquete de datos al servidor Server para comprobar la correcta conexión se establece de cliente y servidor entra establecidos estado para completar el enlace de tres vías a continuación, comenzar la transmisión de datos entre cliente y servidor
Inserte la descripción de la imagen aquí
¿Por qué se requiere de tres vías dos veces o cuatro veces o cinco veces usted no puede hacerlo?
---- análisis suponiendo que un cliente solicite especiales para establecer una conexión con el servidor de paquetes SYN de espera Después de que el servidor confirma que el servidor recibe la confirmación, si se trata de un protocolo de enlace bidireccional, se supone que el servidor envía datos al cliente durante el segundo protocolo de enlace. El servidor envía al servidor que la conexión se ha establecido pero los datos se pierden durante el proceso. Se realizará la retransmisión. Suponga que cada vez que se pierden los datos enviados, el cliente ha sido servidor SYN, generará múltiples conexiones no válidas y ocupará recursos. En este momento, el servidor puede bloquearse. Este fenómeno es el ataque de inundación de SYN.
---- El tercer apretón de manos es evitar que el cliente abandone la conexión y reinicie una solicitud de conexión si el cliente no recibe el mensaje de confirmación del servidor, pero el problema es que el servidor no sabe que el cliente no lo ha recibido, por lo que recibirá dos Las conexiones desperdician costos de conexión si este es el caso cada vez que desperdiciará múltiples costos de conexión

La cuarta ola de TCP es principalmente
Inserte la descripción de la imagen aquí
la primera ola cuando el puerto TCP está desconectado : el Host 1 (que puede ser un cliente o un servidor) envía un segmento FIN al Host 2 En este momento, el Host 1 ingresa al estado FIN_WAIT_1 para indicar el host 1 No hay datos para enviar al host 2.
** La segunda ola: ** El host 2 recibió el segmento FIN enviado por el host 1 y devolvió un segmento ACK al host 1. El host 1 entró en el estado FIN_WAIT_2. El host 2 le dijo al host 1 Tampoco tengo datos para enviar. Puedo cerrar la conexión. La
tercera ola: el host 2 envía un segmento FIN al host 1 para cerrar la conexión y el host 2 ingresa al estado CLOSE_WAIT. La
cuarta ola: el host 1 recibe el host 2 El segmento FIN enviado al host 2 envía un segmento ACK al host 2 El host aleatorio 1 ingresa al estado TIME_WAIT El host 2 recibe el segmento ACK del host 1 y cierra la conexión en este momento el host 1 espera 2MSL y aún no ha recibido una respuesta para probar del lado del servidor se ha cerrado adecuadamente, entonces el anfitrión 1 puede también cerrar la conexión
Inserte la descripción de la imagen aquí
¿por qué necesidad de pasar por 2MSL (máximo de por vida segmento) cerca de volver al estado estado TIME_WAIT?
---- primera MSL es el tiempo de vida máximo de paquete es o bien La presencia de paquetes que excedan el periodo de tiempo máximo que el paquete se descarta en la red
---- una espera TIME_WAIT TCP 2MSL inicia cuando un extremo del paquete TCP ACK se transmite tres veces el cuarto de onda cerrado activo después de onda después de la finalización de la entrada El objetivo principal de este estado de esperar el tiempo de 2MSL es evitar que la otra parte reciba el último paquete ACK. La otra parte reenviará el tercer paquete FIN agitado después del tiempo de espera. Cuando el paquete está en el estado TIME_WAIT, los puertos en ambos extremos no se pueden usar. Espere hasta el final del tiempo de 2MSL antes de continuar usándolo. Cuando la conexión está en la fase de espera de 2MSL, se descartarán los segmentos tardíos

El cliente ingresa al estado time_wait después de enviar el último reconocimiento, pero ¿cómo sabe si el servidor ha recibido el reconocimiento?
Es probable que el paquete de confirmación enviado por la parte activamente cerrada debido a razones de red se retrase, lo que provoca que la parte de conexión pasiva retransmita el paquete FIN. En casos extremos, esto Una vuelta y una vuelta es el doble de la duración del MSL. Si la parte cerrada activamente omite TIME_WAIT y entra directamente en el tiempo cerrado o permanece en time_wait por menos del doble del MSL, cuando el paquete retrasado enviado por la parte pasivamente cerrada llegue antes, puede aparecer como El problema: la antigua conexión tcp ya no existe. El sistema solo puede devolver el primer paquete en este momento. Se establece la nueva conexión tcp. El paquete de retraso puede interferir con la nueva conexión. Es por eso que debe esperar 2msl.

¿Por qué el apretón de manos de tres vías cuando la conexión está cerrada y la onda de cuatro vías?
Porque cuando el servidor recibe el mensaje de solicitud de conexión de sincronización del cliente, puede enviar directamente un mensaje de sincronización + reconocimiento. El mensaje de confirmación es el mensaje de sincronización utilizado para responder. Se utiliza para la sincronización, pero cuando se cierra la conexión, cuando el servidor recibe el mensaje de aleta, es muy probable que el socket no se cierre de inmediato, por lo que solo puedo responder a un mensaje de confirmación para decirle al cliente "Recibí el mensaje que envió". Solo espere por mí Después de que se envían todos los mensajes en el servidor, puedo enviar el mensaje final porque no puedo enviarlos juntos, así que necesito saludar cuatro veces.

41 artículos originales publicados · Me gusta2 · Visitas 1836

Supongo que te gusta

Origin blog.csdn.net/weixin_43883485/article/details/105389739
Recomendado
Clasificación