TCP celowo zwalnia, gdy uzna, że sieć jest przeciążona
Szybkie łącze nie daje nadawcy prawa do wysyłania danych tak szybko, jak tylko potrafi. TCP utrzymuje okno przeciążenia — limit ilości danych wysłanych bez potwierdzenia — i zmienia je na podstawie sygnałów z sieci. RFC 5681 opisuje slow start, congestion avoidance, fast retransmit i fast recovery. Gdy zachowanie połączenia sugeruje przeciążenie, nadawca ogranicza tempo, nawet jeśli lokalna karta sieciowa mogłaby pompować dane znacznie szybciej. Ten pozornie paradoksalny hamulec jest jednym z mechanizmów pozwalających milionom niezależnych połączeń dzielić wspólne wąskie gardła bez ciągłego wzajemnego zagłuszania się.
Wąskie gardło może być daleko od ciebie
Komputer może mieć kartę 1 Gb/s, serwer jeszcze szybszą, a po drodze jeden router lub łącze o znacznie mniejszej dostępnej przepustowości. Jeśli wiele nadawców spróbuje jednocześnie wypełnić takie miejsce bez ograniczeń, kolejki rosną, a po ich przepełnieniu pakiety zaczynają ginąć. Problem nie wynika z szybkości końcówek, lecz z dzielenia ograniczonego zasobu pośrodku.
Okno przeciążenia jest hamulcem nadawcy
RFC 5681 definiuje congestion window, czyli limit po stronie nadawcy ograniczający ilość danych pozostających w locie. Rzeczywista wielkość wysyłki zależy zarówno od możliwości odbiorcy, jak i od tego okna. Nadawca nie potrzebuje centralnego kontrolera Internetu; obserwuje potwierdzenia i zdarzenia wskazujące na straty, a następnie dostosowuje własne zachowanie.
Slow start nie znaczy „zawsze wolno”
Nazwa bywa myląca. Slow start służy do stopniowego odkrywania dostępnej przepustowości: TCP zaczyna ostrożniej i zwiększa ilość danych w locie wraz z potwierdzeniami. Chodzi o uniknięcie sytuacji, w której nowe połączenie natychmiast zalewa nieznane wąskie gardło ogromnym strumieniem. W pewnym momencie algorytm przechodzi do spokojniejszego wzrostu charakterystycznego dla congestion avoidance.
Strata może być sygnałem, żeby odpuścić
W klasycznych mechanizmach TCP utrata pakietu jest traktowana jako ważny sygnał przeciążenia. Po wykryciu strat nadawca ogranicza okno i ostrożniej zwiększa je ponownie. To może wyglądać dziwnie: przecież właśnie zginęły dane, więc intuicja podpowiada „wysyłaj więcej”. Gdy jednak przyczyną jest przepełniona kolejka, dodatkowe pakiety tylko pogorszyłyby problem.
Reguły chronią wspólną sieć
RFC 5681 zawiera wymóg, by implementacja nie była bardziej agresywna niż określone algorytmy pozwalają. Powód jest społeczny w technicznym sensie: wiele połączeń konkuruje o te same zasoby. Nadawca ignorujący oznaki przeciążenia mógłby zagarnąć nieproporcjonalną część przepustowości i zwiększyć straty wszystkim pozostałym.
Szybkość Internetu jest negocjacją z rzeczywistością
Przepustowość aplikacji nie wynika wyłącznie z abonamentu czy prędkości procesora. Zależy od RTT, strat, możliwości odbiorcy, algorytmu kontroli przeciążenia i chwilowej konkurencji na trasie. TCP nie zna pełnej topologii, a mimo to na podstawie lokalnych obserwacji stale reguluje tempo. To rozproszony mechanizm stabilizacji wykonujący się jednocześnie w ogromnej liczbie hostów.
Kontrola przeciążenia nie zna przyczyny z absolutną pewnością
Klasyczne TCP w dużej mierze wnioskuje o stanie sieci z tego, co obserwuje na końcu połączenia. Utrata może wynikać z przepełnienia kolejki, ale w niektórych mediach może mieć też inne przyczyny. Mimo tej niepełnej wiedzy algorytm musi zachowywać się ostrożnie wobec wspólnej sieci. RFC 5681 definiuje reguły wzrostu i redukcji okna tak, by połączenie reagowało na oznaki przeciążenia zamiast zakładać, że każda dostępna chwilowo przepustowość należy do niego. Nowsze rozwiązania mogą wykorzystywać dodatkowe sygnały, np. ECN, ale fundamentalny problem pozostaje: nadawca nie widzi wszystkich routerów i kolejek na trasie. Stabilność Internetu jest więc osiągana zaskakująco dużą częścią na podstawie wnioskowania z lokalnych potwierdzeń, strat i czasów odpowiedzi. Efekt widać też przy wielu jednoczesnych połączeniach: każde z nich niezależnie próbuje oszacować dostępną pojemność, a wspólne wąskie gardło wpływa na obserwowane potwierdzenia i straty. Nie jest to idealna centralna alokacja, lecz rozproszony kompromis, który pozwala Internetowi skalować się bez jednego kontrolera przydzielającego pasmo każdemu nadawcy.