Podręcznik

Kontrola przepływu i zarządzanie zatorami to dwa niezależne, ale ściśle współpracujące mechanizmy implementowane w protokole TCP, których celem jest zapewnienie stabilnej i wydajnej komunikacji pomiędzy urządzeniami w sieci. Kontrola przepływu chroni odbiorcę przed przeciążeniem bufora poprzez ograniczanie liczby bajtów, które nadawca może wysłać bez potwierdzenia. W tym celu TCP wykorzystuje tzw. okno odbiorcze (receiver window), którego rozmiar komunikuje odbiorca w każdym segmencie ACK. Z kolei zarządzanie zatorami działa po stronie nadawcy i ma za zadanie unikać przeciążenia sieci, które może prowadzić do masowej utraty pakietów, zwiększonych opóźnień i spadku wydajności. TCP realizuje to poprzez mechanizmy kontrolujące tempo transmisji w zależności od obserwowanej odpowiedzi sieci, w tym opóźnień, utraty pakietów i potwierdzeń. Kluczowe komponenty to okno przeciążeniowe (congestion window), zmienne progowe (ssthresh) oraz algorytmy: Slow Start, Congestion Avoidance, Fast Retransmit i Fast Recovery. Obie techniki działają równolegle, zapewniając równowagę pomiędzy przepustowością a stabilnością.

W ramach kontroli przepływu TCP wykorzystuje mechanizm nazywany przesuwanym oknem odbiorczym. Działa on w oparciu o zasadę informowania nadawcy przez odbiorcę o tym, ile jeszcze bajtów danych jest w stanie przyjąć bez ryzyka przepełnienia bufora. Przy każdym pakiecie ACK odbiorca przesyła informację w polu „Window Size” nagłówka TCP, wskazując liczbę bajtów, które może jeszcze odebrać. Nadawca nie może przekroczyć tej wartości przy kolejnych wysyłanych danych. Działa to jak ogranicznik prędkości, który jest elastyczny i zależy od aktualnego stanu aplikacji odbierającej dane.

Dla przykładu, jeśli bufor odbiorcy ma pojemność 4096 bajtów, a dotychczas odebrano 1024 bajty, to w kolejnym ACK zostanie zadeklarowane „Window Size = 3072”, co informuje nadawcę, że tyle jeszcze może wysłać. Gdy bufor odbiorcy się zapełni, wartość tego pola może spaść do zera, co zmusza nadawcę do zatrzymania transmisji do momentu otrzymania okna większego od zera. To zapobiega sytuacji, w której nadawca "zalewa" odbiorcę danymi, których ten nie jest w stanie przetworzyć na czas.

Mechanizm przesuwnego okna pozwala na równoczesne zarządzanie wieloma segmentami, których odbiór jest oczekiwany. Okno „przesuwa się” do przodu wraz z postępem transmisji, co oznacza, że kolejne dane mogą być przesyłane w miarę, jak odbiorca potwierdza otrzymanie poprzednich segmentów.

Gdy odbiorca potwierdzi odebranie segmentów C i D, okno przesuwa się dalej:

Dzięki temu dane są wysyłane płynnie i tylko w zakresie, który odbiorca może przyjąć.

W standardowym TCP pole „Window Size” ma długość 16 bitów, co pozwala na zadeklarowanie maksymalnie 65 535 bajtów. W przypadku szybkich sieci, w których produkt opóźnienia i przepustowości (bandwidth-delay product) jest większy, to ograniczenie może znacząco obniżyć efektywność transmisji. Dlatego wprowadzono opcję rozszerzenia okna za pomocą tzw. „Window Scale Option”, która wprowadza mnożnik (skalę) pozwalający na deklarowanie rozmiaru okna do wartości 1 GB. Mnożnik ten ustalany jest podczas fazy nawiązywania połączenia i jest stały przez całą sesję. W ten sposób TCP może efektywnie wykorzystać szybkie połączenia, nie będąc ograniczonym przez rozmiar nagłówka.

W sytuacji, gdy wartość okna spada do zera, nadawca przerywa transmisję i oczekuje na powiększenie okna przez odbiorcę. Aby uniknąć sytuacji „wiecznego oczekiwania”, TCP stosuje mechanizm „Zero Window Probe”, w którym okresowo wysyła pojedyncze bajty danych, aby sprawdzić, czy okno odbiorcy zostało powiększone. Jeśli tak, transmisja może być wznowiona. Mechanizm ten działa jako rodzaj pulsacyjnego testu – wystarczającego, by utrzymać połączenie i sprawdzić gotowość odbiorcy do kontynuacji.

TCP nieustannie dostosowuje rozmiar swojego okna wysyłkowego, który jest efektywnym minimum z dwóch wartości: rozmiaru okna deklarowanego przez odbiorcę (flow control) oraz okna przeciążeniowego (congestion control). Ostateczna liczba bajtów, które mogą być wysłane bez potwierdzenia, to wartość min(CWND, RCV_WINDOW), co oznacza, że kontrola przepływu i zarządzanie zatorami działają razem, ustalając wspólny limit na transmisję.

Zarządzanie zatorami w TCP to mechanizm dynamicznego dostosowywania tempa transmisji danych w zależności od obciążenia sieci. W przeciwieństwie do kontroli przepływu, która chroni odbiorcę, mechanizmy przeciążeniowe mają na celu unikanie utraty pakietów w sieci wynikającej z przepełnienia buforów na routerach. Sygnały przeciążenia nie są przekazywane bezpośrednio – TCP wykrywa je pośrednio, najczęściej na podstawie utraty pakietów lub duplikatów ACK.

Główne komponenty tego mechanizmu to zmienna CWND (Congestion Window), która określa, ile bajtów nadawca może wysłać, zanim otrzyma potwierdzenia, oraz zmienna ssthresh (slow start threshold), która określa granicę między trybem Slow Start a Congestion Avoidance.

Na początku transmisji CWND wynosi 1 MSS (Maximum Segment Size), a TCP rozpoczyna transmisję w trybie Slow Start. W tym trybie, za każdy otrzymany ACK, CWND rośnie wykładniczo – co rundę RTT się podwaja. Mechanizm ten szybko „testuje” przepustowość sieci, ale prowadzi też do potencjalnego przeciążenia. W momencie, gdy CWND osiąga wartość ssthresh, TCP przechodzi do trybu Congestion Avoidance, w którym CWND rośnie już liniowo – o 1 MSS na rundę RTT.

Jeśli następuje utrata pakietu, wykryta przez timeout lub trzy duplikaty ACK, TCP uznaje to za przeciążenie sieci. W takiej sytuacji CWND zostaje zmniejszone – zależnie od algorytmu – i następuje powrót do jednej z wcześniejszych faz. Gdy pakiet zostanie utracony i nie zostanie potwierdzony, TCP inicjuje retransmisję i odpowiednio dostosowuje CWND.

Algorytm Fast Retransmit uruchamia się wtedy, gdy nadawca otrzyma trzy kolejne identyczne ACK (czyli odbiorca zgłasza „ciągle ten sam brakujący bajt”). W odpowiedzi nadawca natychmiast retransmituje brakujący segment, nie czekając na timeout. Po Fast Retransmit aktywowany jest Fast Recovery – CWND zostaje zmniejszony o połowę, ale nie do wartości początkowej, a TCP przechodzi bezpośrednio do Congestion Avoidance.

Cały ten mechanizm uzupełnia model AIMD (Additive Increase, Multiplicative Decrease), który steruje wartością CWND zgodnie z następującą logiką: po każdej rundzie bez przeciążenia CWND rośnie o 1 MSS (additive increase), natomiast po wykryciu przeciążenia CWND zostaje natychmiast zredukowane o połowę (multiplicative decrease).

Zarządzanie zatorami umożliwia TCP zachowanie tzw. sprawiedliwości sieciowej, czyli równomiernego podziału zasobów między wiele równoległych połączeń TCP, działających przez wspólną infrastrukturę. Dzięki strategii AIMD, protokoły TCP automatycznie dostosowują swoje tempo, zmniejszając agresję transmisji w przypadku wykrycia przeciążenia i zwiększając ją stopniowo w stabilnych warunkach. Z czasem każde połączenie osiąga równowagę zależną od warunków sieciowych.

Mechanizmy te, choć złożone, są przezroczyste dla użytkownika końcowego. Dla programistów oraz inżynierów sieci istotne jest jednak zrozumienie, jak TCP dynamicznie reaguje na różne warunki transmisji i jak parametry CWND, RTT, ssthresh i czas retransmisji (RTO) wpływają na efektywność, niezawodność i przepustowość połączenia. W implementacjach TCP spotyka się różne warianty algorytmów kontroli przeciążenia, takie jak TCP Reno, NewReno, Cubic, BBR – wszystkie one jednak opierają się na tych samych podstawowych zasadach adaptacyjnego sterowania ruchem.

Mechanizm przesuwnego okna (Sliding Window)

W TCP każde połączenie traktuje dane jako strumień bajtów. Aby kontrolować, ile danych można przesłać bez oczekiwania na potwierdzenie, wykorzystywane jest okno transmisyjne. Okno to reprezentuje zakres bajtów, które mogą być przesłane, ale jeszcze nie zostały potwierdzone przez odbiorcę.

Działanie okna przesuwnego

Okno przesuwne działa w następujący sposób:

1. Nadawca utrzymuje zmienną: rozmiar okna.

2. Wysłanie danych w zakresie tego okna nie wymaga oczekiwania na potwierdzenie.

3. Gdy odbiorca potwierdzi odbiór określonej liczby bajtów (ACK), okno przesuwa się do przodu, pozwalając na wysłanie kolejnych danych.

Załóżmy, że nadawca ma dane od bajtu 1 do 500, a rozmiar okna wynosi 100 bajtów:

W każdym cyklu przesunięcie okna zależy od tego, ile danych zostało potwierdzonych. TCP traktuje dane jako ciąg bajtów, więc każde ACK odnosi się do numeru kolejnego oczekiwanego bajtu.

Dynamiczne skalowanie okna

Rozmiar okna transmisji może być dynamicznie dostosowywany na podstawie sygnałów od odbiorcy. Jest to konieczne, gdy:

• odbiorca ma ograniczone bufory;

• aplikacja odbierająca dane nie nadąża z przetwarzaniem;

• następuje krótkotrwały problem z wydajnością odbiorcy.

Pole „Window Size”

W nagłówku TCP znajduje się 16-bitowe pole „Window Size”, które określa ile bajtów danych odbiorca może jeszcze przyjąć. Jeśli wartość ta wynosi 0, nadawca musi wstrzymać się z dalszym wysyłaniem danych i cyklicznie próbować, czy okno zostało powiększone (mechanizm zero window probe).

Rozszerzenie okna – opcja „Window Scale”

Standardowy 16-bitowy rozmiar okna ogranicza możliwość przesłania więcej niż 65 535 bajtów bez potwierdzenia. W szybkich sieciach o dużej przepustowości i opóźnieniu (tzw. high-bandwidth delay product) może to być niewystarczające. Rozwiązaniem jest rozszerzenie rozmiaru okna dzięki opcji TCP „Window Scale”, która wprowadza 14-bitowy współczynnik skalowania.

Zjawisko blokady odbiornika (Receiver Silencing)

Jeśli aplikacja po stronie odbiorcy przestanie odbierać dane z bufora TCP, jego rozmiar może osiągnąć 0. Wtedy pole „Window Size” zostaje wyzerowane, a nadawca nie może przesyłać dalszych danych. Może jedynie cyklicznie wysyłać Zero Window Probes, aby sprawdzić, czy sytuacja uległa poprawie.

Zalety i ograniczenia

Zaletą kontroli przepływu w TCP jest to, że działa dynamicznie i automatycznie, dostosowując tempo nadawcy do możliwości odbiorcy. Umożliwia to bezpieczną transmisję danych nawet między systemami o różnych wydajnościach. Ograniczeniem natomiast jest to, że jeśli aplikacja odbiorcza jest zbyt wolna, może dojść do zatrzymania całej komunikacji.

Interakcja z zarządzaniem zatorami

Choć kontrola przepływu i zarządzanie zatorami to dwa różne mechanizmy, ich działanie może się zazębiać. Przykładowo, jeśli routery pośrednie są przeciążone, mogą zaczynać odrzucać pakiety, co zostanie zinterpretowane przez TCP jako oznaka przeciążenia – wywołując reakcję nie tylko na poziomie sieci, ale też modyfikując tempo wysyłania u nadawcy.