Sobre o desempenho das implementações TCP do Linux e do Windows

Question

Eu entendo que a implementação da pilha TCP no Windows e no Linux é diferente. O Windows usa um algoritmo de controle de congestionamento conhecido como o TCP Reno enquanto o Linux usa o Cubic.

Como os dois protocolos se comparam quando coexistem na mesma rede? É verdade que o Cubic (Linux) é mais agressivo e pode acabar tendo uma maior quota de banda?

    

Answer 1

Observe que o algoritmo de controle de congestionamento afeta apenas o tráfego de envio e, portanto, apenas a largura de banda de envio.

Dito isto, o Cubic é na verdade mais agressivo, especialmente para redes com um produto de atraso de alta largura de banda. Existe até uma regra embutida na implementação do Linux para nunca usar uma taxa de envio menor que a do reno na mesma situação:

The Linux Cubic algorithm also includes code which ensures that the cubic algorithm is at least as aggressive as standard TCP

-- Leith, Shorten, McCullagh, Experimental evaluation of Cubic-TCP

Assim, ao baixar suas atualizações do Windows enquanto assiste vídeos do YouTube, seu tráfego no YouTube pode prejudicar o tráfego da Microsoft e não há nada que você possa fazer sobre isso.

    

Answer 2

Primeiro, o que você diz não é factualmente correto:

• O Linux até a versão 2.6.18 do kernel usa BIC por padrão.
• O kernel Linux 2.6.19 e posterior usa CUBIC por padrão.
• Os mecanismos de controle de congestionamento TCP do Linux são conectáveis , por exemplo, você pode alterá-los no fily.
• O Windows XP e versões anteriores usam o TCP Reno (ou o New Reno )
O
• Windows Vista e posterior também tem Compound TCP , que é habilitado por padrão no Server 2008 e pode ser habilitado no Vista e o Windows 7, se necessário.

Todos desses algoritmos são auto-sintonizáveis de acordo com a largura de banda de rede disponível, latência, memória disponível, etc. Eles também têm muitos parâmetros de configuração que permitem ajustá-los manualmente.

Assim, você não pode realmente comparar um com o outro, sem olhar para a topologia de rede específica, hardware e software usados, etc. Não é como um é melhor que o outro, ou usará maior parte da largura de banda disponível. É verdade que CUBIC é menos agressivo que o BIC, mas na prática outras considerações são frequentemente mais importantes do que o sabor do algoritmo de congestionamento TCP usado.

A menos que você esteja tentando sintonizar um cenário de rede incomum e de escopo limitado, todos esses algoritmos funcionam suficientemente bem e justamente prontos para uso.