Isso parece uma questão de drive-by por causa da falta "Por quê?" .
Versão resumida: "Não - use CHD"
Alguns dos trabalhos da UCLA com o TCP Westwood foram feitos no FreeBSD 4.4 link
Você pode encontrar a fonte Westwood + em: link
O TCP Westwood foi uma modificação do TCP New Reno. Não funciona bem quando você tem tráfego reverso. Isso levou ao TCP Westwood +, que é implementado no Linux Kernel por volta de 2006. E eu suspeito que isso possa ser a gênese dessa questão: O Linux tem essa performance: Por que o FreeBSD não o tem? Note, entretanto, que CUBIC é o padrão no Linux 2.6.19 para 3.1. No FreeBSD, o padrão é NewReno.
FreeBSD tem uma boa estrutura modular de controle de congestionamento desde 9.0. Por padrão, ele é enviado com 5 implementações diferentes de controle de congestionamento:
- NewReno , CUBIC e HTCP algoritmos TCP CC baseados em perda.
- Vegas , HD e CHD algoritmos TCP CC baseados em atraso.
Você pode ver o que você tem disponível no seu sistema com:
sysctl net.inet.tcp.cc
Veja:
Anúncio:
Site do projeto original:
Você pode ler seu relatório de projeto bastante denso aqui:
E pelo que li eu não me incomodaria (na maioria dos casos) com TCP Westwood + quando você tem CUBIC disponível:
Você não declara por que precisa do TCP Westwood. Se você está tentando otimizar sua rede, eu com certeza começaria com o que você tem na caixa. O TCP é um código crítico e eu não me aventuro fora do sistema operacional, a menos que seja uma pesquisa séria. Se você está fazendo (séria!) Pesquisa - então eu falo com os caras das 5cc.
Se sua preferência pelo TCP Westwood é por causa de links com perdas (como wireless) - eu preferiria ir a rota "CHD" mais moderna. Se você estiver jogando com redes modernas de alta velocidade, você deve se concentrar em CUBIC e HTCP. No mundo real, "Vegas" quase nunca é divertido: ele não coexiste bem em uma rede com pilhas baseadas em "Reno" (o que na maioria das vezes é o caso!).