Tabla de contenido
Mayor confiabilidad con números de serie y reconocimientos
¿Por qué TCP es un apretón de manos de tres vías?
Mecanismo de retransmisión de tiempo de espera
Aumente la velocidad con el control de ventana
Control de ventana y control de retransmisión
UDP
UDP es un protocolo de datagramas poco fiable. El procesamiento sutil se entregará a la aplicación superior para que lo complete. En el caso de UDP, aunque se puede garantizar el tamaño del mensaje enviado, no hay garantía de que el mensaje llegue. Por lo tanto, la aplicación a veces realiza un procesamiento de retransmisión de acuerdo con sus propias necesidades. La velocidad de transmisión rápida y la naturaleza sin conexión de UDP lo hacen más adecuado para escenarios de comunicación en tiempo real, como juegos en línea y transmisión de video.
formato de protocolo UDP
- Número de puerto de origen (Source Por): el campo tiene una longitud de 16 bits. Este campo es opcional y, en ocasiones, es posible que no se establezca el número de puerto de origen. Cuando no hay un número de puerto de origen, el valor de este campo se establece en 0. Se puede utilizar en comunicaciones que no requieran devolución.
- Número de puerto de destino (Destination Por): Indica el puerto del extremo receptor y la longitud del campo es de 16 bits.
- Longitud: este campo almacena la suma de la longitud del encabezado UDP y la longitud de los datos. La unidad es byte (octeto).
- Checksum (Checksum): Checksum está diseñado para proporcionar encabezados y datos UDP invocables. Al calcular la suma de verificación, se agrega antes del pseudoencabezado UDP y el datagrama UDP. Aumente la longitud total por un factor de 16 agregando un "0" en el último dígito. En este momento, el campo de suma de comprobación del encabezado UDP se establece en "0". Luego realice una suma de complemento a 1 en unidades de 16 bits y escriba la suma de complemento a 1 obtenida en el campo de suma de verificación. Después de que el host receptor recibe el datagrama UDP, obtiene la información de la dirección IP del encabezado IP para construir el Pseudoencabezado UDP, y luego realice el cálculo de la suma de verificación. El valor del campo de suma de verificación es la suma del complemento a 1 del resto del campo de suma de verificación. Por lo tanto, la suma de todos los datos, incluido el campo de suma de verificación, es "16. Los datos recibidos se consideran correctos solo cuando todos los bits son 1". Además, la suma de verificación no se puede usar en UDP. En este momento, el campo de suma de verificación se llena con 0. En este caso, debido a diferentes Al realizar el cálculo de la suma de verificación, se reducirá la sobrecarga del procesamiento del protocolo, lo que puede aumentar la velocidad de reenvío de datos.
El proceso de transmisión UDP es similar al envío de una carta. Sin conexión: si conoce la IP y el número de puerto del par, puede transmitir directamente sin establecer una conexión; No confiable: no hay mecanismo de confirmación ni mecanismo de retransmisión; si el el segmento no se puede enviar debido a una falla en la red Por otro lado, la capa de protocolo UDP no devolverá ninguna información de error a la capa de aplicación; orientado a datagramas: el número y la cantidad de datos de lectura y escritura no se pueden controlar de manera flexible; el segmento orientado a datagramas capa de aplicación entregó a UDP la longitud del mensaje, y UDP lo envía tal cual, sin dividir ni fusionar; use UDP para transmitir 100 bytes de datos: si el remitente llama a sendto una vez para enviar 100 bytes, entonces el receptor también debe llame al recvfrom correspondiente una vez para recibir 100 bytes; en lugar de llamar a recvfrom 10 veces en un bucle, se reciben 10 bytes cada vez.
UDP no tiene un búfer de envío real. La llamada a sendto se transferirá directamente al núcleo, y el núcleo pasará los datos al protocolo de capa de red para las acciones de transmisión posteriores; UDP tiene un búfer de recepción. Pero este búfer de recepción no puede garantizar que la secuencia de paquetes UDP recibidos sea coherente con la secuencia de envío de paquetes UDP; si el búfer está lleno, los datos UDP que llegan se descartarán. UDP es comunicación full-duplex.
TCP
TCP es un protocolo de transmisión confiable y orientado a la conexión. Una secuencia es una estructura de datos ininterrumpida y puede pensar en ella como el flujo de agua en un desagüe. Cuando el programa de aplicación utiliza TCP para enviar información, aunque se puede garantizar el orden de envío, es como si se enviara un flujo de datos sin ningún intervalo al extremo receptor. Para proporcionar una transmisión confiable, TCP implementa un mecanismo de "control de secuencia" o "control de retransmisión". Además, tiene muchas funciones, como "control de flujo (flow control)", "control de congestión" y mejora de la utilización de la red.
formato de protocolo TCP
No hay ningún campo en TCP para indicar la longitud del paquete y la longitud de los datos. La longitud del paquete TCP se puede conocer a partir de la capa IP.La longitud de los datos se puede conocer a partir de la longitud del paquete TCP.
número de puerto de origen
Indica el número de puerto del extremo emisor y la longitud del campo es de 16 bits.
número de puerto de destino
Indica el número de puerto del extremo receptor y la longitud del campo es de 16 bits.
número de serie
El campo tiene una longitud de 32 bits. El número de serie (también llamado a veces número de serie) se refiere a la ubicación donde se envían los datos. Cada vez que se envían datos, el tamaño del número de bytes de los datos se acumula - veces. El número de serie no comienza con 0 o 1, sino que es un número aleatorio generado por la computadora como su valor inicial cuando se establece la conexión y se envía al host receptor a través del paquete SYN. Luego agregue el número de bytes reenviados cada vez al valor inicial para indicar la posición de los datos. Además, aunque el paquete SYN y el paquete FIN enviados cuando se establece y desconecta la conexión no transportan datos, también aumentarán el número de serie correspondiente como un byte.
Confirmar número de respuesta
El campo Número de acuse de recibo tiene una longitud de 32 bits. Se refiere al número de serie de los datos que deben recibirse la próxima vez. En la práctica, se refiere a los datos hasta el dígito que precede al número de acuse de recibo que se ha recibido. Después de recibir la respuesta de confirmación, el remitente puede considerar que los datos anteriores a este número de secuencia se han recibido con normalidad.
compensación de datos
Este campo indica qué bit del paquete TCP debe comenzar a calcular la parte de datos transmitida por TCP. Por supuesto, también se puede considerar como la longitud del encabezado TCP. Este campo tiene una longitud de 4 bits y la unidad es de 4 bytes (es decir, 32 bits). Si el campo de opción no está incluido, el encabezado TCP tiene una longitud de 20 bytes, por lo que el campo de compensación de datos se puede establecer en 5. Por el contrario, si el valor de este campo es 5, significa que desde el principio hasta los 20 bytes del paquete TCP todos son encabezados TCP y el resto son datos TCP.
reservar
Este campo se usa principalmente para futuras expansiones y su longitud es de 4 bits. Generalmente se establece en 0, pero incluso si el paquete recibido no es 0 en este campo, este paquete no se descartará.
bit de control
La longitud del campo es de 6 bits y cada bit es URG, ACK, PSH, RST, SYN, FIN de izquierda a derecha. Estos indicadores de control también se denominan bits de control. Cuando el valor de su bit correspondiente es 1, el significado específico es el siguiente:
- URG: cuando este bit es 1, significa que hay datos urgentes en el paquete. Para los datos que necesitan ser utilizados con urgencia, se explicará más adelante en el puntero urgente.
- ACK: cuando este bit está activado, el campo de la respuesta de reconocimiento se vuelve válido. TCP especifica que este bit debe establecerse en 1 excepto para el paquete SYN cuando la conexión se establece inicialmente.
- PSH: cuando este bit es 1, significa que los datos recibidos deben transmitirse inmediatamente al protocolo de aplicación de la capa superior. Cuando el PSH es 0, no es necesario transmitirlo de inmediato, pero primero debe almacenarse en caché.
- RST: cuando este bit es 1, significa que se produce una excepción en la conexión TCP y la conexión debe desconectarse a la fuerza. Por ejemplo, un puerto no utilizado no puede comunicarse incluso si se envía una solicitud de conexión. En este punto, se puede devolver un paquete con RST establecido en 1. Además, si el host se reinicia debido a fallas del programa o cortes de energía, toda la información de conexión se inicializará, por lo que la comunicación TCP original no continuará. En este caso, si el socio de comunicación envía un paquete RST establecido en 1, la comunicación se desconectará a la fuerza.
- SYN: Se utiliza para establecer una conexión. Si SYN es 1, significa que se espera que se establezca una conexión y el valor inicial del número de serie se establece en el campo de su número de serie.
- FIN: Cuando este bit es 1, significa que no habrá más datos para enviar en el futuro, y se espera desconectar. Cuando finaliza la comunicación y se va a desconectar, los hosts de ambos lados de la comunicación pueden intercambiar los segmentos TCP cuya posición FIN es 1. Después de que cada host confirme y responda al paquete FIN de la otra parte, puede desconectarse. Sin embargo, después de recibir el segmento TCP con FIN establecido en 1, el host no necesita responder un paquete FIN inmediatamente, pero puede esperar hasta que todos los datos en el búfer se eliminen automáticamente porque se enviaron correctamente antes de enviarlos.
Tamaño de la ventana
Este campo tiene una longitud de 16 bits. Se utiliza para notificar el tamaño de los datos (octetos) que se pueden recibir desde la posición indicada por el número de reconocimiento de la misma cabecera TCP. TCP no permite enviar datos más grandes que el tamaño que se muestra aquí. Sin embargo, si la ventana es 0, significa que se puede enviar una sonda de ventana para conocer el último tamaño de la ventana. Pero estos datos deben ser de 1 byte.
suma de control
Las sumas de verificación para TCP son similares a UDP. La diferencia es que la suma de comprobación de TCP no se puede desactivar.
TCP, como UDP, utiliza el pseudoencabezado TCP al calcular la suma de comprobación. Para que su longitud total sea un múltiplo entero de 16 bits, es necesario completar 0 al final de la parte de datos. Primero establezca el campo de suma de comprobación TCP en 0. Luego realice el cálculo de la suma del complemento a 1 en unidades de 16 bits y coloque la suma del complemento a 1 de su suma en el campo de suma de verificación. Después de recibir el segmento de datos TCP, el extremo receptor obtiene la información de la dirección IP del encabezado IP para construir el pseudoencabezado TCP y luego calcula la suma de verificación. Dado que el campo de suma de verificación guarda el valor complementario de la suma de otras partes excepto este campo, si se calcula la suma de 16 bits de todos los datos, incluido el campo de suma de verificación, el resultado es "los 16 bits son 1". Indica que los datos recibidos son correcto.
Puntero urgente
Este campo tiene una longitud de 16 bits. Solo es válido cuando el bit de control URG es 1. El valor de este campo indica el puntero de los datos urgentes en este segmento. Más precisamente, los datos urgentes van desde el encabezado de la parte de datos hasta la posición indicada por el puntero urgente. Por lo tanto, también se puede decir que el puntero urgente señala la posición del final de los datos urgentes en el segmento del mensaje. Cómo manejar datos urgentes es un problema de aplicación. Generalmente se utiliza cuando la comunicación se interrumpe temporalmente o cuando se interrumpe la comunicación. Por ejemplo, al hacer clic en el botón de detener en el navegador web, o usar TELNET para ingresar Ctrl+C, habrá un paquete con URG de 1. Además, el puntero urgente también se utiliza como bandera para indicar la fragmentación del flujo de datos.
Opciones
El campo de opciones se utiliza para mejorar el rendimiento de transmisión de TCP. Debido a que se controla de acuerdo con el desplazamiento de datos (longitud del encabezado), su longitud es de hasta 40 bytes. Además, el campo de opción debe ajustarse a un múltiplo entero de 32 bits tanto como sea posible.
Mayor confiabilidad con números de serie y reconocimientos
Mediante el uso de números de secuencia y mecanismos de reconocimiento, TCP puede garantizar la corrección y confiabilidad de los paquetes de datos transmitidos.
En TCP, cuando los datos del remitente llegan al host receptor, el host receptor devolverá una notificación de que se recibió el mensaje. Este mensaje se denomina acuse de recibo (ACK).
Por lo general, cuando dos personas están hablando, pueden asentir con la cabeza o preguntar en las pausas de la conversación para confirmar el contenido de la conversación. Si no hay comentarios de la otra parte durante mucho tiempo, la parte que habla puede repetirlo nuevamente para asegurarse de que la otra parte realmente lo escuchó. Por lo tanto, si la otra parte entiende el contenido de la conversación y si la otra parte ha escuchado completamente el contenido de la conversación depende de la reacción de la otra parte para juzgar. Una "respuesta de reconocimiento" en la creación de redes es algo como esto: un concepto. Cuando la otra parte comprenda el contenido de la conversación, dirá: "Bueno", lo que equivale a devolver una respuesta de reconocimiento (ACK). Y cuando la otra parte no entendía el contenido de la conversación o no lo escuchaba claramente, preguntaba "¿Eh?" Esto es como una respuesta de reconocimiento negativo (NACK).
TCP logra una transmisión de datos confiable a través de respuestas de reconocimiento positivo (ACK). Cuando el remitente envía los datos, esperará la respuesta de confirmación del par. Si hay una respuesta de reconocimiento, significa que los datos han llegado con éxito al par. Por el contrario, la posibilidad de pérdida de datos es muy alta.
Si no hay respuesta de confirmación dentro de un cierto período de tiempo, el remitente puede considerar que los datos se han perdido y reenviarlos. Por lo tanto, incluso si ocurre una pérdida de paquetes, aún puede garantizar que los datos puedan llegar al extremo opuesto y realizar una transmisión confiable.
El hecho de no recibir un acuse de recibo no significa que los datos se pierdan necesariamente. También es posible que la otra parte haya recibido los datos, pero la respuesta de confirmación devuelta se haya perdido en el camino. Esta situación también hará que el remitente vuelva a enviar los datos porque no ha recibido el acuse de recibo y piensa que los datos no han llegado al destino.
Además, también es posible que la respuesta de reconocimiento se retrase debido a otros motivos, y no es raro que el reconocimiento llegue después de que el host de origen reenvíe los datos. En este punto, el host emisor de origen solo necesita reenviar los datos de acuerdo con el mecanismo. Pero para el host de destino, esto es simplemente un "desastre". Recibirá los mismos datos una y otra vez. Para proporcionar una transmisión confiable para las aplicaciones de la capa superior, se deben descartar los paquetes de datos duplicados. Por esta razón, es necesario introducir un mecanismo que pueda identificar si los datos han sido recibidos y pueda juzgar si pueden recibirse.
Las funciones mencionadas anteriormente, como el procesamiento de respuesta de acuse de recibo, el control de retransmisión y el control de repetición, se pueden realizar a través del número de serie. El número de serie es un número de serie que asigna un número a cada byte (byte de 8 bits) de los datos enviados en secuencia. El extremo receptor consulta el número de serie y la longitud de los datos en el encabezado TCP de los datos recibidos y devuelve el número de serie que debería recibir en el siguiente paso como respuesta de reconocimiento. De esta forma, a través del número de secuencia y el número de respuesta de confirmación, TCP puede realizar una transmisión confiable.
El valor inicial del número de serie no es 0. En cambio, es generado por un número aleatorio después de que se establece la conexión. El cálculo posterior es sumar 1 a cada byte.
¿Por qué TCP es un apretón de manos de tres vías?
El protocolo de enlace de tres vías es un proceso utilizado para establecer una conexión en el protocolo TCP, cuyo objetivo principal es garantizar la confiabilidad y seguridad de la comunicación y evitar la inestabilidad de la red y la pérdida de paquetes de datos.
Específicamente, el proceso de apretón de manos de tres vías es el siguiente:
El cliente envía un mensaje SYN (SYN=1) al servidor, indicando que quiere establecer una conexión y le dice al servidor que su número de serie inicial es x.
Después de recibir el mensaje SYN del cliente, el servidor confirma la recepción y devuelve un mensaje ACK (ACK=1), y al mismo tiempo envía un mensaje SYN (SYN=1), diciéndole al cliente que desea establecer una conexión, y su número de secuencia inicial es y.
Después de recibir el mensaje SYN del servidor, el cliente también envía un mensaje ACK (ACK=1), diciéndole al servidor que ha recibido el mensaje SYN del servidor y acepta establecer una conexión.
La razón por la que este proceso requiere un protocolo de enlace de tres vías es para garantizar que los estados del cliente y el servidor sean coherentes y correctos. Después del primer protocolo de enlace, mientras el servidor espera el segundo protocolo de enlace, si el primer mensaje SYN se pierde o llega tarde, el servidor pensará que hay una nueva solicitud de conexión, pero el cliente no necesariamente inicia una conexión, por lo tanto, el servidor debe esperar la confirmación del segundo protocolo de enlace para confirmar que el cliente realmente desea establecer una conexión. El segundo protocolo de enlace aún requiere que el cliente responda con un ACK de confirmación para completar el establecimiento exacto de la conexión y evitar reinicios anormales.
Por lo tanto, el apretón de manos de tres vías es un protocolo de comunicación confiable y seguro, que puede prevenir de manera efectiva la transmisión de datos innecesaria y los errores de juicio, lo que garantiza la seguridad y corrección de la transmisión de datos.
por qué saludó cuatro veces
El agitar a cuatro manos es un proceso que se utiliza para liberar la conexión en el protocolo TCP. Su objetivo principal es garantizar que ambas partes en la comunicación puedan liberar la conexión con normalidad y evitar problemas como la duplicación o fuga de datos.
Específicamente, el proceso de agitar cuatro veces es el siguiente:
El cliente envía un mensaje FIN (FIN=1) para solicitar una conexión medio cerrada y que no se envíen más datos, pero los datos enviados por el servidor aún pueden aceptarse.
Después de recibir el mensaje FIN, el servidor envía un mensaje ACK (ACK=1) como confirmación y entra en el estado CLOSE_WAIT, esperando que se complete la transmisión de datos final.
El servidor cierra la transmisión, envía un mensaje FIN (FIN=1) y solicita cerrar la conexión con el cliente.
Después de que el cliente recibe el mensaje FIN, también envía un mensaje ACK (ACK=1) como confirmación, ingresa al estado TIME_WAIT y espera a que 2MSL (vida útil máxima del segmento, el tiempo de supervivencia más largo) expire después del doble del ciclo de vida máximo tiempo del mensaje Durante este período, si se recibe un mensaje FIN retransmitido, repita el paso 4 hasta que la conexión se cierre después de que expire el tiempo.
De hecho, la razón por la que se necesitan cuatro ondas cuatro veces es porque ambos extremos de la conexión necesitan realizar operaciones de confirmación para evitar datos sin procesar entre las dos partes. Específicamente, después de que el cliente envía un mensaje FIN, el servidor espera a que se complete la transmisión de datos antes de enviar el mensaje FIN. En este momento, el cliente también necesita confirmar para cerrar la conexión de manera segura.
Por lo tanto, agitar cuatro veces es un proceso para garantizar la confiabilidad e integridad de la comunicación. Solo cuando tanto el cliente como el servidor hayan completado estos cuatro pasos, la conexión se puede cerrar por completo para evitar la omisión de datos o la transmisión incorrecta.
El estado TIME_WAIT (tiempo de espera) es un estado específico en el protocolo TCP, que se utiliza para garantizar que ambas partes que se comunican puedan cerrar la conexión normalmente y liberar recursos. Durante la onda de cuatro vías, tanto el cliente como el servidor deben ingresar al estado TIME_WAIT durante un período de tiempo para completar la operación de confirmación final.
Específicamente, el cliente ingresa al estado TIME_WAIT después de enviar el último mensaje ACK (es decir, el mensaje ACK en la cuarta ola). En este estado, el cliente ya no envía ningún paquete, pero todavía puede aceptar paquetes enviados desde el servidor y espera un tiempo antes de entrar en el estado CERRADO. El tiempo específico suele ser 2MSL (Maximum Segment Lifetime, el tiempo de supervivencia más largo), que es el doble del tiempo máximo del ciclo de vida del paquete.
¿Cuál es la función de este estado? El estado TIME_WAIT puede garantizar que el servidor pueda procesar correctamente el mensaje ACK y puede evitar que se envíen repetidamente segmentos de mensajes similares a la conexión TCP cerrada debido a un retraso o retransmisión de la red. Si otro cliente intenta usar el número de puerto de la conexión cerrada, si el puerto está en el estado TIME_WAIT, entonces el nuevo mensaje SYN recibirá un mensaje RST para responder a la solicitud, lo que evita la conexión posterior del puerto cerrado A inútil se recibió el mensaje de solicitud.
En resumen, el papel del estado TIME_WAIT es garantizar que la conexión se cierre correctamente y evitar que la conexión se cierre debido a un retraso en la red o una retransmisión dentro de un cierto período de tiempo, para garantizar la estabilidad y confiabilidad del protocolo TCP. y para evitar la reutilización de puertos.
El estado CLOSE_WAIT (cerrar en espera) es un estado en el protocolo TCP, lo que significa que la conexión se cierra pasivamente, es decir, el cliente envía un mensaje FIN y solicita cerrar la conexión, y el servidor recibe el mensaje FIN y está a punto para cerrar la conexión. En este momento, el servidor debe verificar si todos los datos se han transmitido. Si los datos no se han transmitido, el servidor enviará un mensaje ACK al cliente, esperará a que se transmitan los datos y luego enviará un mensaje FIN. para cerrar la conexión. Durante este proceso, el servidor está en el estado CLOSE_WAIT, esperando que se complete la transmisión de datos final.
La duración del estado CLOSE_WAIT suele ser corta, según la velocidad y el volumen de las transferencias de datos. En la mayoría de los casos, los datos suelen transferirse rápidamente y el servidor enviará el mensaje FIN final para cerrar. Si la transferencia de datos es lenta o el volumen de datos es particularmente grande, el estado CLOSE_WAIT puede durar más.
En el estado CLOSE_WAIT, el servidor ya no recibe datos del cliente, pero aún puede enviar datos al cliente para garantizar que todos los datos se transmitan y procesen para evitar la omisión de datos y la incompletitud.
En resumen, el estado CLOSE_WAIT indica que el servidor ha recibido el mensaje FIN del cliente y espera a que se complete la transmisión de datos final antes de liberar la conexión para garantizar el cierre seguro de la conexión.
Mecanismo de retransmisión de tiempo de espera
El tiempo de espera de retransmisión se refiere al intervalo de tiempo específico para esperar un reconocimiento antes de retransmitir datos. Si pasado este tiempo no se recibe la respuesta de confirmación, el remitente reenviará los datos.
Entonces, ¿cómo determinar la duración específica del tiempo de espera de la retransmisión?
Lo ideal es encontrar un tiempo mínimo que pueda garantizar que "la respuesta de confirmación debe devolverse dentro de este tiempo". Sin embargo, el período de tiempo varía según el entorno de red en el que pasa el paquete de datos. Por ejemplo, el tiempo es relativamente corto en LAN de alta velocidad, pero debería ser más largo que en LAN en comunicaciones de larga distancia. Incluso en la misma red, la duración del tiempo cambiará según el grado de congestión de la red en diferentes períodos. TCP requiere una comunicación de alto rendimiento independientemente del entorno de la red y debe mantener esta característica independientemente de los cambios en la congestión de la red. Para ello, calcula el tiempo de ida y vuelta "y su desplazamiento" cada vez que se envía un paquete. Agregue el tiempo de ida y vuelta y la desviación, y el tiempo de espera de retransmisión es un valor ligeramente mayor que la suma.
Hay razones por las que el cálculo del tiempo de espera de retransmisión debe considerar tanto el tiempo de ida y vuelta como la desviación. Según el entorno de la red, puede haber grandes cambios en el tiempo de ida y vuelta, lo que ocurre porque los fragmentos del paquete llegan a través de diferentes cables. El propósito de TCP/IP es controlar incluso en este entorno y tratar de no desperdiciar el tráfico de la red.
En los sistemas Unix y Windows de BSD, el tiempo de espera se ha controlado en unidades de 0,5 segundos, por lo que el tiempo de espera de retransmisión es un múltiplo entero de 0,5 segundos. Sin embargo, dado que aún no se conoce el tiempo de ida y vuelta del paquete de datos inicial, su tiempo de espera de retransmisión generalmente se establece en aproximadamente 6 segundos. Después de reenviar los datos, si aún no se recibe la respuesta de confirmación, se enviará nuevamente. En este momento, el tiempo de espera de la respuesta de confirmación se extenderá con una función exponencial de 2 veces y 4 veces. Además, los datos no serán reenviados infinita y repetidamente. Después de alcanzar un cierto número de retransmisiones, si aún no se devuelve una respuesta de confirmación, se considerará que se ha producido una anomalía en la red o en el host del mismo nivel, y la conexión se cerrará a la fuerza. Y notifique a la aplicación que la comunicación se termina de forma anormal y forzada.
control de flujo
TCP puede realizar un control de flujo de acuerdo con la capacidad de procesamiento del extremo receptor para evitar que el extremo receptor no pueda procesar demasiados paquetes de datos de la otra parte.
El remitente envía datos de acuerdo a su situación real. Sin embargo, el extremo receptor puede recibir un paquete irrelevante y puede pasar algún tiempo lidiando con otros problemas. Por lo tanto, llevará algún tiempo realizar otro procesamiento para este paquete de datos, e incluso no podrá recibir ningún dato en condiciones de alta carga. De esta forma, si el extremo receptor descarta los datos que deberían haber sido recibidos, el mecanismo de retransmisión se activará nuevamente, lo que resultará en un desperdicio innecesario de tráfico de red.
Para evitar que suceda este fenómeno, TCP proporciona un mecanismo que permite al remitente controlar la cantidad de datos enviados de acuerdo con la capacidad de recepción real del receptor. Esto se llama control de flujo. Su funcionamiento específico es que el host del extremo receptor notifique al host del extremo emisor el tamaño de los datos que puede recibir, por lo que el extremo emisor enviará datos que no excedan este límite. Este límite de tamaño se denomina tamaño de la ventana. El valor del tamaño de la ventana lo determina el host receptor. En el encabezado TCP, hay un campo dedicado para notificar el tamaño de la ventana. El host receptor notifica al extremo emisor el tamaño del búfer que puede recibir en este campo. Cuanto mayor sea el valor de este campo, mayor será el rendimiento de la red.
Sin embargo, una vez que el búfer en el extremo receptor enfrenta el desbordamiento de datos, el valor del tamaño de la ventana también se establecerá en un valor más pequeño para notificar al extremo emisor, controlando así la cantidad de datos enviados. Es decir, el host emisor controlará la cantidad de datos enviados de acuerdo con las instrucciones del host receptor. Esto también forma un control de flujo TCP completo (control de flujo).
La siguiente figura es un ejemplo de cómo controlar el proceso de flujo según el tamaño de la ventana.
Cuando el extremo receptor recibe el segmento de datos que comienza en el número 3001, su búfer está lleno y tiene que dejar de recibir datos temporalmente. Posteriormente, la comunicación continúa hasta que se recibe la notificación de una actualización de la ventana de envío. Si la notificación de actualización para esta ventana se pierde en tránsito, es posible que no haya más comunicación. Para evitar tales problemas, el host emisor enviará de vez en cuando un segmento de datos llamado detección de ventana.Este segmento de datos solo contiene un byte para obtener la información más reciente sobre el tamaño de la ventana.
Aumente la velocidad con el control de ventana
TCP usa un segmento como unidad, y cada segmento se envía para una respuesta de confirmación.Este método de transmisión tiene una desventaja, es decir, cuanto mayor sea el tiempo de ida y vuelta del paquete, menor será el rendimiento de la comunicación.
Para solucionar este problema, TCP introdujo el concepto de ventana. Controla la degradación del rendimiento de la red incluso con tiempos de ida y vuelta elevados. Como se muestra en la figura a continuación, cuando la respuesta de reconocimiento ya no se encuentra en cada segmento, sino en una unidad más grande, el tiempo de reenvío se acortará considerablemente. Es decir, el host emisor no tiene que esperar la respuesta de confirmación después de enviar un segmento, sino que continúa enviando.
El tamaño de la ventana se refiere al valor máximo que puede continuar enviando datos sin esperar una respuesta de reconocimiento. El tamaño de la ventana es de 4 segmentos. Este mecanismo realiza el uso de una gran cantidad de búferes (el búfer aquí representa el lugar donde los datos enviados y recibidos se almacenan temporalmente. Por lo general, es una parte del espacio abierto en la memoria de la computadora), a través de la función de confirmación y respondiendo a múltiples segmentos al mismo tiempo. Como se muestra en la siguiente figura, la parte resaltada dentro de un círculo de los datos enviados es la ventana mencionada anteriormente. Los datos dentro de esta ventana se pueden enviar incluso si no se recibe confirmación. Sin embargo, antes de que llegue la respuesta de confirmación de toda la ventana, si se pierden algunos de los datos, el remitente sigue siendo responsable de la retransmisión. Para hacer esto, el host emisor debe configurar un caché para mantener los datos que se retransmitirán hasta que reciba su reconocimiento.
La parte fuera de la ventana deslizante incluye datos que no han sido enviados y datos que han sido confirmados para ser recibidos por el par. Cuando se envían los datos, si la respuesta de confirmación se recibe según lo programado, no es necesario volver a enviarla y los datos se pueden borrar del búfer en este momento.
Cuando se reciba la respuesta de confirmación, deslice la ventana hasta el número de serie en la respuesta de confirmación. Esto permite enviar varios segmentos de forma secuencial y simultánea para mejorar el rendimiento de la comunicación. Este mecanismo también se conoce como control de ventana deslizante.
La esencia de la ventana deslizante es un puntero o subíndice, y el tamaño de la ventana deslizante puede ser 0.
Control de ventana y control de retransmisión
El mecanismo de retransmisión de tiempo de espera y el protocolo de ventana deslizante, así como el algoritmo de control de congestión y otros mecanismos que ajustan automáticamente la velocidad de transmisión de acuerdo con la situación de congestión de la red, aseguran la estabilidad de la comunicación y mejoran la eficiencia y precisión de la transmisión.
Al usar el control de ventana, ¿qué debemos hacer si se pierde un segmento?
Primero, consideremos la situación en la que la respuesta de confirmación no regresa. En este caso, los datos ya llegaron al extremo del par y no es necesario volver a enviarlos. Sin embargo, cuando no se utiliza el control de ventana, se reenviarán los datos que no reciban un reconocimiento. Con el control de ventana, como se muestra en la figura, no es necesario volver a enviar algunos reconocimientos, incluso si se pierden.
En segundo lugar, debemos considerar el caso en el que se pierde un segmento. Si el host receptor recibe datos distintos al número de secuencia que debería recibir, devolverá una respuesta de confirmación de los datos recibidos hasta el momento.
Como se muestra abajo. Cuando se pierde un segmento de mensaje, el remitente siempre recibirá una respuesta de confirmación con un número de secuencia de 1001. Esta respuesta de confirmación parece recordarle al remitente que "Quiero recibir datos a partir de 1001". Por lo tanto, cuando la ventana es relativamente grande , y En el caso de pérdida de segmento, las respuestas de confirmación con el mismo número de secuencia se devolverán repetidamente. Si el host emisor recibe la misma respuesta de reconocimiento tres veces seguidas, volverá a enviar los datos correspondientes. Este mecanismo es más eficiente que la gestión del tiempo de espera mencionado anteriormente, por lo que también se denomina control de retransmisión de alta velocidad.
control de congestión
TCP puede ajustar automáticamente la velocidad de transmisión de acuerdo con el grado de congestión de la red para garantizar la estabilidad y confiabilidad de la red.
Con el control de ventana TCP, incluso si los hosts de envío y recepción ya no envían respuestas de confirmación en unidades de un segmento de datos, aún pueden enviar una gran cantidad de paquetes de datos de forma continua. Sin embargo, enviar grandes cantidades de datos al comienzo de la comunicación también puede causar otros problemas.
En términos generales, las redes informáticas se encuentran en un entorno compartido. Por lo tanto, también es posible que la red se congestione debido a la comunicación entre otros hosts. Cuando la red está congestionada, si de repente se envía una gran cantidad de datos, es muy probable que se paralice toda la red.
Para evitar este problema, TCP controlará la cantidad de datos enviados a través de un valor obtenido por un algoritmo llamado inicio lento al comienzo de la comunicación.
En primer lugar, para ajustar la cantidad de datos a enviar al remitente, se define un concepto denominado "ventana de congestión". Por lo tanto, en el momento del inicio lento, establezca el tamaño de la ventana de congestión en 1 segmento de datos (1MSS) para enviar datos y luego aumente el valor de la ventana de congestión en 1 cada vez que se reciba un acuse de recibo (ACK). Al enviar paquetes de datos, compare el tamaño de la ventana de congestión con el tamaño de la ventana notificado por el host receptor y luego envíe una cantidad menor de datos de acuerdo con el valor más pequeño entre ellos.
Si se utiliza el mecanismo de tiempo de espera para la retransmisión, el valor inicial de la ventana de congestión se puede establecer en 1 antes de que se realice la corrección de inicio lento. Con los mecanismos mencionados anteriormente, la congestión de la red provocada por el envío continuo de paquetes al comienzo de la comunicación puede reducirse de manera efectiva y también puede evitarse la congestión de la red. Sin embargo, con cada viaje de ida y vuelta del paquete, la ventana de congestión también aumentará con una función exponencial como 1, 2, 4, etc., y la situación de congestión aumentará considerablemente e incluso conducirá a la congestión de la red. Para evitarlos, se introduce el concepto de umbral de inicio lento. Siempre que el valor de la ventana de congestión supere este umbral, cada vez que se reciba un acuse de recibo, la ventana de congestión solo podrá ampliarse en la siguiente proporción: (
bytes de 1 segmento de datos/ventana de congestión (bytes)) x1 segmento de datos bytes
Cuanto mayor sea la ventana de congestión, mayor será el número de solicitudes confirmadas. Sin embargo, a medida que se recibe cada respuesta de confirmación, el aumento disminuirá gradualmente, incluso más pequeño que el número de bytes más pequeños que un segmento de datos. Por lo tanto, el tamaño de la ventana de congestión mostrará una tendencia ascendente lineal.
Cuando se inicia la comunicación TCP, no se establece el umbral de inicio lento correspondiente. En su lugar, se establecerá en la mitad del tamaño de la ventana de congestión en ese momento cuando se agote el tiempo de retransmisión. Las retransmisiones de alta velocidad desencadenadas por acuses de recibo duplicados se manejan de manera algo diferente a los mecanismos de retransmisión de tiempo de espera. Debido a que el primero requiere que se activen al menos 3 segmentos de datos de respuesta de confirmación después de llegar al otro host, la congestión de la red del último es menor que la del último. Mientras se realiza el control de retransmisión de alta velocidad mediante respuestas de reconocimiento repetidas, el umbral de inicio lento se establece en la mitad del tamaño de la ventana actual. Luego, el tamaño de la ventana se establece en el umbral de inicio lento + el tamaño de 3 segmentos de datos. Con dicho control, la ventana de congestión de TCP cambia como se muestra en la figura anterior. Dado que el tamaño de la ventana afectará directamente el rendimiento cuando se reenvían los datos, en general, cuanto mayor sea la ventana, se formará una comunicación de mayor rendimiento. Cuando se inicia la comunicación TCP, el rendimiento de la red aumentará gradualmente, pero a medida que se produzca la congestión de la red, el rendimiento también disminuirá rápidamente. Por lo tanto, entrará en el proceso de aumentar lentamente el rendimiento nuevamente. Por lo tanto, las características del llamado rendimiento de TCP parecen estar ocupando gradualmente la sensación de ancho de banda de la red.
Algoritmo de Nagle
Para mejorar la utilización de la red para T en TCP, a menudo se usa un algoritmo llamado Nagle. Este algoritmo se refiere a un mecanismo de procesamiento que retrasa el envío incluso si el extremo del envío todavía tiene datos que deben enviarse, pero si esta parte de los datos es muy pequeña. En concreto, los datos sólo podrán ser enviados bajo alguna de las siguientes condiciones. Si no se cumplen las dos condiciones, espere un tiempo antes de enviar los datos.
- Cuando todos los datos enviados han recibido un reconocimiento
- Cuándo se pueden enviar datos con la longitud máxima del segmento
De acuerdo con este algoritmo, aunque se puede mejorar la utilización de la red, puede ocurrir cierto grado de retraso. Por esta razón, cuando se usa TCP en áreas como sistemas de ventanas y control mecánico, la habilitación de este algoritmo a menudo se desactiva.
acuse de recibo retrasado
Un host que recibe datos puede devolver una ventana más pequeña si responde inmediatamente con un reconocimiento cada vez. Eso es porque los datos acaban de recibirse y el búfer está lleno. Cuando un extremo receptor recibe la notificación de esta pequeña ventana, la usará como límite superior para enviar datos, por eso se introduce un método, es decir, no devuelve la respuesta de confirmación inmediatamente después de recibir los datos, sino lo retrasa por un período de tiempo. .
- No se realizará ningún reconocimiento hasta que se reciban los datos con una longitud máxima de segmento de 2x (según el sistema operativo, puede haber casos en los que se devuelva el reconocimiento tan pronto como se reciban dos paquetes, independientemente del tamaño de los datos).
- En otros casos, el retraso máximo es de 0,5 segundos para enviar la respuesta de confirmación (muchos sistemas operativos se establecen en unos 0,2 segundos)
Si el retraso es superior a 0,5 segundos, es posible que el remitente vuelva a enviar los datos. Cuanto menor sea este tiempo, mayor será la carga de la CPU y el rendimiento también disminuirá. Por el contrario, cuanto mayor sea este tiempo, más probable es que active el procesamiento de retransmisión del host emisor y, cuando la ventana tiene solo un segmento de datos, el rendimiento también se degradará.
De hecho, no hay necesidad de un reconocimiento para cada segmento de datos. TCP utiliza un mecanismo de control de ventana deslizante. Por lo tanto, generalmente está bien confirmar que hay menos clientes. En la transmisión de archivos TCP, la mayoría de ellos devuelve una respuesta de reconocimiento cada dos segmentos de datos.
a cuestas
De acuerdo con el protocolo de la capa de aplicación, el mensaje enviado llega al extremo del par y, después de que el extremo del par lo procese, se devolverá un recibo. Por ejemplo, el SMTP o POP del protocolo de correo electrónico, la parte de control de conexión del protocolo de transferencia de archivos FIP y similares. Estos protocolos de aplicación utilizan la misma conexión para el intercambio de datos. Incluso el protocolo HTTP de la WWW es el mismo desde la versión 1.1 en adelante. Para otro ejemplo, en el inicio de sesión remoto, el cheque de devolución de los caracteres ingresados también es una especie de recibo por enviar el mensaje. (La verificación de bucle invertido significa que en el inicio de sesión remoto, los caracteres ingresados desde el teclado llegan al servidor y luego regresan al cliente). Cuando las personas en áreas rurales van al mercado a vender cerdos, arrastran algunas canastas en la parte posterior del cerdos por cierto
La escena donde las verduras son llevadas juntas al mercado. De hecho, significa por cierto, por cierto.
En este tipo de comunicación, los datos de reconocimiento y recepción de TCP se pueden enviar en un paquete. Este método se llama piggybacking. A través de este mecanismo, se puede reducir la cantidad de datos enviados y recibidos. Además, si se devuelve un acuse de recibo inmediatamente después de recibir los datos, no se puede realizar el seguimiento. En su lugar, pasa los datos recibidos a la aplicación para que los procese y genere los datos de devolución, y luego procede a enviar la solicitud, debiendo esperar el envío de la respuesta de confirmación. Es decir, no es posible llevar a cuestas sin habilitar reconocimientos retrasados. La respuesta de reconocimiento retrasada es un mejor mecanismo de procesamiento que puede mejorar la utilización de la red y reducir la carga de procesamiento de la computadora.
En las aplicaciones de Internet, el protocolo TCP juega un papel importante, actúa como una importante garantía de transmisión en el proceso de transmisión de datos al garantizar la estabilidad, integridad y confiabilidad de la transmisión. Comprender las características básicas y el proceso de implementación del protocolo TCP es de gran importancia para mejorar el nivel de aplicación de la tecnología de redes informáticas. Por supuesto, el protocolo TCP todavía tiene algunas deficiencias, como restricciones en el ancho de banda de la red y la carga y el impacto en los protocolos de la capa de aplicación, etc., que pueden optimizarse y mejorarse en aplicaciones prácticas para satisfacer mejor las necesidades del usuario.
El búfer TCP es el área de intercambio de datos entre el extremo emisor y el extremo receptor.Es un espacio de almacenamiento para almacenar temporalmente paquetes de datos. Durante la transmisión, el búfer TCP asignará y administrará dinámicamente los recursos de memoria para hacer frente a diferentes cargas de transmisión de datos y niveles de congestión de la red.
En el extremo de envío, el búfer TCP se utiliza principalmente para almacenar paquetes de datos que se enviarán y enviar información de control, como el número de secuencia, el número de confirmación, el tamaño de la ventana, etc. El extremo emisor coloca los datos en el búfer y luego envía el paquete de datos al extremo receptor de acuerdo con la congestión de la red. Si el extremo receptor no puede recibir el paquete de datos, el extremo emisor almacenará automáticamente en caché de acuerdo con el tamaño de la ventana de la otra parte para garantizar el control de flujo y la transmisión de datos estable.
En el extremo receptor, el búfer TCP se utiliza para almacenar paquetes de datos recibidos pero no procesados, como paquetes de datos pendientes e información de reconocimiento. El extremo receptor colocará el paquete de datos en el búfer, analizará el paquete de datos y lo confirmará y procesará de acuerdo con el número de confirmación y otra información del paquete de datos. Si un paquete de datos no llega o se envía incorrectamente o repetidamente, el búfer en el extremo receptor realizará operaciones como desduplicación, reorganización y clasificación de los datos para garantizar la exactitud y continuidad de los datos, y luego enviará un ACK a el extremo de envío, que indica que el paquete de datos se ha enviado, se recibe y se libera espacio en el búfer para que se puedan recibir más paquetes.
Cabe señalar que, en el uso real, el rendimiento de TCP puede verse afectado al ajustar el tamaño del búfer. Si el búfer es demasiado grande, aunque puede admitir más transmisión de datos, puede causar congestión y retrasos en la red; si el búfer es demasiado pequeño, se pueden perder paquetes de datos o se reducirá la eficiencia de la transmisión de datos. Por lo tanto, es necesario ajustar el tamaño de búfer apropiado según el entorno de red específico y los requisitos de la aplicación.
Diferencia entre TCP y UDP
Algunas personas pueden pensar que, dado que TCP es un protocolo de transporte confiable, debe ser mejor que UDP. en realidad no. Las ventajas y desventajas de TCP y UDP no se pueden comparar de manera simple y absoluta.
TCP se usa cuando es necesaria una entrega confiable en la capa de transporte. Debido a que está orientado a la conexión y tiene mecanismos como el control de secuencia y el control de retransmisión, puede proporcionar una transmisión confiable para las aplicaciones.
Por un lado, UDP se utiliza principalmente para comunicaciones o comunicaciones de difusión que tienen altos requisitos de transmisión de alta velocidad y rendimiento en tiempo real. Tomemos un ejemplo de hacer una llamada a través de un teléfono IP. Si se usa TCP, si los datos se pierden durante la transmisión, se volverán a enviar, pero esto no puede transmitir la voz de la persona que llama sin problemas, lo que conducirá a la falla de la comunicación normal. Con UDP, no realiza el procesamiento de retransmisión. Por lo tanto, no habrá problema de retraso en la llegada del sonido. Incluso si se pierden algunos datos, solo afectará a una pequeña cantidad de llamadas. Además, se utiliza UDP en lugar de TCP para comunicaciones de difusión y multidifusión. Los protocolos basados en difusión, como RIP y DHCP, también se basan en UDP.
Por lo tanto, TCP y UDP deben usarse según sea necesario de acuerdo con el propósito de la aplicación.