La ventana de congestión TCP continúa reduciéndose, ¿cuál de las siguientes situaciones es más probable que ocurra?
Inicio ---> cwnd = 1
Después de 1 RTT ---> cwnd = 2*1= 2
Después de 2 RTT ---> cwnd = 2*2= 4
Después de 3 RTT ---> cwnd = 4*2= 8
Si el ancho de banda es demasiado bajo, lento El comienzo no es un comienzo lento. p>
Si el ancho de banda es W, el ancho de banda se ocupa después del tiempo RTT*log2W.
Evitar la congestión: se puede ver desde el comienzo lento que cwnd puede crecer rápidamente para maximizar el uso de los recursos de ancho de banda de la red, pero cwnd no puede crecer ilimitadamente de esta manera y debe requerir ciertas restricciones. TCP utiliza una variable llamada umbral de inicio lento (ssthresh). Cuando cwnd excede este valor, el proceso de inicio lento finaliza y entra en la fase de evitación de congestión. En la mayoría de las implementaciones de TCP, el valor de ssthresh es 65536 (nuevamente en bytes). La idea principal para evitar la congestión es aumentar el valor de cwnd de manera aditiva, es decir, el valor de cwnd ya no aumenta exponencialmente, sino que comienza a aumentar de manera aditiva. En este momento, cuando se reconocen todos los segmentos del mensaje en la ventana, el tamaño de cwnd aumenta en 1 y el valor de cwnd comienza a aumentar linealmente con el RTT. Esto puede evitar la congestión de la red causada por un crecimiento excesivo y aumentar y ajustar lentamente. a la red.
Los dos mecanismos discutidos anteriormente operan cuando no se detecta congestión, entonces, ¿cómo se debe ajustar cwnd cuando se detecta congestión?
Primero, veamos cómo TCP determina que la red está congestionada. La razón principal por la que TCP cree que la red está congestionada es que retransmite un segmento de mensaje. Como se mencionó anteriormente, TCP tiene un temporizador para cada segmento de mensaje, llamado temporizador de retransmisión (RTO). Cuando el RTO se agota y no se recibe confirmación de datos, TCP retransmitirá el segmento de mensaje. La congestión es muy alta. Es posible que un segmento de mensaje se pierda en algún lugar de la red y los segmentos de mensajes posteriores no tengan mensajes. En este caso, la respuesta de TCP es relativamente "fuerte". En este caso, TCP realizará la siguiente reacción "fuerte":
1. Reducir ssthresh a la mitad del valor de cwnd
2 Restablecer cwnd a 1
p><. p>3. Vuelva a ingresar al proceso de inicio lento.En general, el principio de cambio de ventana de control de congestión de TCP es el principio AIMD, es decir, aumento aditivo y disminución multiplicativa. Se puede ver que este principio de TCP puede garantizar mejor la equidad entre los flujos, porque una vez que se produce la pérdida de paquetes, se reducirá a la mitad y se retirará inmediatamente, dejando suficiente espacio para otros flujos recién creados, garantizando así la equidad general.
De hecho, existe otra situación en la que TCP retransmitirá: es decir, se reciben tres ACK idénticos.
TCP enviará inmediatamente un ACK después de recibir el paquete de datos que llega caótico. TCP utiliza estos tres mismos ACK para determinar la pérdida del paquete de datos. En este momento, se deben hacer las siguientes cosas para una retransmisión rápida:
1. Establezca ssthresh en la mitad de cwnd
2. Luego establezca cwnd en el valor de ssthresh (algunas implementaciones son ssthresh+3)
3. Fase de evitación de la congestión.
El algoritmo posterior de "Recuperación rápida" se agregó después del algoritmo de "Retransmisión rápida" mencionado anteriormente. Cuando se reciben tres ACK duplicados, TCP eventualmente ingresará a la fase de recuperación rápida en lugar de a la fase de evitación de congestión. Los algoritmos de retransmisión rápida y recuperación rápida se utilizan a menudo juntos. La idea de una recuperación rápida es el principio de "conservación de paquetes", es decir, el número de paquetes de datos en la red al mismo tiempo es constante. Sólo cuando el paquete de datos "antiguo" sale de la red, se convierte en un "nuevo". El paquete de datos se puede enviar a la red. Si "el antiguo" cuando el paquete sale de la red, si el remitente recibe un ACK duplicado, entonces el mecanismo TCP ACK indica que un paquete ha abandonado la red y cwnd se incrementará en 1. Si Este principio se sigue estrictamente, rara vez ocurre en la congestión de la red; de hecho, el propósito del control de la congestión es corregir el comportamiento que viola este principio.
Específicamente, los pasos principales para una recuperación rápida son: <. /p>
1. Cuando se produce un ACK duplicado, establezca ssthresh en la mitad del valor de cwnd, establezca cwnd en el valor de ssthresh más 3 y luego retransmita el segmento faltante. La razón por la que esto es 3 es porque hay tres duplicados. Los ACK indican que hay tres paquetes "antiguos" "Mensaje. Antiguo" que salieron de la red.
2. Cuando se reciba otro ACK duplicado, la ventana de congestión aumentará en 1.
3. Cuando se recibe un ACK para un nuevo paquete, establezca cwnd en el valor ssthresh en el primer paso. La razón de esto es que este ACK reconoce los nuevos datos, lo que indica que se han recibido todos los datos en el momento del ACK duplicado y que el proceso de recuperación está completo y puede volver al estado previo a la recuperación, es decir, ingresar nuevamente el estado de evitación de congestión.
El algoritmo de retransmisión rápida apareció por primera vez en la versión Tahoe de 4.3BSD, y la recuperación rápida apareció por primera vez en la versión Reno de 4.3BSD, también conocida como la versión Reno del algoritmo de control de congestión TCP.
Se puede ver que el algoritmo de retransmisión rápida de Reno está diseñado para retransmitir un solo paquete de datos, pero en aplicaciones reales, el tiempo de espera de retransmisión provocará la retransmisión de muchos paquetes de datos, por lo que cuando hay una ventana de datos Surgen problemas cuando se envían varios paquetes. se pierden y se activan algoritmos de retransmisión rápida y recuperación rápida. Así surgió NewReno, una ligera modificación de Reno Fast Recovery que puede recuperar múltiples pérdidas de paquetes dentro de una ventana. Específicamente, Reno saldrá del estado de recuperación rápida después de recibir un ACK para un nuevo paquete, mientras que NewReno solo saldrá del estado de recuperación rápida después de recibir un ACK para todos los paquetes en la ventana, lo que mejora aún más el rendimiento.
Lo que SACK cambia es el mecanismo de reconocimiento de TCP. El TCP original solo confirma que los datos se han recibido continuamente. SACK le informará a la otra parte caracteres confusos y otra información, reduciendo así la ceguera del remitente de datos. retransmisión. Por ejemplo, si se reciben todos los datos con los números de secuencia 1, 2, 3, 5 y 7, entonces el ACK ordinario solo confirmará el número de secuencia 4, y SACK informará al otro extremo de los 5 y 7 recibidos actualmente en la opción SACK. Para mejorar el rendimiento, no es necesario utilizar el algoritmo NewReno cuando se utiliza SACK, porque la información transportada por el propio SACK permite al remitente tener suficiente información para saber qué paquetes de datos deben retransmitirse y cuáles no.