Realización de una transmisión confiable de TCP (2) Mecanismo de retransmisión de TCP
¿Por qué adivinar? Porque incluso si trabaja horas extras, este paquete de datos no necesariamente se perderá. Simplemente pasé por alto la larga distancia y llegué muy tarde. Después de todo, el protocolo TCP está ubicado en la capa de transporte, por lo que es imposible saber exactamente qué está sucediendo en la capa de enlace de datos y en la capa física. Pero esto no obstaculiza nuestro mecanismo de retransmisión de tiempo de espera, porque el receptor ignorará automáticamente los paquetes duplicados recibidos.
Hablemos en detalle del mecanismo de retransmisión de TCP:
Bajo este mecanismo, cada paquete de datos tiene un temporizador correspondiente. Cuando se excede el tiempo especificado, el paquete de datos se retransmitirá sin recibir un mensaje de confirmación ACK de la otra parte.
¿Cuál debe ser el tiempo de espera?
Echemos un vistazo primero al RTT (tiempo de ida y vuelta y retraso de ida y vuelta).
Y el tiempo de espera se expresa mediante RTO (tiempo de espera de retransmisión, tiempo de retransmisión).
El tiempo de espera no debe establecerse ni demasiado largo ni demasiado corto; de lo contrario:
En resumen, el valor de configuración de RTO debe ser ligeramente mayor que el valor de RTT.
Cálculo del valor RTO:
/JXH _ 123/article/details/27345151
Vale la pena señalar que cada vez que se activa una retransmisión por tiempo de espera, el next Se establecerá un intervalo de tiempo de espera al doble del valor anterior. El tiempo de espera indica que el entorno de la red es deficiente y no adecuado para transmisiones frecuentes.
La captura de Wireshark muestra:
El problema con la retransmisión por tiempo de espera es el siguiente:
? Cuando se pierde un segmento de mensaje, esperará un cierto tiempo de espera antes de retransmitirlo, lo que aumentará el retraso de un extremo a otro;
? Cuando se pierde un segmento de mensaje, durante el proceso de tiempo de espera, puede suceder que el extremo receptor haya recibido el siguiente segmento de mensaje pero no haya sido confirmado durante mucho tiempo, y el extremo emisor lo considere perdido, lo que resultará en una retransmisión innecesaria. Una pérdida de tiempo y un desperdicio de recursos. (Por ejemplo, el paquete 5 se pierde y los paquetes 6, 7, 8 y 9 han llegado al receptor. En este momento, el cliente solo puede esperar a que el servidor envíe un ACK, por lo que para el cliente, tiene No tengo idea de cuántos paquetes se perdieron, tal vez pensando con pesimismo que todos los paquetes después de 5 se pierden, por lo que retransmitir estos 5 paquetes es un desperdicio).
Como se mencionó hace un momento, la retransmisión basada en temporizador a menudo toma un tiempo. Durante mucho tiempo, la retransmisión rápida utiliza un método muy inteligente para resolver este problema.
El mecanismo de retransmisión rápida no se basa en el tiempo, sino en los datos.
Dado que TCP utiliza un mecanismo de reconocimiento acumulativo, cuando el receptor recibe un segmento de datos con un número de secuencia mayor al esperado, enviará repetidamente el número de reconocimiento del segmento de datos de reconocimiento anterior, es decir, ACK (Duplicate ACK.
De esta manera, si se reciben tres ACK redundantes repetidos consecutivos antes de que expire el temporizador de retransmisión (el primer ACK es normal, los últimos tres son redundantes), el remitente sabrá cuál se perdió durante En el segmento de mensajes de transmisión, no es necesario esperar a que se desborde el temporizador de retransmisión, lo que mejora enormemente la eficiencia.
La captura de Wireshark muestra:
Sin embargo, la retransmisión rápida aún no se resuelve. El segundo problema. Pregunta: ¿Cuántos paquetes se deben retransmitir?
El método mejorado es SACK (reconocimiento selectivo), que simplemente devuelve el rango de números de secuencia del segmento de mensaje recibido más recientemente en función de la retransmisión rápida. para informar al cliente qué paquetes han llegado al servidor
Mira este ejemplo:
Cuando la opción SACK está presente
Cuando el 500-599. Llega el mensaje, el receptor lo envía.
¿ACK 200? , sack[500, 600]
Cuando llega el mensaje 600-699, el receptor lo envía. ¿ACK 200? , saco [500, 700]
Cuando llegue el mensaje 700-799
Cuando llegue el mensaje 800-899
Cuando llegue el mensaje 900-999, ¿Recibir la confirmación acumulativa del Partido enviada? ¿ACK 200? , SACK [500, 1000]
Después de recibir tres ACK repetidos consecutivos, el remitente verifica y descubre que se han perdido entre 200 y 499 datos y realiza una retransmisión rápida. Cuando el receptor recibe datos del 200 al 499 y devuelve ACK 1000, todos los datos del remitente han sido reconocidos y la ventana deslizante se mueve a la posición 1000.
SACK se puede utilizar para decirle al remitente qué datos se han recibido. Después de que el remitente reciba estos mensajes, sabrá qué datos se han perdido y luego retransmitirá inmediatamente la parte perdida.
Cabe señalar que SACK sólo se puede enviar cuando se recibe un paquete desordenado.
SACK incluye dos opciones TCP. Una opción utilizada para identificar si se admite SACK (SACK_Permitted), que se envía cuando TCP establece una conexión. Otra opción contiene información específica de SACK.
(1)Opción SACK_Permitted
Al establecer una conexión TCP, esta opción solo se permite configurar en paquetes marcados con SYN. Durante la fase de establecimiento de la conexión, la parte que inicia la conexión especifica activamente opciones en su SYN. El mecanismo SACK solo se habilitará después de recibir esta opción del SYN de la otra parte.
(2) Opción de información SACK
El parámetro de opción SACK le dice a la otra parte los bloques de datos discontinuos que se han recibido y almacenado en caché. El remitente puede usar esta información para verificar qué bloque es. perdido y luego enviar el bloque de datos correspondiente.
? Borde izquierdo: el primer número de secuencia del bloque. Borde derecho: el número de secuencia al lado del último número de secuencia del bloque.
El número de secuencia ACK en el intervalo [borde izquierdo, borde derecho] indica el número de secuencia recibido esta vez.
Pregunta 1: ¿Cuántos bloques puede contener como máximo la opción saco?
Dado que la longitud máxima del encabezado TCP es de 60 bytes, el encabezado fijo ocupa 20 bytes y la opción SACK en sí ocupa 2 bytes, los 60-20-2 restantes = 38 bytes. Cada bloque (incluyendo inicio y final) ocupa 8 bytes, por lo que el número máximo de bloques reconocidos es 38/8 = 4 bloques, por lo que el SACK puede incluir hasta 4 bloques para ser retransmitidos. Al mismo tiempo, dado que SACK a veces se usa junto con la marca de tiempo (ocupa 10 bytes), en este caso solo hay tres SACK como máximo.
Pregunta 2: 2: ¿Cuáles son las reglas para usar la opción SACK?
El remitente de SACK es el receptor del mensaje.
El primer bloque debe indicar qué mensaje entrante activó el SACK.
Rellena tantos bloques como puedas.
SACK informa el bloque de datos no contiguo recibido más recientemente.
El receptor de SACK es el remitente del mensaje:
Los datos permanecerán en la ventana deslizante hasta que sean reconocidos.
Cada paquete tiene un mensaje etiquetado que será ignorado cuando se vuelva a recibir.
? Si se pierde SACK, el indicador SACK de todos los paquetes se restablece después del tiempo de espera y la retransmisión.
DSACK es una extensión de SACK y se utiliza principalmente para manejar mensajes duplicados recibidos.
Su función principal es indicar al remitente qué datos se han recibido repetidamente.
DSACK también utiliza el mismo formato de mensaje que SACK, la única diferencia es que el primer bloque consecutivo especifica el espacio del número de secuencia del mensaje duplicado que activa DSACK. Si el rango del primer segmento está cubierto por el rango ACK, es un DSACK. En otras palabras, el rango del primer segmento está cubierto por el SACK del segundo segmento, por lo que es DSACK.
Las ventajas de introducir DSACK son las siguientes:
1) Permite al remitente saber si el paquete enviado se pierde o el paquete ACK devuelto
<; p>2) ¿Su configuración de tiempo de espera es demasiado pequeña, lo que provoca la retransmisión?3) En la red, hay situaciones en las que los paquetes se envían primero y llegan más tarde (también llamado desorden de paquetes);
4) ¿Se están copiando mis paquetes a través de la red?
En resumen, el propósito de DSACK es ayudar al remitente a determinar si hay reordenamiento de paquetes, pérdida de ACK, duplicación de paquetes o retransmisión falsa, para que TCP pueda controlar mejor el tráfico de la red.
El mecanismo de retransmisión por tiempo de espera puede resolver el problema de la pérdida de paquetes, pero tiene problemas como tiempos de espera prolongados, tiempo de espera desperdiciado, eficiencia de transmisión reducida y no saber qué paquetes deben retransmitirse. La retransmisión rápida puede resolver el problema del largo tiempo de espera para la retransmisión por tiempo de espera, pero aún no puede resolver de manera efectiva el problema de qué paquetes retransmitir. SACK puede saber qué paquetes deben retransmitirse. Puede saber qué paquetes han sido reconocidos y el cliente puede juzgar qué paquetes deben retransmitirse. Como medio auxiliar de SACK, DSACK se puede utilizar para determinar qué está sucediendo en la red y controlar el tráfico de la red en consecuencia.