¿El inicio lento en TCP se refiere a una ventana de inicio pequeña o a un crecimiento lento de la ventana?
El principio fundamental del control de congestión TCP se basa en la ventana de congestión (cwnd). Antes de esto, también comentamos que TCP también tiene una ventana de recepción (rwnd), que se utiliza para notificaciones entre pares para el control de flujo. El tamaño de la ventana representa el segmento más grande de datos que se pueden enviar pero aún no recibir un ACK. Obviamente, cuanto mayor sea la ventana, más rápida será la velocidad de transmisión de datos, pero también es más probable que provoque congestión en la red. Si el valor de la ventana es 1, se reduce a un protocolo de parada y espera. Cada vez que envía un dato, debe esperar a que la otra parte lo confirme antes de enviar el segundo paquete de datos. Obviamente, la eficiencia de la transmisión de datos es menor. El algoritmo de control de congestión de TCP consiste en equilibrar los dos y seleccionar el mejor valor de cwnd para maximizar el rendimiento de la red sin causar congestión.
Debido a que es necesario considerar el control de congestión y el control de flujo, la ventana de transmisión real de TCP = min (rwnd, cwnd). Sin embargo, rwnd lo determina el par y el entorno de red no tiene ningún impacto en él. Por lo tanto, generalmente no consideramos el valor de rwnd al considerar la congestión. Por el momento, solo discutiremos cómo determinar el valor de cwnd. . En cuanto a la unidad de cwnd, está en bytes en TCP. Suponemos que TCP envía datos de acuerdo con el tamaño de MSS para cada transmisión, entonces podemos entender que cwnd se expresa en unidades según la cantidad de paquetes, por lo que a veces decimos que cwnd aumenta en 1, lo que significa que el número de bytes aumenta en 1. MSS.
Inicio lento: el TCP inicial enviará una gran cantidad de paquetes de datos a la red después de que la conexión se establezca correctamente, lo que fácilmente puede provocar el agotamiento del espacio de caché del enrutador en la red, provocando así congestión. Por lo tanto, una conexión recién establecida no puede enviar una gran cantidad de paquetes de datos al principio. Solo puede aumentar gradualmente la cantidad de datos enviados cada vez de acuerdo con las condiciones de la red para evitar el fenómeno anterior. Específicamente, cuando se establece una nueva conexión, cwnd se inicializa al tamaño de 1 segmento de mensaje máximo (MSS) y el remitente comienza a enviar datos de acuerdo con el tamaño de la ventana de congestión. Siempre que se reconoce un segmento de mensaje, cwnd se incrementa en 1 milisegundo. De esta forma, el valor de cwnd aumenta exponencialmente con el tiempo de ida y vuelta (RTT) de la red. De hecho, la velocidad de inicio lenta no es lenta en absoluto, pero el punto de partida es relativamente bajo. Simplemente podemos calcular:
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 w, entonces el ancho de banda se puede ocupar por completo después de RTT*log2W.
Evitar la congestión: como se puede ver desde el comienzo lento, cwnd puede crecer rápidamente para maximizar el uso de los recursos de ancho de banda de la red, pero cwnd no puede crecer así indefinidamente y debe requerir algunas restricciones. TCP utiliza una variable llamada umbral de inicio lento (ssthresh). Cuando cwnd excede este valor, el proceso de inicio lento finaliza y se ingresa a la fase de evitación de congestión. Para la mayoría de las implementaciones de TCP, el valor de ssthresh es 65536 (también en bytes). La idea principal para evitar la congestión es el aumento aditivo, es decir, el valor de cwnd ya no aumenta exponencialmente, sino que comienza a aumentar de forma aditiva. En este momento, cuando se confirman 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 RTT para evitar la congestión de la red causada por un crecimiento excesivo, y aumenta lentamente y se ajusta al máximo. Valor de la red.
Los dos mecanismos discutidos anteriormente son comportamientos cuando no se detecta congestión. Entonces, ¿cómo ajustar cwnd cuando se detecta congestión?
Primero, echemos un vistazo a cómo TCP determina que la red ha entrado en un estado de congestión. La razón principal por la que TCP cree que la red está congestionada es porque retransmite un segmento. Como se mencionó anteriormente, TCP tiene un temporizador para cada segmento de mensaje, llamado temporizador de retransmisión (RTO).
Cuando se agota el tiempo de espera del RTO y no se reconocen los datos, TCP retransmitirá el segmento del mensaje. Cuando se agota el tiempo de espera, es probable que se produzca congestión. Es posible que un segmento de mensaje se pierda en algún lugar de la red y que los segmentos posteriores no tengan ningún mensaje. En este caso, la respuesta de TCP es "fuerte":
1. Reduzca ssthresh a la mitad del valor de cwnd.
2.Restablezca cwnd a 1.
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, la suma aumenta y la multiplicación disminuye. Se puede ver que este principio de TCP puede garantizar mejor la equidad entre los flujos, porque una vez que se pierde un paquete, puede retroceder inmediatamente a la mitad, 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á: recibe tres acuses de recibo idénticos. Cuando TCP recibe un paquete que llega desordenado, envía inmediatamente un ACK. TCP utiliza tres acuses de recibo idénticos para determinar la pérdida de paquetes. En este momento, se realiza una retransmisión rápida. Las funciones de retransmisión rápida son las siguientes:
1. Establezca ssthresh en la mitad de cwnd.
2. Establezca cwnd en el valor de ssthresh (algunas implementaciones son ssthresh+3).
3. Vuelva a entrar en la fase de evitación de congestión.
Más tarde, después del algoritmo de "retransmisión rápida" mencionado anteriormente, se agregó un algoritmo de "recuperación rápida". Cuando se reciben tres acuses de recibo duplicados, TCP finalmente ingresa 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 recuperación rápida es el principio de "conservación de paquetes", es decir, la cantidad de paquetes existentes en la red al mismo tiempo permanece sin cambios. Sólo cuando los paquetes "antiguos" abandonan la red, pueden aparecer paquetes "nuevos". ser enviado a la red. Si el remitente recibe un ACK duplicado, según el mecanismo TCP ACK, significa que un paquete ha abandonado la red, por lo que cwnd aumenta en 1. Si se puede seguir estrictamente este principio, rara vez se producirá congestión en la red. De hecho, el propósito del control de la congestión es corregir violaciones de este principio.
Específicamente, los pasos principales para una recuperación rápida son:
1 Cuando se reciben tres confirmaciones duplicadas, establezca ssthresh en la mitad de cwnd y configure cwnd para aumentar el valor de ssthresh en. 3 y reenviar los segmentos de mensajes perdidos. La razón para agregar 3 es que se recibieron tres acuses de recibo duplicados, lo que indica que tres paquetes "antiguos" abandonaron la red.
2. Cuando se recibe un ACK duplicado, la ventana de congestión aumentará en 1.
3. Al recibir el ACK del nuevo paquete, establezca cwnd en el valor de ssthresh en el primer paso. La razón es que el ACK confirma los nuevos datos, lo que indica que se han recibido todos los datos del ACK repetido, que el proceso de recuperación ha finalizado y que puede volver al estado anterior a la recuperación, es decir, ingresar nuevamente al estado para evitar la congestión.
El algoritmo de retransmisión rápida apareció por primera vez en Tahoe versión 4.3BSD, y la recuperación rápida apareció por primera vez en Reno versión 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 tiene como objetivo la retransmisión de un paquete. Sin embargo, en la práctica, los tiempos de espera de retransmisión pueden dar lugar a retransmisiones de muchos paquetes, por lo que surgen problemas cuando se pierden varios paquetes de la ventana de datos y se activan los algoritmos de retransmisión rápida y recuperación rápida. Entonces apareció NewReno, con ligeras modificaciones basadas en la rápida recuperación de Reno, que puede recuperar múltiples paquetes perdidos en una sola ventana. Específicamente, Reno sale del estado de recuperación rápida cuando recibe un ACK de datos nuevos, mientras que NewReno solo saldrá del estado de recuperación rápida después de recibir confirmaciones de todos los paquetes de datos dentro de la ventana, mejorando así aún más el rendimiento.
SACK es para cambiar el mecanismo de reconocimiento de TCP. Al principio, TCP solo confirma los datos recibidos continuamente, mientras que SACK le informará a la otra parte toda la información fuera de orden, lo que reducirá la ceguera de la retransmisión de datos del remitente. Por ejemplo, si se reciben datos con los números de secuencia 1, 2, 3, 5 y 7, el ACK ordinario solo confirmará el número de secuencia 4, y SACK notificará al par la información de recepción actual de 5 y 7 en la opción SACK. mejorando así el rendimiento.
Cuando se usa SACK, no se puede usar el algoritmo NewReno, porque la información transportada por el propio SACK permite al remitente tener suficiente información para saber qué paquetes deben retransmitirse y qué paquetes no.
También puede hacer referencia a y;