Rozumiem, że implementacja stosu TCP w systemie Windows i Linux jest inna. Windows używa algorytmu kontroli przeciążenia znanego jako TCP Reno, podczas gdy Linux używa Cubic.
Jak porównują 2 protokoły, gdy współistnieją w tej samej sieci? Czy to prawda, że Cubic (Linux) jest bardziej agresywny i może w rezultacie uzyskać większy udział przepustowości?
Odpowiedzi:
Należy pamiętać, że algorytm kontroli przeciążenia wpływa tylko na ruch w górę, a zatem tylko na przepustowość w górę.
To powiedziawszy, Cubic jest bardziej agresywny, szczególnie w przypadku sieci z produktem opóźniającym o dużej przepustowości. Istnieje nawet reguła wbudowana w implementację Linuksa, aby nigdy nie używać mniejszej prędkości wysyłania niż reno w tej samej sytuacji:
Algorytm sześcienny Linux zawiera również kod, który zapewnia, że algorytm sześcienny jest co najmniej tak agresywny jak standardowy TCP
- Leith, Shorten, McCullagh, Eksperymentalna ocena Cubic-TCP
Tak więc, podczas pobierania aktualizacji systemu Windows podczas oglądania filmów z YouTube, ruch w Youtube może zagłuszyć ruch w Microsoft, i nic nie możesz na to poradzić.
Po pierwsze, to, co mówisz, nie jest zgodne z prawdą:
Wszystkie te algorytmy są samodostrajające zgodnie z dostępną przepustowością sieci, opóźnieniem, dostępną pamięcią itp. Mają także wiele parametrów konfiguracyjnych, które umożliwiają ich ręczne dostrojenie.
Tak więc nie można tak naprawdę porównywać jednego z drugim, nie patrząc dokładnie na konkretną topologię sieci, używany sprzęt i oprogramowanie itp. To nie jest tak, że jedno jest lepsze od drugiego lub będzie zużywać większą część dostępnej przepustowości. Prawdą jest, że CUBIC jest mniej agresywny niż BIC, ale w praktyce inne względy są często ważniejsze niż to, który wariant algorytmu przeciążenia TCP jest używany.
O ile nie próbujesz dostroić się do bardzo wąskiego i nietypowego scenariusza sieciowego, wszystkie te algorytmy działają wystarczająco dobrze i uczciwie po wyjęciu z pudełka.