Regulacja ruchu TCP: Start wolny, AIMD i wizyta sawtooth cwnd

Okno zatłoczenia: przycisk prędkości TCP

TCP wysyła wielokrotne segmenty bez czekania na poszczególne potwierdzenia. Okno zatłoczenia (cwnd) ogranicza, ile bajtów może być w trakcie przesyłania jednocześnie. Przepustowość jest bezpośrednim wynikiem tego: przepustowość ≈ cwnd / RTT. Zbyt wysoka wartość cwnd dla rzeczywistej pojemności sieci powoduje, że bufor zatłoczenia wypełnia się i zaczyna usuwać pakety; zbyt niska wartość cwnd spowoduje niekorzystne wykorzystanie przepustowości. TCP nie ma bezpośredniego sposobu na pomiar dostępnej przepustowości, dlatego klasyczne algorytmy traktują sam fakt utraty pakietów jako sygnał, że cwnd jest zbyt duży.

Start wolny: ekspansywna próba

Nowe połączenie zaczyna się w trybie startu wolnym, gdzie cwnd podwójnie rośnie przy każdym czasie pełnego obrotu — ekspansja, mimo nazwy, wybrana dlatego, że nowe połączenie nie ma żadnych informacji na temat tego, co potrafi obsłużyć ścieżka, i musi szybko wzrosnąć zamiast wolno krawędziować. Gdy cwnd przekroczy pewien próg (lub nastąpi strata danych), TCP przełącza się na tryb unikania zagrożenia kongestyjnego, w którym cwnd rośnie tylko liniowo, dodając około jedno segment do cwnd przy każdym czasie pełnego obrotu — znacznie bardziej ostrożna próba dla jakiejkolwiek pozostającej wolnej pojemności.

AIMD i wizyta sawtooth

Po wejściu w fazę unikania zagłupień, tradycyjne warianty TCP stosują Zwiększanie Addytywne, Mniejszenie Mnożyste (AIMD): zwiększają cwnd o około jedno segmentów na pełny obwód, a w chwili wykrycia straty, znacznie je zmniejszają — Reno halbuje cwnd, podczas gdy starszy Tahoe wraca do jednego segmentu i ponownie uruchamia tryb wolnej zwiększania. Wykreślone na wykresie w czasie, powtarzające się liniowe wzrosty Reno połączone z nagle nastąpiłym halowaniem tworzą typowy kształt sawtooth, co jest charakterystycznym oznakowaniem przepływu TCP ciągle testującego granicę dostępnej pojemności i cofającego się, gdy ją znajdzie.

Slow start:           cwnd(t+RTT) = 2 · cwnd(t)          (until threshold or loss)
Congestion avoidance: cwnd(t+RTT) = cwnd(t) + 1 MSS       (linear probing)
Loss detected (Reno): cwnd → cwnd / 2                      (multiplicative decrease)
Timeout (Tahoe):      cwnd → 1 MSS, restart slow start

Po kontroli opartym na stratach: CUBIC i BBR

Reno i Tahoe traktują każdą stratę pakietu jako sygnał zatkania, co działa źle na współczesnych linkach o wysokiej pradze i opóźnieniu, gdzie pojedyncza strata może bez potrzeby podważyć połączenie przesyłające gigabajty w sekundę. CUBIC, domyślna metoda w systemie Linux od 2006 roku, rosnie funkcją sześcienną od czasu od ostatniej straty, co umożliwia szybsze odbudowanie połączeń długotrwałych (elephant flows). Google BBR podchodzi do tego problemu inaczej, modelując rzeczywistą pradę brzegowej ścieżki i czas przebywania na powrót bezpośrednio zamiast reagować na straty po fakcie — w sieciach o wysokiej iloczynie prady i opóźnienia BBR może dostarczyć 2-10 razy lepszy przepustowość, ponieważ przestaje traktować pełny bufor jako jedyną wartość, do której należy się przyłączyć.

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz TCP Congestion Control i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.