Mi informacion de contacto
Correo[email protected]
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
El protocolo TCP tiene las características de conexión, transmisión confiable, orientado al flujo de bytes, full-duplex, etc. La transmisión confiable es su parte central.
Figura 1
La figura anterior es la estructura del encabezado TCP.
(1) No es necesario introducir demasiado el puerto de origen y el puerto de destino. Son los programas que se utilizan para indicar el extremo emisor y el extremo receptor.
(2) El número de secuencia y el número de secuencia de confirmación se utilizan para el mecanismo de respuesta de confirmación en TCP que se presentará más adelante.
(3) Los 4 bits en la parte de desplazamiento de datos en realidad se usan aquí para indicar la longitud del encabezado TCP. Debido a los 4 bits, el número máximo representado es 15, pero debido a que la unidad es de 4 bytes, la longitud máxima. El encabezado TCP es de 60 bytes.
(4) Todos sabemos que la longitud máxima de los paquetes de datos UDP es 64 kb, lo cual es muy limitado, por lo que para evitar esta situación, se proporcionan 6 bits reservados en el encabezado TCP, que se pueden usar si se expande la función TCP. Más tarde, se representa mediante bits reservados.
(5) El identificador en inglés de 6 bytes está relacionado con el mecanismo TCP que se presenta más adelante y no se presentará aquí.
(6) La suma de verificación tiene la misma función que la suma de verificación en UDP y también se utiliza para verificar si los datos han cambiado durante el proceso de transmisión.
(7) La ventana se discutirá más adelante cuando se presente el mecanismo.
(8) El indicador de emergencia se presentará más adelante.
(9) Entre las opciones se encuentran algunas opciones opcionales/opcionales.
El protocolo TCP tiene que resolver un problema muy importante: la transmisión fiable. La llamada transmisión confiable no significa que el remitente pueda enviar los datos al receptor al 100%, pero hará todo lo posible para que el remitente sepa si el receptor lo sabe.
Figura 2
Como se muestra en la Figura 2, cada vez que envía un mensaje a la diosa, la diosa le enviará un mensaje. Esta es la respuesta. Este también es el caso en TCP. El cliente envía un paquete de datos. devolver un paquete de datos de respuesta En este momento, los datos de respuesta El indicador ACK del paquete en la Figura 1 se establecerá en 1.
imagen 3
Como se muestra en la Figura 3, cuando enviamos varios mensajes a la diosa, debido a que la diosa responde a los mensajes a diferentes velocidades, es fácil que nos confundamos. Pensaremos que la diosa acepta ser mi novia. La diosa dice que se pierda. Esto es Internet. El problema del último en llegar, primero en ser atendido, existe objetivamente en China. Obviamente, al enviar múltiples paquetes de datos al cliente y el cliente responder a múltiples paquetes de datos de respuesta, también debemos distinguir qué respuesta corresponde a qué paquete de datos se envió. Este problema se puede resolver utilizando el número de secuencia y el número de secuencia de confirmación en la Figura 1. .
Cada paquete de datos enviado tiene un número de secuencia, pero no hay un número de secuencia de confirmación, o el campo de número de secuencia de confirmación no es válido. El ACK del paquete de datos que responde es 1. En este momento, el campo de número de secuencia de confirmación es válido. y el número de secuencia del paquete de datos enviado y la respuesta Los números de secuencia de confirmación de los paquetes de datos son correspondientes, de modo que se puede distinguir quién respondió a quién y se puede resolver el problema de último en llegar primero en ser atendido en la red mencionado anteriormente. .
El número de secuencia del paquete de datos TCP real se numera según los bytes. A cada byte se le asignará un número de secuencia. El valor del número de secuencia en el encabezado TCP es el número del primer byte de la carga útil, por ejemplo, el número. del primer byte en la parte de carga útil. Un número de byte es 1 y la longitud de la carga útil es 1000 bytes, entonces el número de secuencia de confirmación en el encabezado del paquete de datos de respuesta es 1001. Esto se debe a que el número de secuencia de confirmación del El paquete de datos de respuesta correspondiente al paquete de datos se establece en El número del último byte de la carga útil se incrementa en 1. De hecho, esto es más fácil de entender. Devolver 1001 significa que se ha recibido la carga útil de 1000 bytes enviada. Se solicitan datos posteriores a 1001, como se muestra en la Figura 4.
Figura 4
Para los paquetes de datos enviados posteriormente, el número de secuencia se incrementa, pero una cosa a tener en cuenta es que, aunque se incrementa, el número de secuencia no comienza en 0 o 1.
La transmisión confiable se puede lograr principalmente confiando en el mecanismo de "respuesta de confirmación". Puede decirle al remitente a través del mensaje de respuesta si todo va bien y si se produce una pérdida de paquetes. ¿Qué se debe hacer si se produce una pérdida de paquetes (los datos se pierden durante el proceso de transmisión y no pueden llegar al extremo opuesto, un evento aleatorio objetivo)?
La retransmisión por tiempo de espera se utiliza para solucionar problemas de pérdida de paquetes en la red.
Aquí se dan principalmente dos situaciones:
(1) Los paquetes de datos transmitidos se pierden
En este momento, B no enviará un paquete de respuesta si no recibe el paquete de datos de A. Cuando el evento que A está esperando excede un cierto umbral, determinará que ha ocurrido un problema de pérdida de paquetes y retransmitirá el paquete de datos.
(2) El paquete de datos de respuesta se pierde.
Cuando A no recibe el paquete de datos de respuesta, todavía retransmite un paquete de datos, pero en este momento B ha recibido un paquete de datos. Con la retransmisión del paquete de datos, recibirá dos paquetes de datos idénticos. , especialmente para temas como transferencias, donde se producirán transferencias repetidas.
Para los problemas anteriores, el receptor TCP deduplicará los datos recibidos según el número de secuencia. A la capa TCP no le importa el problema de la duplicación. La clave es que la capa de aplicación no puede leer datos duplicados, no importa cuántas veces se retransmitan, debe asegurarse de que la capa de aplicación solo lea una copia.
En el núcleo del sistema operativo receptor, hay una estructura de datos: el búfer de recepción. Esta estructura de datos es similar a la cola de bloqueo de prioridad. Cuando B recibe el paquete de datos y pasa a través de las capas a la capa de transporte. cola de bloqueo para colocar los datos, introdúzcalos y la cola determinará si los datos existen en función del número de secuencia del paquete de datos. Si existe (existencia significa que el mismo paquete de datos ha sido recibido y leído una vez). capa de aplicación), se descartará directamente. Otro punto del búfer de recepción es que puede resolver el problema del último en llegar, primero en ser atendido en la red. Los datos enviados se ordenarán según el número de secuencia y luego el programa de la capa de aplicación los consumirá en orden.
Como se muestra en la figura anterior, los datos que llegan al búfer de recepción se ordenarán según el número de secuencia. Esto no solo resuelve el problema del último enviado, primero en llegar, sino que también resuelve el problema de recibir paquetes de datos duplicados. esta vez, si el paquete de datos retransmitido se recibe con el número de secuencia 500 Se descartará directamente, porque el número de secuencia mínimo del búfer de recepción es 1000, lo que significa que el programa de aplicación ya ha leído 500.
La pérdida de paquetes en sí es un evento de pequeña probabilidad. Cuando aumenta la cantidad de pérdidas de paquetes, la red se convertirá en un gran problema. A medida que aumenta el número de retransmisiones, el intervalo de tiempo entre retransmisiones sigue aumentando, porque más retransmisiones indican que hay un problema con la red y las retransmisiones frecuentes consumirán recursos. Cuando el número de retransmisiones alcanza un umbral, se enviará un mensaje de reinicio con el bit de bandera RST establecido en 1 para borrar el estado intermedio de ambos extremos. Si no se responde al mensaje de reinicio, se eliminará la conexión en ambos extremos.
La retransmisión por tiempo de espera es un complemento de la respuesta de reconocimiento.
Figura 5
Establecer una conexión significa que ambas partes que se comunican guardan la información del otro extremo. La finalización específica requiere tres interacciones de red, como se muestra en la Figura 5.
La primera vez que el protocolo de enlace de tres vías debe ser iniciado por el cliente. Quien inicia el protocolo de enlace de tres vías es el cliente. El proceso específico se muestra en la Figura 5. Primero, el cliente envía un paquete SYN, es decir, el indicador SYN en el encabezado se establece en 1. Luego, el servidor devuelve un paquete de respuesta. Los indicadores ACK y SYN del paquete de respuesta son. ambos configurados en 1, porque ACK y SYN Los paquetes de datos con bits de bandera son enviados por el kernel del sistema operativo al mismo tiempo, por lo que pueden enviarse juntos para mejorar el rendimiento. Finalmente, el cliente envía un paquete de respuesta al servidor y se completa el protocolo de enlace de tres vías. Los paquetes de datos transmitidos durante este proceso no contienen datos comerciales.
El significado del apretón de manos de tres vías:
(1) Lanzar piedras para pedir direcciones.
Confirme si el enlace de comunicación es fluido
(2) Negociar algunos parámetros importantes
Por ejemplo, el número de secuencia del paquete de datos transmitido.
(3) Confirmar las capacidades de recepción y envío de ambas partes.
¿Por qué tres apretones de manos? ¿Están bien cuatro o dos apretones de manos?
Aunque el protocolo de enlace de cuatro vías no afectará las funciones normales, reducirá el rendimiento. El protocolo de enlace de dos vías no puede confirmar completamente las capacidades de recepción y envío del servidor.
Además, hay dos estados más importantes involucrados aquí. El primero es el estado de escucha, lo que significa que el servidor ha vinculado el puerto en este momento y está esperando que el cliente envíe un paquete SYN. El otro está establecido. Es fácil de entender y significa que se completa el protocolo de enlace de tres vías. El estado después de que se establece la conexión.
A diferencia del protocolo de enlace de tres vías, que solo puede iniciarlo primero el cliente, tanto el servidor como el cliente pueden iniciar el protocolo de enlace de cuatro vías.
Figura 6
El proceso específico de agitar cuatro veces se muestra en la Figura 6. Cuando se llama al método socket.close () en el código del cliente o cuando finaliza el proceso, se enviará un mensaje final FIN al servidor. Se devuelve el mensaje ACK, pero tendrá que esperar hasta que se envíe el código del servidor. Solo después de llamar a un código como socket.close() se puede enviar el mensaje final FIN al cliente. Después de eso, el cliente envía un mensaje ACK al servidor y. El proceso se completa agitando cuatro veces.
El ACK y FIN en el medio aquí no se pueden combinar, porque el ACK lo envía el kernel del sistema, por lo que se enviará inmediatamente cuando el servidor reciba el mensaje FIN, pero el mensaje FIN tendrá que esperar hasta que el código del lado del servidor ejecuta el socket. Se puede enviar después de close (), y hay una diferencia de tiempo entre los dos. Pero hay una manera de combinar los dos. En circunstancias especiales, el ACK se puede enviar con retraso, de modo que pueda enviarse junto con el FIN.
Además, hay dos estados involucrados en los cuatro procesos de agitación. El primero es el estado close_wait. Este estado es el estado en el que se encuentra el receptor después de recibir el mensaje FIN del remitente. El otro estado es time_wait. que la parte debe esperar después de recibir el FIN enviado por el receptor y luego enviar un ACK al receptor. La conexión no se puede desconectar inmediatamente porque es necesario evitar que se pierda el último ACK enviado por el remitente al receptor. el receptor retransmite el FIN para garantizar que el remitente aún pueda recibir este FIN, el tiempo en este estado suele ser 2 MSI (MSI: el tiempo máximo para la transmisión de datos en ambos extremos), que suele ser de 2 minutos.
Si se encuentra una gran cantidad de close_wait en el receptor, significa que el método close () se ha olvidado. Si se encuentra una gran cantidad de time_wait en el servidor, significa que el servidor ha activado una gran cantidad de desconexión TCP activa. operaciones.
TCP necesita garantizar una transmisión confiable, pero al mismo tiempo quiere completar la transmisión de datos de la manera más eficiente posible. La ventana deslizante es un mecanismo para mejorar la eficiencia. En realidad, esta es una forma de compensarlo, porque para garantizar la confiabilidad, TCP sacrifica mucho rendimiento, no importa cómo deslice la ventana, la velocidad de transmisión de datos no puede ser más rápida que UDP.
Figura 7
Como se muestra en la Figura 7, este es el proceso de transmisión de datos, pero el proceso de enviar un paquete de datos y recibir un paquete de datos de respuesta aún es relativamente lento.
Figura 8
Como se muestra en la Figura 8, esto ocurre después de introducir el mecanismo de ventana deslizante, en lugar de enviar un paquete de datos sino varios paquetes de datos a la vez, el tiempo de espera de los paquetes de datos de respuesta devueltos se superpone. Sin esperar ACK, la cantidad de datos enviados en lotes es el tamaño de la ventana.
Figura 9
El proceso de ventana deslizante se muestra en la Figura 9. Supongamos que el tamaño de la ventana es de 4 grupos. Cuando un grupo recibe ACK, se enviarán nuevos datos para complementarlo, lo que equivale a un proceso de deslizamiento. Si el remitente recibe el ACK de 3001, significa que se han recibido los datos del 1001 al 3001, por lo que la ventana puede moverse dos espacios hacia la derecha.
¿Qué hacer si se produce una pérdida de paquetes en la ventana deslizante? Hay dos situaciones:
(1) El paquete de datos enviado se pierde
Si se pierde un determinado grupo de datagramas enviados, aunque envía muchos grupos de datos al receptor en lotes, el número de secuencia de confirmación del ACK recibido sigue siendo el del grupo perdido hasta que el remitente retransmite el datagrama. Por ejemplo, los datagramas 1001 ~ 2000 en la imagen de arriba se pierden. Incluso si se transmiten varios conjuntos de datos más adelante, se devolverá el ACK de 1001 hasta que el remitente lo retransmita y el receptor lo reciba, y luego responda con el ACK de 7001. .
(2) La respuesta ACK se pierde
Si se pierde el ACK de respuesta, entonces no necesita preocuparse por eso, porque simplemente puede esperar hasta que se devuelva el ACK de otros grupos de datos. Por ejemplo, si se pierde el ACK de 1001 en la imagen de arriba, se perderá. No importa. El remitente del próximo ACK de 2001 lo ha recibido. Se han recibido los datos anteriores, y lo mismo ocurre si se pierde el ACK de los datos posteriores.
El procesamiento de pérdida de paquetes mencionado anteriormente sigue siendo muy eficiente. Si el paquete de datos se pierde, simplemente llene el vacío y retransmita los datos. Si se pierde el ACK, simplemente ignórelo. Esta operación se denomina retransmisión rápida.
La retransmisión por tiempo de espera y la retransmisión rápida son estrategias diferentes adoptadas en diferentes entornos. Si su TCP transmite pocos datos y con poca frecuencia, se activará la retransmisión por tiempo de espera. Si su TCP necesita transmitir una gran cantidad de datos en un corto período de tiempo, se activará la ventana deslizante. Se activará la retransmisión rápida, la retransmisión rápida es equivalente a la variante de retransmisión por tiempo de espera bajo la ventana deslizante.
Como se mencionó anteriormente sobre la ventana deslizante, el tamaño de la ventana es variable. Puede controlar la velocidad de envío del remitente cambiando el tamaño de la ventana. Cuanto más grande es la ventana, más datos se envían por unidad de tiempo y mayor es la eficiencia. Cuanto más pequeña es la ventana, más datos se envían por unidad de tiempo. Cuanto menos datos hay, menos eficiente es. Normalmente, por supuesto, esperamos que la eficiencia sea lo más alta posible, pero el requisito previo para una alta eficiencia es garantizar la confiabilidad. Si el remitente envía demasiado rápido y el receptor no puede manejarlo, entonces puede ocurrir una pérdida de paquetes. es El receptor le dice al remitente que la velocidad de envío es demasiado rápida. Esto es "control de flujo".
Como se muestra en la figura anterior, como se mencionó anteriormente, hay un búfer de recepción de estructura de datos en el kernel y el receptor devolverá el tamaño del espacio libre en el búfer de recepción como tamaño de ventana. El encabezado TCP anterior tiene un campo de tamaño de ventana de 16 bits que usa ACK para guardar y devolver esta información. El campo de tamaño de ventana solo tendrá efecto en ACK.
Como se muestra en la figura anterior, ACK devolverá el tamaño de la ventana para lograr el propósito de control de flujo. Cuando el tamaño de la ventana vuelve a 0, el remitente enviará periódicamente mensajes de prueba que no contienen datos comerciales para activar ACK para conocer el. Estado del búfer. ¿Hay espacio libre?
El control de congestión es muy similar al control de flujo, ambos mecanismos se combinan con ventanas corredizas.
Como se muestra en la figura anterior, los enlaces de la red son muy complejos y cualquier nodo del enlace puede restringir la velocidad del remitente. La idea del control de la congestión es tratarla como un todo, sin importar cuán compleja sea su estructura intermedia, y luego encontrar el tamaño de ventana más apropiado mediante experimentos.
La figura anterior es un proceso de control de congestión. Primero pruébelo con un tamaño de ventana relativamente pequeño (inicio lento), porque no conoce la situación de congestión de la red. Después de eso, el tamaño de la ventana crecerá exponencialmente y cuando alcance. Después de un cierto umbral, comenzará a crecer linealmente y luego, cuando la ventana crezca hasta cierto punto, se producirá la pérdida de paquetes. En este momento, la ventana se reducirá inmediatamente.
(1) Reduzca directamente hasta el fondo, regrese al comienzo del inicio lento y luego repita el proceso anterior (ya abandonado)
(2) Reducir a la mitad y luego crecer linealmente (el método real utilizado)
El control de congestión consiste en utilizar experimentos para encontrar un tamaño de ventana adecuado. Si hay mucha pérdida de paquetes, reduzca el tamaño de la ventana. Si no hay pérdida de paquetes, aumente el tamaño de la ventana.
La respuesta retrasada, como sugiere el nombre, significa esperar un tiempo antes de devolver ACK. En realidad, esto también implica el problema del tamaño de la ventana, porque la respuesta retrasada de ACK le dará al receptor más tiempo para consumir los datos en el búfer de recepción, aumentando así. el tamaño del búfer libre, el tamaño de la ventana devuelta por ACK aumenta y el remitente puede enviar más datos en lotes.
Hay dos métodos de respuesta retardada:
(1) Especificar el retraso según un tiempo determinado
(2) Según la cantidad de datos recibidos
Las dos estrategias anteriores se utilizan en combinación.
De hecho, las respuestas a cuestas han aparecido antes, como un mecanismo utilizado para mejorar la eficiencia de la transmisión. Este es el caso en el que ACK y SYN se devuelven utilizando el mismo paquete de datos en el protocolo de enlace de tres vías. También existe una situación similar a la de Four Waves. Debido a que ACK y FIN se envían en momentos diferentes, no se pueden realizar respuestas paralelas. Sin embargo, con la respuesta retrasada no es necesario enviar ACK al remitente tan rápido. se puede combinar con las dos FIN. Las transmisiones secundarias se combinan en una sola transmisión aprovechando las respuestas.
El flujo de bytes es un mecanismo de TCP. Un problema al que se debe prestar atención aquí es el problema de la adherencia de paquetes. Este problema se debe a la incapacidad de distinguir los límites entre los paquetes de datos de diferentes capas de aplicación. flujo de bytes, el servidor puede leer varios bytes y también puede leer un byte, lo que puede causar fácilmente este problema.
Hay dos soluciones al problema de las bolsas adhesivas anterior:
(1) Utilice separadores
Se puede utilizar cualquier símbolo siempre que no exista en el paquete de solicitud.
(2) Acordar la longitud del paquete de datos.
Sin embargo, en la mayoría de los casos, los programadores de Java no utilizan TCP directamente, sino que utilizan protocolos ya preparados como http o implementan comunicación de red basada en herramientas como protobuffer o dubbo. Estos métodos han resuelto el problema de los paquetes fijos internamente. Perdido.
(1) En ambos extremos de la comunicación, el proceso en un extremo falló.
El sistema operativo completa cuatro ondas y agita la PCB.
(2) Cierto host se apaga (proceso normal)
La primera posibilidad es que el sistema operativo haya completado cuatro ondas. La segunda posibilidad es que el receptor no tenga respuesta ACK después de enviar el FIN. Retransmite muchas veces y luego elimina unilateralmente la conexión. eso se apaga, ya que todos están apagados. La información almacenada (memoria) naturalmente desaparece.
(3) La fuente de alimentación de un determinado host está apagada.
Cuando el host apagado es un servidor, el paquete de datos enviado por el cliente se retransmitirá sin ACK. Si no se obtiene ningún resultado después de varias retransmisiones, la conexión se eliminará.
Cuando el host apagado es un cliente y el servidor no ha recibido un paquete de datos durante mucho tiempo, enviará periódicamente un paquete de latidos sin carga útil, solo para activar un ACK. Si el cliente es normal, regresará. un ACK, de lo contrario no lo recibirá. Si no se recibe respuesta del cliente después de enviarlo varias veces seguidas pero no hay respuesta, se puede considerar que el cliente está inactivo y se elimina la información de conexión.
Además, aunque TCP implementa paquetes de latidos, el ciclo es largo. A menudo se necesitan minutos para descubrir que el cliente está inactivo a través de este paquete de latidos. En el desarrollo real, se implementarán paquetes de latidos en la capa de aplicación, con mayor frecuencia y período más corto (los paquetes de latidos de segundo nivel/milisegundos se envían A->B envía un ping y B->A responde con un pong). Una vez determinado Si el dispositivo se bloquea, podrá encontrar rápidamente el problema.
(4) El cable de red está desconectado.
Esencialmente, es el tercer caso. Si el remitente no recibe el ACK, expirará y retransmitirá, luego enviará RST y luego eliminará la conexión unilateralmente. Si el receptor no recibe el paquete de datos, enviará un paquete de latidos. Si no recibe el ACK, simplemente enviará un paquete de latidos.
Hay dos bits de bandera en la estructura del encabezado TCP que no se mencionan, a saber, PSH y URG. PSH insta a la otra parte a devolver una respuesta lo antes posible. El URG está asociado con el campo de puntero de emergencia del encabezado del paquete TCP y se usa en conjunto para controlar la transmisión de datos fuera de banda de TCP.
La transmisión de datos fuera de banda significa que, además de los datos comerciales, se utilizan algunos paquetes de datos especiales para controlar el mecanismo de funcionamiento del propio TCP.
Se ha dedicado a la investigación de tecnología durante más de 30 años y domina varios lenguajes como java, linux, javascript, php, css, etc. Ha realizado muchas contribuciones en el campo del código abierto. Estación de documentación para desarrolladores para compartir algunos problemas en el desarrollo de tecnología para referencia futura.
Correo[email protected]