Protocolo TCP-apretón de manos y agitando

 

Conoce el protocolo TCP

TCP se llama "Protocolo de control de transmisión", que es un protocolo en la capa de transporte, que controla la transmisión de datos en detalle. 
Caracteristicas:

• Orientado a bytes
• Seguro y confiable
• Orientado a la conexión

Formato de segmento de protocolo TCP

• Número de puerto de origen y número de puerto de destino: aquí es lo mismo que UDP, cada información debe saber de qué proceso llegar a qué proceso.
• Número de serie de 32 bits y número de serie de confirmación de 32 bits: el número de serie y la señal de confirmación aquí pueden entenderse como información que dos procesos de comunicación se responden entre sí al enviar y recibir datos. Por ejemplo, el proceso A comienza a enviar datos al proceso B desde la secuencia número 1000 y envía cinco datos. Luego, cuando B recibe la respuesta de datos, el número de secuencia de confirmación de A aquí debe ser de 1006, si no es 1006, por ejemplo, 1003, significa que 1004, 1005 no se ha recibido el paquete de datos B, por lo que A inicia el mecanismo de retransmisión . Esto garantiza la fiabilidad de los datos y también es una de las características de TCP. El número de serie es el número que el proceso envía el mensaje, y la confirmación es el número que se espera que el proceso de destino regrese. Realice una comparación para verificar si llega el paquete de datos.
• Longitud del encabezado TCP de 4 bits: la longitud del encabezado TCP de 4 bits aquí puede entenderse como cuatro bits que representan la longitud, y el valor representado por los cuatro bits multiplicados por cuatro es la longitud del encabezado TCP. De la figura se puede ver que la longitud mínima del encabezado es de 20 bytes, lo que significa que la longitud del encabezado TCP de cuatro bits aquí es 0101 por defecto. Y la longitud del encabezado TCP no puede exceder 15 * 4 = 60 bytes.
• Indicador de 6 bits: ① URG: si el puntero de emergencia es válido ② ACK: si el número de confirmación es válido ③ PSH: solicita a la aplicación receptora que lea inmediatamente los datos del búfer TCP ④ RST: la otra parte solicita restablecer la conexión, llamamos al logotipo RST Restablecer segmento ⑤ SYN: solicitud para establecer una conexión, llamamos al identificador SYN que lleva el segmento de sincronización ⑥ FIN: notifica a la otra parte que el extremo local está cerrado, llamamos al segmento de fin de transporte FIN.
• Tamaño de ventana de 16 bits: el tamaño de la ventana aquí puede verse como un signo, que indica el tamaño del espacio restante en el búfer TCP. Juega un papel de control de flujo. Si 16 es la ventana está llena, entonces esta vez no se permite recibir datos. Los datos que lleguen más tarde se perderán.
• Suma de comprobación de 16 bits: la suma de comprobación aquí la llena el remitente, la comprobación CRC. Si la verificación falla cuando el receptor recibe los datos, se considera que hay un problema con los datos. La suma de comprobación aquí no solo verifica el encabezado TCP, sino también la porción de datos.
• Puntero de emergencia de 16 bits: identifica qué parte de los datos son datos de emergencia.

  Proceso de conexión

  Sabemos que el protocolo TCP está orientado a la conexión, lo que significa que solo se puede usar después de que el cliente y el servidor se hayan conectado correctamente. Entonces, ¿cuál es el proceso de conexión entre el cliente y el servidor? En términos simples, son tres apretones de manos y cuatro manos de onda. La idea principal es que el cliente necesita tres apretones de manos para conectarse al servidor y cuatro manos de onda para desconectarse después de que se complete la comunicación.

• Apretón de manos

 

Tanto el cliente como el servidor hicieron algunos preparativos preliminares antes de estrechar la mano. El servidor primero asigna un descriptor, luego completa la estructura sockaddr_in, vincula el descriptor de archivo creado y el puerto del servidor, y luego escucha para hacer que el descriptor de archivo se convierta en un descriptor de escucha, y finalmente bloquea para aceptar esperar al cliente Conectar El cliente es relativamente simple, es asignar descriptores de archivo, llenar la estructura sockaddr_in y finalmente conectarse para solicitar la conexión del servidor hasta que el servidor responda.

Cuando el cliente solicita la respuesta del servidor a través de la conexión, envía un segmento de mensaje de sincronización, es decir, una solicitud SYN, al servidor, y espera la respuesta del servidor después del envío. Si el servidor recibe el segmento de sincronización SYN, enviará una respuesta ACK al cliente, lo que significa que recibió el segmento de sincronización enviado por el cliente. Al mismo tiempo, el servidor también enviará un segmento de sincronización SYN para solicitar Responder Después de recibir el segmento de sincronización SYN, el cliente también enviará una respuesta ACK para responder al servidor. Este proceso es el proceso de tres apretones de manos.

De esta manera, la conexión entre el cliente y el servidor es ambas, ambas deben enviar una solicitud y ambas deben responder. Visto en la figura, SYN_SENT es el estado de la conexión de solicitud, y SYN_RCVD es el estado de la conexión en espera. Después de que el protocolo de enlace de tres vías es exitoso, tanto el servidor como el cliente ingresarán al estado ESTABLECIDO, es decir, la conexión TCP es exitosa. En este momento, los datos pueden transmitirse.

Durante este proceso, si se pierde la solicitud SYN del cliente, el servidor no responderá y el cliente tendrá un tiempo de espera. Cuando llegue el tiempo de espera y no se reciba ninguna respuesta ACK, el cliente iniciará otra solicitud. Si varias solicitudes no tienen éxito, el cliente puede determinar que la red es anormal y no volverá a solicitar. Del mismo modo, después de que el servidor recibe la solicitud SYN del cliente, también enviará una respuesta ACK y enviará una solicitud SYN. Si el cliente no responde al ACK del servidor, el servidor también se reenviará hasta que se juzgue que la red es anormal. Por lo tanto, si falta alguno de los tres apretones de manos, la conexión no será exitosa y la comunicación no será posible. Por lo tanto, el protocolo de enlace de tres vías también es una forma de garantizar la confiabilidad de TCP.

¿Cuál es el propósito del apretón de manos de tres vías?
Respuesta: La comprensión personal es fácil de entender es sincronizar el número de serie y el número de confirmación de las dos partes e intercambiar la información de tamaño de la ventana tcp.
¿Por qué necesitamos dos apretones de manos para completar la solución, pero tres veces?
Respuesta: Se requiere el protocolo de enlace de tres vías para evitar que el segmento de solicitud de conexión no válida se transmita repentinamente al servidor, lo que provocará un error.

Agita cuatro veces

Una vez completada la transmisión de datos entre el cliente y el servidor, el cliente no tiene ninguna solicitud, por lo que en este momento se llama a close para cerrar el descriptor de archivo y se ingresa el estado FIN_WAIT_1. Al mismo tiempo, el segmento de mensaje final FIN se envía al servidor. Espere la respuesta del servidor. Cuando el servidor recibe el segmento final FIN aquí, esta vez, el servidor ingresa al estado CLOSE_WAIT. Y responda al cliente para enviar ACK. Cuando el cliente recibe la respuesta ACK del servidor, ingresa al estado FIN_WAIT_2. Cuando el servidor llama a cerrar, envía un segmento final FIN al cliente. Ingrese el estado LAST_ACK en este momento. En este momento, cuando el cliente recibe el FIN enviado por el servidor, responderá al servidor con un ACK, y el cliente ingresa al estado TIME_WAIT. Luego de que TIME_WAIT finaliza, ingresa CERRADO y se desconecta con éxito. Cuando el servidor recibe el último ACK del cliente, ingresa al estado CERRADO. Con éxito desconectado.

Estado CLOSE_WAIT y LAST_ACK

Durante el protocolo de enlace de tres vías, el servidor puede enviar SYN y ACK al mismo tiempo, pero ¿por qué los FIN y ACK enviados por el servidor se envían por separado? ? Este es realmente el caso. 

En primer lugar, la señal FIN se envía debido al cierre de la llamada. Cuando el cliente llama cerca, envía un segmento final FIN y entra en el estado FIN_WAIT_1. Sin embargo, el segmento de usuario en el servidor es realmente imperceptible para este segmento. El núcleo procesará este segmento por sí mismo, lo que significa que el núcleo responderá con un ACK. Este proceso no está determinado por el código del usuario. El FIN del servidor es enviado por el código del usuario llamando a close, por lo que el núcleo y el servidor pueden no procesar esta información al mismo tiempo. Por lo tanto, FIN y ACK no se envían necesariamente al mismo tiempo. Nota: ¡Esto no es necesariamente aquí! ! ! Sin embargo, el núcleo envía el SYN directamente durante el protocolo de enlace de tres vías, por lo que esto puede lograr una transmisión síncrona.

Si el código del servidor no se cierra, significa que el segmento final FIN no se ha enviado. Es decir, el servidor conectado permanece en el estado CLOSE_WAIT durante mucho tiempo, ¿qué impacto tendrá esto? 
El servidor permanece en el estado CLOSE_WAIT durante mucho tiempo, lo que significa que el descriptor de archivo asignado no se ha cerrado ni devuelto. Entonces, si existe una gran cantidad de CLOSE_WAIT, provocará una pérdida de recursos. Puede que no haya descriptores de archivo asignables al final, lo que hará que algunos clientes no puedan conectarse, lo que provocará un impacto inestimable.

TIEMPO DE ESPERA

Después de que el cliente envía la respuesta ACK por última vez, ingresa al estado TIME_WAIT, y ¿qué está haciendo el cliente en este estado? 
¡La respuesta es esperar! Una vez que el cliente finalmente envía la respuesta ACK, ingresa el estado TIME_WAIT, para evitar que se pierda la última respuesta ACK. Aquí, el estado TIME_WAIT esperará 2MSL.

La unidad MSL aquí es Max Segment Life, lo que significa el tiempo de supervivencia máximo de un mensaje. El tiempo de supervivencia aquí se refiere a todo el proceso desde la aparición de un mensaje hasta su recepción. El tiempo de este proceso es MSL. 
En Linux, puede usar cat / proc / sys / net / ipv4 / tcp_fin_timeout para ver el valor de MSL. 

Después de que el cliente envía la respuesta ACK por última vez, ¿por qué esperar 2MSL?

Esto es para asegurar que llegue el último mensaje ACK. Debido a que el cliente ingresa al estado TIME_WAIT después de enviar la última respuesta ACK, si el mensaje ACK se pierde, el servidor descubre que no ha recibido una respuesta ACK después de esperar un MSL, luego reenviará un mensaje FIN. El tiempo de dicha respuesta ACK más el tiempo del FIN retransmitido es exactamente 2MSL. Si el cliente no recibe el mensaje FIN después de esperar 2MSL, significa que el servidor recibió el mensaje ACK enviado por el cliente, que desconecta la conexión. 

Aquí puede ver que después de que el cliente sale, ingresa al estado TIME_WAIT.

En otras palabras, en TIME_WAIT, la conexión TCP entre el cliente y el servidor aún existe. 
En algunos casos, el servidor también puede solicitar la desconexión, y el servidor primero ingresa FIN_WAIT_1. En este caso, el servidor finalmente ingresa al estado TIME_WAIT. Entonces, ¿cuál es el problema en este estado?

Aquí, terminamos el servidor y descubrimos que el servidor entró en el estado TIME_WAIT. En este momento, el servidor se reinició nuevamente y se encontró que no se podía iniciar. En este momento, el enlace del número de puerto falló debido a un error al iniciar. ¿Por qué es esto?

De hecho, esto se debe a que en el estado TIME_WAIT, la conexión TCP todavía existe, por lo que el número de puerto ahora está vinculado. Cuando el servidor se inició de nuevo, el número de puerto en este momento no fue liberado. Por lo tanto, solo indica que el enlace ha fallado.

Si el servidor necesita manejar una gran cantidad de conexiones de clientes, el tiempo de supervivencia de cada conexión es muy corto, pero hay una gran cantidad de solicitudes de clientes por segundo. En este momento, si el servidor cierra activamente la conexión, se generará una gran cantidad de conexiones TIME_WAIT. Debido a nuestra gran demanda, resultará en una gran cantidad de conexiones TIME_WAIT, resultando en puertos de servidor insuficientes para manejar nuevas conexiones. ¿Cómo resolver esta vez?

En este momento, la función setsockopt (listenfd, SOL_SOCKET, SO_REUSEADDR, y opt, sizeof (opt) se puede utilizar para resolver este problema. La función de esta función es permitir la creación de múltiples descriptores de socket con el mismo número de puerto pero diferentes direcciones IP. En socket () y Simplemente llame entre bind ().