[Javaweb] Principio TCP (tres apretones de manos y cuatro ondas)

contenido

1. Protocolo TCP

En segundo lugar, el principio de TCP

1. Mecanismo de respuesta de confirmación

2. Mecanismo de retransmisión de tiempo de espera

3. Mecanismo de gestión de conexiones

4. Ventana corredera

5. Control de flujo

6. Control de congestión

7. Respuesta tardía

8, respuesta a cuestas

9, problema del paquete pegajoso


1. Protocolo TCP

TCP, es decir, Transmission Control Protocol, protocolo de control de transmisión. Como su nombre indica, es necesario llevar a cabo un control detallado sobre la transmisión de datos.

Formato de segmento de protocolo TCP

Número de puerto de origen/destino: Indica de qué proceso provienen los datos y a qué proceso;

Número de serie: el número aleatorio generado por la computadora cuando se establece la conexión se usa como su valor inicial y se transmite al host receptor a través del paquete SYN. ​​Cada vez que se envían datos, el tamaño de los "bytes de datos" es " acumulado". Se utiliza para resolver el problema de los paquetes de red fuera de servicio.

Número de respuesta de confirmación: Se refiere al número de secuencia de los siguientes datos recibidos "esperados". Después de que el remitente recibe esta respuesta de confirmación, se puede considerar que los datos anteriores a este número de secuencia se han recibido normalmente. Se utiliza para resolver el problema de no pérdida de paquetes.

Indicadores de 6 bits:

URG: si el puntero urgente es válido

ACK: si el número de reconocimiento es válido, cuando este bit es 1, el campo de "Respuesta de reconocimiento" se vuelve válido. TCP estipula que este bit debe establecerse en 1 excepto para el paquete SYN cuando la conexión se establece inicialmente.

PSH: solicite a la aplicación receptora que lea los datos del búfer TCP inmediatamente

RST: La otra parte solicita restablecer la conexión, llamamos al segmento que lleva el identificador RST como el segmento de reinicio. Cuando el bit es 1, significa que ocurre una excepción en la conexión TCP y la conexión debe desconectarse a la fuerza.

SYN: solicitud para establecer una conexión, llamamos al segmento que lleva el identificador SYN como segmento de sincronización, cuando el bit es 1, significa que se desea una conexión, y el valor inicial del número de serie se establece en el "número de serie " campo.

FIN: notifica a la otra parte que el extremo local se va a cerrar. Llamamos al segmento que lleva el identificador FIN como el segmento final. Cuando el bit es 1, significa que no habrá más datos para enviar en el futuro. , y se espera que la conexión se desconecte. Cuando finaliza la comunicación y se desea desconectar la conexión, los hosts de ambos lados de la comunicación pueden intercambiar segmentos TCP cuyo bit FIN es 1.

En segundo lugar, el principio de TCP

El mecanismo de control proporcionado por TCP para la transmisión de datos se refleja principalmente en dos aspectos: seguridad y eficiencia. Estos mecanismos son similares a los principios de diseño de subprocesos múltiples: con la premisa de garantizar la seguridad de la transmisión de datos, mejorar la eficiencia de la transmisión tanto como sea posible.

1. Mecanismo de respuesta de confirmación

2. Mecanismo de retransmisión de tiempo de espera

Entonces, el host B recibirá una gran cantidad de datos duplicados. Luego, el protocolo TCP debe poder identificar esos paquetes como paquetes duplicados y descartar los duplicados. En este momento, podemos usar el número de serie mencionado anteriormente para lograr fácilmente el efecto de deduplicación.

En este momento, podemos usar el número de serie mencionado anteriormente para lograr fácilmente el efecto de deduplicación.

        Lo ideal es encontrar un tiempo mínimo para garantizar que "la respuesta de confirmación debe devolverse dentro de este tiempo".

        Sin embargo, la duración de este tiempo varía según el entorno de red.

        Si el tiempo de espera es demasiado largo, afectará la eficiencia general de retransmisión;

        Si el tiempo de espera es demasiado corto, es posible que se envíen paquetes repetidos con frecuencia;

Para garantizar una comunicación de alto rendimiento en cualquier entorno, TCP calcula dinámicamente este tiempo de espera máximo.

        En Linux (lo mismo ocurre con BSD Unix y Windows), el tiempo de espera se controla en una unidad de 500 ms, y el tiempo de espera para cada retransmisión de tiempo de espera es un múltiplo entero de 500 ms.

        Si aún no hay respuesta después de la retransmisión, espere 2*500ms antes de retransmitir.

        Si aún no hay respuesta, espere 4*500ms para la retransmisión. Y así sucesivamente, aumentando exponencialmente.

        Después de acumular una cierta cantidad de retransmisiones, TCP considera que la red o el host del mismo nivel es anormal y cierra la conexión a la fuerza.

3. Mecanismo de gestión de conexiones

Segmento de sincronización SYN, intente establecer una conexión con la otra parte, en la API de JavaSocket, el nuevo núcleo de socket del cliente iniciará dicha solicitud SYN

El bit de bandera SYN es 1, lo que indica que es un segmento de sincronización

Puedo oír (ACK), puedes oírme (SYN)

 El proceso de establecer una conexión es equivalente a enviar SYN entre sí por ambas partes, y luego enviar ACK y SYN en medio de ACK entre sí, y los dos son uno, por lo que el final es un "apretón de manos de tres vías".

¿Puede haber sólo dos apretones de manos?

Transición de estado del servidor:

[CERRADO -> LISTEN] Después de que el servidor llama a escuchar, ingresa al estado LISTEN y espera a que el cliente se conecte;

[LISTEN -> SYN_RCVD] Una vez que se monitorea la solicitud de conexión (segmento de sincronización), la conexión se coloca en la cola de espera del kernel y se envía un mensaje de confirmación SYN al cliente.

[SYN_RCVD -> ESTABLECIDO] Una vez que el servidor recibe el mensaje de confirmación del cliente, ingresa al estado ESTABLECIDO y puede leer y escribir datos.

[ESTABLECIDO -> CLOSE_WAIT] Cuando el cliente cierra activamente la conexión (las llamadas se cierran), el servidor recibirá el segmento final, el servidor devolverá el segmento de confirmación e ingresará CLOSE_WAIT;

[CLOSE_WAIT -> LAST_ACK] Después de ingresar CLOSE_WAIT, significa que el servidor está listo para cerrar la conexión (los datos anteriores deben procesarse); cuando el servidor realmente llame para cerrar la conexión, enviará FIN al cliente, y el servidor entrará en el estado LAST_ACK, esperando la llegada del último ACK (este ACK es la confirmación del cliente de que se ha recibido el FIN)

[LAST_ACK -> CLOSED] El servidor recibió un ACK para FIN y cerró la conexión por completo.

Transición de estado del cliente:

[CERRADO -> SYN_SENT] Las llamadas del cliente se conectan para enviar un segmento de sincronización;

[SYN_SENT -> ESTABLECIDO] Si la llamada de conexión es exitosa, ingresará al estado ESTABLECIDO y comenzará a leer y escribir datos;

[ESTABLECIDO -> FIN_WAIT_1] Cuando el cliente llama activamente a cerrar, envía el segmento final al servidor e ingresa FIN_WAIT_1 al mismo tiempo;

[FIN_WAIT_1 -> FIN_WAIT_2] Cuando el cliente recibe la confirmación del servidor del segmento final, ingresa FIN_WAIT_2 y comienza a esperar el segmento final del servidor;

[FIN_WAIT_2 -> TIME_WAIT] El cliente recibe el segmento final del servidor, ingresa TIME_WAIT y envía LAST_ACK;

[TIME_WAIT -> CLOSED] El cliente debe esperar un tiempo de 2MSL (Max Segment Life, el tiempo máximo de supervivencia del mensaje) antes de ingresar al estado CERRADO.

Estado de transferencia importante:

1. ESCUCHAR: el servidor se inicia y los clientes pueden conectarse en cualquier momento

2, ESTABLECIDO: La conexión se establece correctamente y el mensaje se transmite en cualquier momento

El servidor llama al nuevo ServerSocket para vincular el número de puerto e ingresar al estado LISTEN

Cuando el cliente llame al nuevo Socket, intentará establecer una conexión con el servidor y activará un protocolo de enlace de tres vías.

El protocolo de enlace de tres vías no se puede realizar solo dos veces. Si no hay un último ACK, el host B no puede saber si su capacidad de envío y la capacidad de recepción de la otra parte son normales.

Tres apretones de manos, cuatro apretones de manos están bien pero no son necesarios, el medio SYN y ACK se activan al mismo tiempo

3. CLOSE_WAIT: cuatro veces de ondas, la mitad de las dos veces restantes no serán ondas (el receptor no llama al método de cierre, lo que dará como resultado solo dos ondas de cuatro veces, por lo que la conexión no se cerrará correctamente).

4, TIME_WAIT: quien se desconecta activamente, quien ingresa al estado TIME_WAIT, en este momento el host ha completado el proceso de activación cuatro veces, pero aún no se puede liberar de inmediato, y la liberación debe esperar a que el estado TIME_WAIT permanezca durante un cierto período de tiempo.

Si se produce una pérdida de paquetes durante el protocolo de enlace de tres vías y el proceso de onda de cuatro vías, se activará una retransmisión de tiempo de espera.

4. Ventana corredera

Sin el mecanismo de ventana deslizante, para transmitir N piezas de datos, es necesario esperar N tiempos de tiempo de respuesta. El tiempo total de transmisión es: N piezas de tiempo de transmisión de datos + N piezas de tiempo de respuesta.

La esencia de la ventana deslizante es transmitir datos en lotes y el tiempo total de transmisión: N piezas de tiempo de transmisión de datos se superponen en 1 pieza de tiempo.

Ventana: la cantidad máxima de datos enviados en lotes sin esperar ACK se denomina "tamaño de ventana"

Deslizante: una analogía visual, el rango de la ventana es para indicar qué datos están actualmente esperando ACK. Cuando llega un ACK, los siguientes datos se envían inmediatamente y el rango de paquetes de datos en espera se desliza gradualmente.

El tamaño de la ventana no cambia. Cuando el remitente recibe el ACK de 2001, significa que la otra parte ha recibido los datos de 1001-2000. En este momento, los datos de 5001-6001 se transmiten inmediatamente. En esta vez, el número de secuencia del paquete ACK en espera es 2001, 3001, 4001, 5001.

ACK se pierde

Si se pierde el ACK del 1001, pero no se pierde el ACK del 2001, se considera que el dato 1-1000 también llegó exitosamente, y si se pierde el 1001, se pierde, no importa, el 2001 puede contener el información en 1001ACK.

El paquete se acaba de perder

Si se pierde el datagrama, por ejemplo, 1001-2000, entonces los siguientes datos, como 2001-3000, 3001-4000, etc., han llegado con éxito. En este momento, el número de serie del ACK devuelto por el host B es siempre 1001. Si el host A encuentra que varios ACK consecutivos son 1001. El host A sabe que el datagrama 1001 está perdido y retransmitirá 1001.

Cuando el host B recibe los datos de 1001, dado que los datos de 2001-7000 acaban de recibirse, los siguientes dos ACK comenzarán desde 7001. La retransmisión solo retransmite los datos perdidos y otros datos no necesitan retransmisión adicional.

5. Control de flujo

La velocidad a la que el receptor puede procesar los datos es limitada. Si el remitente envía demasiado rápido, lo que hace que el búfer del receptor se llene, si el remitente continúa enviando en este momento, provocará la pérdida de paquetes, lo que provocará una serie de reacciones en cadena, como la pérdida de paquetes y la retransmisión. Por lo tanto, TCP admite la determinación de la velocidad de envío del remitente de acuerdo con la capacidad de procesamiento del receptor. Este mecanismo se llama Control de Flujo ;

El extremo receptor coloca el tamaño del búfer que puede recibir en el campo "tamaño de ventana" en el encabezado TCP y notifica al extremo emisor a través del extremo ACK;

Cuanto mayor sea el campo de tamaño de la ventana, mayor será el rendimiento de la red;

Una vez que el receptor descubre que su búfer está casi lleno, establecerá el tamaño de la ventana en un valor más pequeño y notificará al remitente;

Después de que el remitente reciba esta ventana, reducirá su propia velocidad de envío;

Si el búfer del receptor está lleno, la ventana se establecerá en 0; en este momento, el remitente ya no enviará datos, pero necesita enviar periódicamente un segmento de datos de detección de ventana, para que el receptor pueda decirle al remitente el tamaño de la ventana.

En esencia, el control de flujo restringe la eficiencia de envío del remitente según la capacidad de procesamiento del receptor.

Restrinja la ventana deslizante del remitente de acuerdo con el espacio restante del búfer de recepción

Reflejado al remitente por el "campo de tamaño de ventana" en el encabezado TCP

6. Control de congestión

Aunque TCP tiene el gran asesino de la ventana deslizante, puede enviar grandes cantidades de datos de manera eficiente y confiable. Pero aún puede causar problemas si se envían muchos datos desde el principio. Debido a que hay muchas computadoras en la red, el estado actual de la red puede estar congestionado. Sin conocer el estado actual de la red, es probable que el envío precipitado de una gran cantidad de datos empeore las cosas. TCP introduce un mecanismo de inicio lento, primero envía una pequeña cantidad de datos, explora la ruta, descubre el estado actual de congestión de la red y luego decide qué tan rápido transmitir los datos;

Dado que el control de congestión no es fácil de medir la congestión de la ruta de transmisión, solo se puede usar repetidamente para probar el tamaño de la ventana gradualmente.

1. Comienza a experimentar con un tamaño de ventana más pequeño

2. Si no hay congestión (sin pérdida de paquetes), expanda la ventana de congestión exponencialmente

3. Después de alcanzar un cierto umbral, aumente linealmente el tamaño de la ventana

4. Hasta que se produzca la pérdida de paquetes, la ventana vuelve al valor inicial y el umbral de ajuste es la mitad del tamaño de la ventana en la que se produce la pérdida de paquetes.

7. Respuesta tardía

Si el host que recibe los datos devuelve una respuesta ACK inmediatamente, la ventana devuelta en este momento puede ser relativamente pequeña.

Supongamos que el búfer del receptor es 1M. Recibió 500 000 de datos a la vez; si responde de inmediato, la ventana devuelta es 500 000;

Pero, de hecho, la velocidad de procesamiento del terminal de procesamiento puede ser muy rápida y se consumen 500 K datos del búfer en 10 ms;

En este caso, el procesamiento en el extremo receptor está lejos de alcanzar su propio límite, e incluso si se amplía la ventana, se puede procesar;

Si el extremo receptor espera un tiempo antes de responder, como esperar 200 ms antes de responder, entonces el tamaño de ventana devuelto en este momento es 1 M;

Cuanto mayor sea la ventana, mayor será el rendimiento de la red y mayor será la eficiencia de transmisión. Nuestro objetivo es maximizar la eficiencia de la transmisión y garantizar que la red no esté congestionada;

8, respuesta a cuestas

Sobre la base de la demora en la respuesta, se introdujo un mecanismo para mejorar aún más la eficiencia de la operación del programa

 El modo de comunicación entre el cliente y el servidor es generalmente el modo Solicitud-Respuesta, "una pregunta y una respuesta".

El host B quiere devolver dos datos al host A. Estrictamente hablando, el tiempo de transmisión de estos dos datos es diferente.

Cuando Req envía el kernel para recibir datos, devolverá ACK inmediatamente y Resp volverá al código de la aplicación. Después de ejecutar Resp, la respuesta se escribirá de nuevo en el cliente y se enviará la respuesta.

Debido a la respuesta retrasada, el tiempo de transmisión de ACK se retrasa y el tiempo de retraso es suficiente para que el programa en inglés complete el cálculo de respuesta.

Cuando regresé a Resp, descubrí que el ACK de ahora no se había enviado. Sobre la base de Resp, tomé un valor de ACK por cierto.

9, problema del paquete pegajoso

En primer lugar, debe quedar claro que el "paquete" en el problema del paquete fijo se refiere al paquete de datos de la capa de aplicación. En el encabezado del protocolo de TCP, no hay un campo como "longitud del paquete" como UDP, pero hay un campo como el número de secuencia. Desde la perspectiva de la capa de transporte, TCP viene uno por uno. Póngalos en el búfer en orden de número de secuencia. Desde la perspectiva de la capa de aplicación, todo lo que ve es una serie de datos de bytes continuos. Luego, la aplicación ve esa serie de datos de bytes y no sabe qué parte comienza con qué parte, que es un paquete de datos de capa de aplicación completo.

Entonces, ¿cómo evitar el problema del paquete pegajoso? En el análisis final, es una oración que define el límite entre dos paquetes.

Para paquetes de longitud fija, asegúrese de que se lean en un tamaño fijo cada vez; por ejemplo, la estructura de solicitud anterior es de un tamaño fijo, luego se puede leer secuencialmente desde el búfer de acuerdo con el tamaño de (Solicitud); para variable- paquetes de longitud Para el paquete, puede acordar un campo de la longitud total del paquete en la posición del encabezado del paquete, para saber la posición final del paquete; para el paquete de longitud variable, también puede usar un delimitador claro entre el paquete y el paquete (protocolo de capa de aplicación, lo determinan los propios programadores, siempre que el delimitador no entre en conflicto con el texto)

Supongo que te gusta

Origin blog.csdn.net/qq_50156012/article/details/123391854
Recomendado
Clasificación