Sobre el rendimiento de las implementaciones TCP de Linux y Windows

Entiendo que la implementación de la pila TCP en Windows y Linux es diferente. Windows usa un algoritmo de control de congestión conocido como TCP Reno, mientras que Linux usa Cubic.

¿Cómo se comparan los 2 protocolos cuando coexisten en la misma red? ¿Es cierto decir que Cubic (Linux) es más agresivo y podría terminar obteniendo una mayor proporción de ancho de banda?

Tenga en cuenta que el algoritmo de control de congestión solo afecta el tráfico ascendente y, por lo tanto, solo el ancho de banda ascendente.

Dicho esto, Cubic en realidad es más agresivo, especialmente para redes con un producto de alto retardo de ancho de banda. Incluso hay una regla incorporada en la implementación de Linux para nunca usar una tasa de envío menor que la que usaría Reno en la misma situación:

El algoritmo cúbico de Linux también incluye código que garantiza que el algoritmo cúbico sea al menos tan agresivo como el TCP estándar

- Leith, Shorten, McCullagh, Evaluación experimental de Cubic-TCP

Por lo tanto, cuando descargue sus actualizaciones de Windows mientras mira videos de Youtube, su tráfico de Youtube podría privar a su tráfico de microsoft, y no hay nada que pueda hacer al respecto.

Primero, lo que dices no es correcto de hecho:

• Linux hasta el kernel versión 2.6.18 usa BIC por defecto.
• El kernel de Linux 2.6.19 y posterior usa CUBIC por defecto.
• Los mecanismos de control de congestión TCP de Linux son conectables , por ejemplo, puede cambiarlos en la filia.
• Windows XP y versiones anteriores utilizan TCP Reno (o New Reno )
• Windows Vista y versiones posteriores también tienen Compound TCP , que está habilitado de manera predeterminada en Server 2008 y puede habilitarse en Vista y Windows 7 si es necesario.

Todos estos algoritmos se auto-ajustan de acuerdo con el ancho de banda de red disponible, la latencia, la memoria disponible, etc. También tienen muchos parámetros de configuración que le permiten ajustarlos manualmente.

Por lo tanto, no se puede comparar realmente uno con el otro, sin mirar la topología de red específica exacta, el hardware y el software utilizados, etc. No es que uno sea mejor que el otro, o se utilizará una mayor parte del ancho de banda disponible. Es cierto que CUBIC es menos agresivo que BIC, pero en la práctica otras consideraciones son a menudo más importantes que el tipo de algoritmo de congestión TCP utilizado.

A menos que esté tratando de sintonizar un escenario de red inusual y de alcance muy estrecho, todos estos algoritmos funcionan lo suficientemente bien y de manera inmediata.