La ubicación de la máquina de estado de control de congestión TCP en el código fuente del kernel de Linux

Equidad

Equidad significa que cuando se produce congestión, cada

fuente (o diferentes conexiones TCP o datagramas UDP establecidos por la misma fuente) Justo *** El capacidad de compartir los mismos recursos de red (como ancho de banda, caché, etc.). Las fuentes del mismo nivel deberían recibir la misma cantidad de recursos de red.

La razón fundamental de la justicia es que la congestión conducirá inevitablemente a la pérdida de paquetes, y la pérdida de paquetes provocará competencia por recursos limitados de la red entre flujos de datos con competencia débil que sufrirán mayores pérdidas.

Por lo tanto, no hay congestión y no hay cuestión de equidad.

El problema de equidad de la capa TCP se manifiesta en dos aspectos:

(1)?

Cuando ocurre la congestión, el TCP orientado a la conexión y el UDP sin conexión responden y maneja las indicaciones de congestión de manera diferente, lo que lleva a un uso injusto de los recursos de la red. Cuando se produce la congestión, los flujos de datos TCP con un mecanismo de respuesta de control de la congestión entrarán en la fase de evitación de la congestión de acuerdo con los pasos de control de la congestión, reduciendo así activamente la cantidad de datos enviados a la red. Sin embargo, para el UDP de datagramas sin conexión, dado que no existe un mecanismo de control de congestión de extremo a extremo, incluso si la red envía indicaciones de congestión (como pérdida de paquetes, recepción de ACK duplicado, etc.), UDP no se comportará como si TCP redujera la cantidad. de datos enviados a la red. Por lo tanto, el flujo de datos TCP que cumple con el control de congestión obtiene cada vez menos recursos de red, mientras que UDP sin control de congestión obtiene cada vez más recursos de red, lo que hace que los recursos de red se distribuyan entre diferentes fuentes.

La asignación injusta de recursos de red a su vez

exacerba la congestión e incluso puede conducir al colapso de la congestión. Por lo tanto, cómo determinar si cada flujo de datos cumple estrictamente con el control de congestión de TCP cuando se produce una congestión y cómo "castigar" el comportamiento que no cumple con el protocolo de control de congestión se ha convertido en un tema candente en la investigación actual sobre control de congestión.

. La forma fundamental de resolver la equidad del control de la congestión en la capa de transporte es utilizar plenamente el mecanismo de control de la congestión de un extremo a otro.

(2) También existen problemas de equidad entre algunas conexiones TCP. Este problema se produce porque algunos TCP utilizan un tamaño de ventana mayor antes de la congestión, o tienen un RTT más pequeño, o los paquetes son más grandes que otros TCP, por lo que también ocupan más ancho de banda.

RTT es injusto

Estrategia de actualización de la ventana de congestión AIMD

También hay algunas deficiencias: la estrategia de incremento de suma enviará al remitente con un retraso de ida y vuelta; (RTT) La ventana de congestión para un flujo de envío aumenta en un tamaño de paquete, por lo que cuando diferentes flujos de datos compiten por el ancho de banda del cuello de botella de la red, el flujo TCP con un RTT más pequeño tiene un tamaño de ventana de congestión de un paquete. Por lo tanto, cuando diferentes flujos de datos compiten por el ancho de banda del cuello de botella de la red, la ventana de congestión de un flujo TCP con un RTT más pequeño aumentará más rápido que un flujo TCP con un RTT más grande, ocupando así más recursos de ancho de banda de la red.

Notas adicionales

La calidad de la línea entre China y Estados Unidos no es muy buena, con RTT largos y pérdida frecuente de paquetes. El protocolo TCP tiene éxito y fracaso; TCP se diseñó originalmente para resolver el problema de la transmisión confiable en líneas no confiables, es decir, el protocolo HTTP usa tcp en la capa de transporte, por lo que la velocidad de descarga de la página web depende de la velocidad de tcp. . Entonces, la velocidad de descarga de una página web depende de la velocidad de descarga del subproceso único TCP (porque la página web se descarga en un solo subproceso).

La razón principal por la que la pérdida de paquetes provoca una disminución significativa en la velocidad de transmisión de TCP es el mecanismo de retransmisión de pérdida de paquetes controlado por el algoritmo de control de congestión de TCP.

El kernel de Linux proporciona muchos algoritmos de control de congestión de TCP. Los algoritmos cargados en el kernel se pueden ver en el parámetro del kernel net.ipv4.tcp_available_congestion_control.

Vegas

En 1994,

Brakmo propuso un nuevo mecanismo de control de congestión TCP?

Vegas, desde una perspectiva diferente para manejar la congestión control. Como se puede ver en la sección anterior, el control de congestión de TCP se basa en la pérdida de paquetes. Una vez que se pierde un paquete, se ajustará la ventana de congestión, pero la pérdida de paquetes no necesariamente se debe a que la red entre en un estado de congestión. El valor RTT está estrechamente relacionado con el funcionamiento de la red, ¿TCP?

Vegas utiliza cambios en el valor RTT para determinar si la red está congestionada, ajustando así la ventana de control de congestión. Si descubre que el RTT está aumentando, Vegas pensará que la red está congestionada, por lo que comenzará a reducir la ventana de congestión.

Después de encenderlo, si el RTT se vuelve más pequeño, Vegas pensará que la congestión de la red se alivie gradualmente, por lo que aumentará nuevamente la ventana de congestión. Debido a que Vegas determina el ancho de banda disponible de la red no por la pérdida de paquetes sino por los cambios de RTT, puede detectar con mayor precisión el ancho de banda disponible de la red, mejorando así la eficiencia. Sin embargo, Vegas tiene un defecto, que se puede decir que es un defecto fatal, que eventualmente afectará el uso a gran escala de TCP en Internet. El problema es que los flujos de datos que utilizan TCP Vegas no son competitivos en términos de ancho de banda en comparación con los flujos de datos que no utilizan TCP Vegas.

Esto se debe a que mientras los enrutadores de la red almacenen los datos en el buffer, los datos se almacenarán en el buffer. el RTT se hará más grande Si el búfer no se desborda, no habrá congestión. Sin embargo, el almacenamiento en búfer de los datos provocará retrasos en el procesamiento, lo que hará que el RTT sea más grande, especialmente en una red con un ancho de banda pequeño, una vez que los datos comiencen a aumentar. se transmitirá, el RTT aumentará dramáticamente, lo cual es especialmente obvio en las redes inalámbricas. En este caso, TCP

Vegas reducirá su propia ventana de congestión, pero mientras no se pierdan paquetes, como se mencionó anteriormente, el TCP estándar no reducirá su propia ventana, por lo que los dos se vuelven injustos. luego el ciclo continúa, TCPLa eficiencia de Vegas es muy baja. De hecho, si todo TCP utilizara el control de congestión de Vegas, la equidad entre los flujos sería mejor y la competitividad no sería un problema con el algoritmo de Vegas en sí.

Entorno aplicable: es difícil de aplicar a gran escala en Internet (baja competencia en ancho de banda)

2. Reno

Reno es el más utilizado. y algoritmo relativamente maduro. Los mecanismos de inicio lento, evitación de congestión y retransmisión rápida y recuperación rápida incluidos en este algoritmo son la base de muchos algoritmos existentes. No es difícil ver en el mecanismo operativo de Reno que para mantener el equilibrio dinámico, debe ocurrir periódicamente una cierta cantidad de pérdida, junto con el mecanismo AIMD: reducción rápida, crecimiento lento, especialmente en un entorno de ventana grande, debido a la pérdida de datos Tomará mucho tiempo recuperarse de la reducción de la ventana causada por el informe, por lo que la utilización del ancho de banda no puede ser muy alta y, a medida que el ancho de banda del enlace de la red continúa aumentando, esta deficiencia será cada vez mayor. obvio. A medida que el ancho de banda del enlace de red siga aumentando, este inconveniente será cada vez más evidente. En términos de equidad, según las estadísticas, la equidad de Reno todavía es muy reconocida e idealmente puede mantener el principio de equidad en varias redes.

El algoritmo de Reynolds se utiliza ampliamente debido a su simplicidad, eficacia y robustez y se ha convertido en un algoritmo convencional.

Pero no puede manejar eficazmente la situación de múltiples pérdidas de paquetes en la misma ventana de datos. El nuevo algoritmo de Reynolds resuelve este problema.

Protocolo basado en retroalimentación de pérdida de paquetes

En los últimos años, con la popularidad de la red de productos de alto ancho de banda y retardo (red de productos de alto ancho de banda y retardo), para mejorar el ancho de banda TCP Utilización, se han desarrollado varios protocolos TCP nuevos basados ​​en una retroalimentación mejorada de pérdida de paquetes, incluidos HSTCP, STCP, BIC-TCP, CUBIC y H-TCP.

En general, un protocolo basado en retroalimentación de pérdida de paquetes es un mecanismo pasivo de control de congestión que toma decisiones de congestión basadas en eventos de pérdida de paquetes en la red. Incluso si la carga de la red es alta, el protocolo no reducirá activamente la velocidad de envío mientras no se produzca una pérdida de paquetes por congestión. Este protocolo maximiza el uso del ancho de banda restante en la red y mejora el rendimiento. Sin embargo, debido a la agresividad del protocolo de retroalimentación de pérdida de paquetes cuando la red está cerca de la saturación, por un lado, la utilización del ancho de banda de la red ha mejorado enormemente, pero por otro lado, para el protocolo de control de congestión basado en paquetes; retroalimentación de pérdida, la utilización de la red El gran aumento en la tasa significa que la próxima congestión y pérdida de paquetes no están muy lejos. Por lo tanto, si bien estos protocolos mejoran la utilización del ancho de banda de la red, también aumentan indirectamente la tasa de pérdida de paquetes de la red, lo que lleva a un aumento. en la inquietud de toda la red.

Amigable

BIC-TCP,

HSTCP, STCP y otros protocolos basados ​​en retroalimentación de pérdida de paquetes mejoran en gran medida su propio rendimiento, pero también afectan seriamente el rendimiento. tasa de tráfico de Reno. La razón principal por la que los protocolos basados ​​​​en retroalimentación de pérdida de paquetes son tan hostiles para TCP es que estos algoritmos de protocolo adoptan un mecanismo radical de administración de ventanas de congestión. Por lo general, creen que mientras no se pierdan paquetes, debe haber un exceso de ancho de banda en la red. por lo que su tasa de envío seguirá aumentando.

Desde una perspectiva macro del tiempo, la velocidad de transmisión muestra una tendencia cóncava. Cuanto más cerca del pico del ancho de banda de la red, más rápido aumenta la velocidad de transmisión. Esto no solo causará mucha congestión y pérdida de paquetes, sino que también anexará maliciosamente los recursos de ancho de banda de otros flujos de datos en la red, lo que resultará en una disminución en la equidad de toda la red. .

3.HSTCP (TCP de alta velocidad)

HSTCP (Protocolo de control de transmisión de alta velocidad) es un nuevo algoritmo de control de congestión basado en la red de alta velocidad AIMD (aumento aditivo y disminución multiplicativa), que puede mejorar el rendimiento de la red de manera más eficiente en redes de alta velocidad y alta latencia. Modifica los parámetros de aumento y disminución del algoritmo estándar para evitar la congestión de TCP para hacer que la ventana aumente rápidamente y disminuya lentamente, manteniendo la ventana lo suficientemente grande como para utilizar completamente el ancho de banda, logrando así un mayor rendimiento que TCP en redes de alta velocidad.

Reno mucho ancho de banda, pero tiene un problema muy grave de RTT injusto. La llamada injusticia significa que múltiples tráfico *** comparten el mismo cuello de botella de la red y ocupan los mismos recursos de la red.

El remitente TCP ajusta dinámicamente la función incremental de la ventana de congestión HSTCP en función de la tasa de pérdida de paquetes esperada de la red.

Cómo crece la ventana durante la prevención de la congestión: cwnd = cwnd a(cwnd) / cwnd

Cómo disminuye la ventana después de la pérdida de paquetes: cwnd = (1-b( cwnd))* cwnd

Entre ellas, a(cwnd) y

b(cwnd) son dos funciones en TCP estándar, a(cwnd)=1 y b(cwnd)=0. 5. Para lograr compatibilidad con TCP, en situaciones de ventana baja, es decir, en entornos de red que no son BDP, HSTCP adopta los mismos a y b que TCP estándar para garantizar la compatibilidad entre los dos. Cuando la ventana es mayor (umbral LowWindow=38), se adoptarán nuevos a

y b para cumplir con los requisitos de alto rendimiento. Consulte el documento RFC3649 para obtener más detalles.

4. Westwood

En redes inalámbricas, basándose en una gran cantidad de investigaciones, se descubrió que tcpwestwood es un algoritmo ideal. Su idea principal es detectar continuamente la tasa de llegada de acuse de recibo. del extremo emisor realice una estimación del ancho de banda y utilice la estimación del ancho de banda para ajustar la ventana de congestión y el umbral de inicio lento cuando se produce la congestión, utilizando el mecanismo de control de congestión aiad (aumento acumulativo y disminución adaptativa). No solo mejora el rendimiento de las redes inalámbricas, sino que también tiene buena equidad e interoperabilidad con las redes actuales. El problema es que no distingue bien entre pérdida por congestión y pérdida de paquetes inalámbricos durante la transmisión, lo que genera llamadas frecuentes al mecanismo de congestión.

5.H-TCP

El algoritmo con mejor rendimiento general en redes de alto rendimiento es: H-TCP, pero tiene problemas como rtt injusto y ancho de banda bajo poco amigable.

6.BIC-TCP

Desventajas de BIC-TCP: Primero, su preferencia es más fuerte. La función de crecimiento de BIC-TCP es más efectiva cuando el ancho de banda del enlace es pequeño y el ancho de banda del enlace es pequeño. El retraso es corto en este caso, es más preventivo que el TCP estándar, lo que equivale a reiniciar un algoritmo de inicio lento en la fase de detección. Una vez que TCP se estabiliza, la ventana siempre ha crecido linealmente y no habrá un proceso de inicio lento. En segundo lugar, la etapa de control de ventana de BIC-TCP se divide en aumento de búsqueda binaria, detección máxima y luego distinción entre Smax y Smin, lo que aumenta la dificultad de la implementación del algoritmo y también la dificultad del análisis del modelo de rendimiento del protocolo. En redes con bajo RTT y entornos de baja velocidad, BIC puede ser demasiado "agresivo", por lo que se desarrolló una versión mejorada de BIC, CUBIC, que fue el algoritmo predeterminado en Linux hasta que se adoptó CUBIC.

7.CUBIC

CUBIC está diseñado para simplificar el algoritmo de ajuste de ventana de BIC-TCP.

El ajuste de ventana de BIC-TCP tendrá un aumento (. Lo cóncavo y convexo aquí es la curva de crecimiento de la función matemática cóncava/convexa, mientras que CUBIC usa una función cúbica (es decir, función cúbica).

Función cubo), la curva de la función cúbica también tiene una parte cóncava y convexa, su forma es muy similar a la gráfica de BIC-TCP, por lo que esta parte reemplaza la curva de crecimiento de BIC-TCP.

Además, el punto más crítico de CUBIC es que su función de crecimiento de ventana solo depende del valor del intervalo de tiempo entre dos eventos de congestión consecutivos, por lo que el crecimiento de ventana es completamente independiente del retardo RTT de la red. y el HSTCP introducido anteriormente tiene un grave problema injusto de RTT. La función independiente de RTT de CUBIC permite a CUBIC mantener un buen RTT entre conexiones TCP con múltiples enlaces de cuello de botella disfrutados.

CUBIC es el protocolo de control de congestión para TCP (Protocolo de control de transmisión) y es el algoritmo TCP predeterminado actual en Linux.

Este protocolo modifica la función de crecimiento de ventana lineal

del estándar TCP existente en una función cúbica.

Este protocolo modifica la función de crecimiento de ventana lineal del estándar TCP existente

a una función cúbica para mejorar la escalabilidad de TCP en redes rápidas y de larga distancia. Además, permite una asignación más justa del ancho de banda entre flujos de datos con diferentes RTT (tiempo de ida y vuelta) al hacer que el crecimiento de la ventana sea independiente del RTT; por lo tanto, estos flujos de datos en estado estable aumentarán su ventana de congestión, mientras que CUBIC

aumentará activamente el tamaño de la ventana cuando la ventana esté lejos del

punto de saturación, y aumentará el tamaño de la ventana cuando la ventana esté cerca del

punto de saturación. despacio. Esta característica hace que

CUBIC sea altamente escalable sin utilizar ancho de banda de red ni productos de latencia.

8. STCP

STCP, TCP escalable.

El algoritmo STCP fue propuesto por Tom Kelly en 2003. Ajusta la ventana de envío modificando la ventana TCP. aumentar y disminuir el tamaño para adaptarse a entornos de red de alta velocidad. Este algoritmo tiene una alta utilización y estabilidad del enlace, pero el aumento en la ventana de este mecanismo es inversamente proporcional al RTT, y existe un fenómeno de RTT injusto. También es diferente del flujo TCP tradicional *Igual que el almacenamiento. consume demasiado ancho de banda y su compatibilidad con TCP también es deficiente.