NewReno y SACK del algoritmo de control de congestión TCP
El algoritmo de recuperación rápida propuesto por TCP Reno mejora el rendimiento y la solidez de los mensajes perdidos, pero:
Solo considera la pérdida de un solo mensaje cada vez que ocurre una congestión. .
En las redes reales, una vez que se produce la congestión, los enrutadores descartarán una gran cantidad de paquetes. Es decir, es común perder varios paquetes en una congestión.
La siguiente figura muestra la conversión mutua entre el estado de recuperación rápida y el estado de evitación de congestión en el algoritmo de Reno:
Por lo tanto, la red descarta múltiples paquetes de datos en una congestión, lo cual es bloqueado por TCP Reno analizó incorrectamente esto como múltiples congestiones en la transmisión. Una reducción excesiva de la ventana provoca que se produzcan tiempos de espera de transmisión. Por lo tanto, para mejorar el rendimiento de TCP al descartar múltiples paquetes en una congestión, es necesario reducir el comportamiento de los terminales TCP al cortar ciegamente las ventanas de transmisión.
Nuevo Reno: Mejora basada en el algoritmo de Reno
NewReno TCP ha modificado el algoritmo de recuperación rápida basado en Reno TCP Cuando solo se pierde un paquete, su mecanismo es el mismo que el de Reno TCP. Reno. Lo mismo. Sus ventajas se muestran en situaciones en las que se pierden varios paquetes simultáneamente.
En el algoritmo de recuperación rápida de Reno, el remitente sale del estado de recuperación rápida después de recibir un nuevo ACK, mientras que en el algoritmo New Reno, el remitente sale del estado de recuperación rápida solo después de que se hayan respondido todos los mensajes.
NewReno TCP agrega una función de juicio de respuesta de recuperación y mejora la capacidad del terminal TCP para analizar el estado de transmisión del mensaje a través de la información del mensaje ACK.
El terminal TCP puede distinguir entre la situación de pérdida de múltiples mensajes en una congestión y la situación de múltiples congestiones, y luego la ventana de congestión solo se reduce a la mitad una vez después de cada congestión, lo que mejora la robustez y el rendimiento de TCP. .
Dos conceptos: respuesta parcial (envuelta) y respuesta de recuperación (rack)
Recordar el mensaje ACK recibido por el remitente TCP durante la fase de recuperación (ACK no redundante) Es ACKx Al recibir ACKx, el mensaje con el número de secuencia (SN) más grande enviado por el terminal TCP es PKTy. Si ACKx no es un mensaje de respuesta a PKTy, el mensaje ACKx se denomina ACK parcial (PACK; abreviatura). Si ACKx resulta ser el mensaje de respuesta de PKTy, entonces este mensaje ACKx se llama ACK de recuperación (RACK para abreviar).
Por ejemplo, comprenda:
Si los paquetes 4, 5 y 6 se pierden, ahora solo se retransmite el 4 y solo se recibe el acuse de recibo del 4. Los siguientes 5 y 6. no están confirmados, lo cual es ACK parcial. Si el ACK recibido es 6, es un ACK de recuperación.
La respuesta de recuperación recibida por el remitente TCP indica que todos los mensajes enviados por el terminal TCP han sido recibidos correctamente por el receptor después de la retransmisión y que la red se ha recuperado de la congestión.
Cuando el remitente de NewReno recibe el primer ACK parcial, no finaliza la recuperación rápida inmediatamente, sino que continúa retransmitiendo paquetes después del ACK parcial hasta que se hayan retransmitido todos los paquetes perdidos. Cuando se recibe un ACK parcial, se reinicia el temporizador de retransmisión. Esto permite al remitente de NewReno corregir el error sin esperar un tiempo de espera cuando se pierde una gran cantidad de paquetes de datos en la red, lo que reduce el impacto de una gran cantidad de pérdidas de paquetes de datos en el efecto de transmisión.
El nuevo Reno puede retransmitir paquetes perdidos cada vez que RTT. Si se pierden m paquetes en la ventana de envío, la fase de recuperación rápida de TCP NewReno durará m RTT.
Los pasos específicos del algoritmo de recuperación rápida mejorado son los siguientes:
La recuperación rápida se basa en el principio de conservación de paquetes, es decir, los paquetes que se pueden transmitir simultáneamente en el Si la red permanece sin cambios y solo los paquetes antiguos salen de la red, se pueden enviar paquetes nuevos a la red. Los ACK duplicados no solo significan pérdida de paquetes, sino que también significan que el paquete enviado abandonó la red y ya está en el búfer del área de recepción, sin ocupar más recursos de la red, por lo que la ventana de congestión aumenta en un tamaño de paquete.
¿Cuáles son los problemas con los algoritmos Reno y NewReno?
Aunque NewReno puede resolver el problema de una gran cantidad de pérdidas de paquetes, NewReno solo puede causar un error de pérdida de paquetes por tiempo RTT.
Para manejar la pérdida de una gran cantidad de paquetes de manera más eficiente, otra solución es informar al remitente cuáles han sido recibidos por el receptor, pero este método debe modificar el mecanismo de transmisión del remitente y el receptor.
En ausencia de un algoritmo SACK, el remitente solo puede elegir dos estrategias de recuperación:
TCP SACK agrega el siguiente contenido basado en TCP Reno:
Cuándo se pierden varios paquetes en la ventana:
Latencia reducida, rendimiento de red mejorado y recuperación más rápida de la congestión.
SACK agrega un campo de opción TCP, que permite al receptor devolver los segmentos de datos recibidos (rango de datos recibidos continuamente) al remitente cuando devuelve ACK repetidos. El intervalo entre segmentos de datos es Datos no recibidos por el receptor. El remitente sabe qué paquetes se han recibido y qué paquetes deben retransmitirse, por lo que el remitente de SACK puede retransmitir varios paquetes dentro de un tiempo RTT.
La longitud de toda la opción TCP no supera los 40 bytes y, en realidad, no supera los 4 conjuntos de valores límite.
Se utiliza un ejemplo de Wirehark para ilustrar el comportamiento SACK del receptor:
En la figura anterior, el número de secuencia de confirmación ACK es 12421, el valor del límite izquierdo de SACK es 13801 y el valor del límite derecho de SACK El valor es 15181. Al definir los valores de estos tres parámetros, básicamente podemos calcular el número de secuencia y la longitud del datagrama eliminado. Del mensaje de datos con SACK que se muestra en la figura anterior, podemos ver que el número de secuencia TCP del mensaje de datos descartado es 12422 y su longitud de datos es 13801-12421 = 1380 b.
Algoritmo de recuperación rápida mejorado;
Materiales de referencia:
Wu, Li. Análisis cuantitativo del rendimiento del mecanismo de control de congestión de TCP. Ingeniería Informática y Aplicaciones. 2008,44(18)
, Feng,,. Modelo de análisis de rendimiento de estado estacionario basado en TCP NewReno. I+D informático. 20648.100000000005
Chen Lin, Shuang Xueqin. Un estudio comparativo de los algoritmos de control de congestión de la red TCP. Revista de la Universidad de Yangtze.
Xu, Evaluación del rendimiento del algoritmo de control de congestión TCP. Universidad de Correos y Telecomunicaciones de Beijing 2005, 3
Liu Yongmin, Nian Xiaohong. Investigación sobre el algoritmo de control de congestión SACK. tecnologías de la información. 2003,9
Jiao Chengbo, Dou Ruiyu, Lan Julong. Análisis de rendimiento y mejora de mecanismos de retransmisión selectiva en redes inalámbricas. Investigación de aplicaciones informáticas. 2007.3
Enfoque de arriba hacia abajo para las redes de computadoras, sexta edición. Prensa de la Industria de Maquinaria.
Texto original:/M0_38068229/article/details/80417503