Rdzeń Niezawodności: Dlaczego Retransmisja Jest Niezbędna

Wyobraźmy sobie, że składasz skomplikowaną maszynę, zamawiając jej części online od jednego dostawcy. Części są ponumerowane i przeznaczone do montażu w określonej kolejności. Usługa kurierska, która dostarcza te części, to Protokół Internetowy (IP), który jest szybki i wydajny, ale nie daje żadnych gwarancji niezawodności. Działa on w modelu best-effort.

Oznacza to, że podczas transportu jedno z pudełek zawierających kluczową część może zaginąć. Inne pudełko może zostać opóźnione i dotrzeć po części, która została wysłana później. Jako odbiorca nie możesz złożyć maszyny, jeśli brakuje jednej części lub jeśli nie znasz prawidłowej kolejności. Potrzebujesz nadzorcy, który śledzi przesyłkę, zauważa, gdy brakuje części, i dzwoni do dostawcy, aby wysłał zamiennik.

W świecie cyfrowym TCP jest właśnie takim sumiennym nadzorcą. Rozumie, że bazowa sieć IP jest z natury zawodna. Główną obietnicą TCP jest dostarczenie kompletnego, uporządkowanego strumienia danych do aplikacji docelowej. Aby spełnić tę obietnicę, musi mieć solidny system do wykrywania, kiedy segmenty danych zostały utracone, oraz mechanizm do uruchamiania ich retransmisji. Mechanizmy retransmisji TCP to zestaw reguł i algorytmów, które wykrywają utratę danych i zapewniają, że utracone segmenty zostaną wysłane ponownie, gwarantując, że ostateczna wiadomość jest kompletna i poprawna, bez względu na to, jak chaotyczna była podróż przez sieć.

Wykrywanie Strat: Dwa Główne Wyzwalacze Retransmisji

Zanim TCP będzie mogło retransmitować utracony segment, musi najpierw zorientować się, że segmentu brakuje. Nie otrzymuje ono jawnych powiadomień z sieci o treści pakiet został odrzucony. Zamiast tego musi wnioskować o stracie na podstawie potwierdzeń (lub ich braku), które otrzymuje z drugiego końca. Istnieją dwa podstawowe sygnały, które wywołują to wnioskowanie.

1. Powolna Ścieżka: Przekroczenie Limitu Czasu Retransmisji (RTO)

To jest fundamentalny, ostateczny mechanizm TCP do wykrywania utraconego segmentu. Logika jest prosta:

1. Dla każdego wysłanego segmentu danych nadawca uruchamia Licznik Czasu Retransmisji (ang. Retransmission Timer).
2. Następnie nadawca czeka na odpowiednie potwierdzenie (ACK) od odbiorcy.
3. Jeśli ACK dotrze, zanim licznik wygaśnie, licznik jest zatrzymywany i resetowany dla następnego segmentu. Dane uważa się za dostarczone.
4. Jeśli licznik wygaśnie, zanim dotrze ACK, nadawca zakłada, że segment (lub jego potwierdzenie) zaginął w tranzycie.

Zdarzenie RTO jest silnym wskaźnikiem problemu sieciowego, albo znaczne przeciążenie powoduje długie opóźnienia, albo ścieżka sieciowa jest tymczasowo przerwana. Nadawca reaguje, retransmitując niepotwierdzony segment i podejmując drastyczne środki w celu zmniejszenia obciążenia sieci, jak omówiono w kontroli przeciążenia. Choć metoda ta jest niezwykle niezawodna, oczekiwanie na wygaśnięcie licznika może być bardzo powolne, zwłaszcza w sieciach o wysokiej latencji.

2. Szybka Ścieżka: Zduplikowane Potwierdzenia

Nowoczesne TCP nie musi polegać wyłącznie na wolnych timeoutach. Posiada bardziej inteligentny, szybszy sposób wnioskowania o utracie pakietów, zwłaszcza w przypadkach lekkiego przeciążenia. Ten mechanizm opiera się na obserwacji wzorca przychodzących potwierdzeń ACK.

TCP używa schematu potwierdzeń kumulatywnych. ACK z numerem $N$ oznacza, że odbiorca otrzymał wszystkie bajty aż do $N-1$ i teraz oczekuje bajtu $N$. Jeśli segmenty dotrą w złej kolejności, odbiorca nie może jeszcze potwierdzić nowych danych. Zamiast tego natychmiast ponownie wysyła ACK dla ostatniego bajtu, który otrzymał w kolejności. To powtórzone ACK dla starych danych nazywa się zduplikowanym ACK.

Zgodnie z konwencją, jeśli nadawca otrzyma trzy zduplikowane ACK z rzędu, traktuje to jako bardzo silny sygnał, że pojedynczy segment następujący bezpośrednio po potwierdzonych danych został utracony, podczas gdy kolejne segmenty zostały pomyślnie odebrane. Jest to znacznie szybszy wyzwalacz retransmisji, ponieważ nadawca nie musi czekać na wygaśnięcie pełnego RTO.

Szybka Retransmisja i Szybkie Odzyskiwanie: Inteligentna Odpowiedź TCP

Wykrycie utraty pakietu za pomocą trzech zduplikowanych ACK umożliwia działanie dwóch potężnych, powiązanych ze sobą algorytmów, które znacznie poprawiają wydajność TCP w sieciach z utratą pakietów: Szybkiej Retransmisji i Szybkiego Odzyskiwania. Algorytmy te zostały wprowadzone w implementacji TCP Reno i stanowią podstawę nowoczesnej niezawodności TCP.

Szybka Retransmisja (Fast Retransmit)

Algorytm Szybkiej Retransmisji jest prosty:

Po otrzymaniu trzeciego zduplikowanego ACK, nie czekaj na wygaśnięcie Licznika Czasu Retransmisji. Natychmiast retransmituj pojedynczy utracony segment, o który proszą.

Ta proaktywna retransmisja może zaoszczędzić cały czas obiegu (lub więcej) oczekiwania, radykalnie przyspieszając proces odzyskiwania. Nazywa się ją "szybką", ponieważ omija powolny mechanizm timeoutu.

Szybkie Odzyskiwanie (Fast Recovery)

Szybkie Odzyskiwanie odpowiada na pytanie, co zrobić natychmiast po Szybkiej Retransmisji. Nadejście zduplikowanych ACK dostarcza cennej informacji: sieć nie jest martwa. Dane wciąż płyną, w przeciwnym razie pakiety spoza kolejności, które wywołały zduplikowane ACK, by nie dotarły.

Dlatego gwałtowne hamowanie przez zresetowanie okna przeciążeniowego (cwnd) z powrotem do 1 MSS (jak by to miało miejsce po RTO) byłoby niepotrzebną przesadą, która zdławiłaby przepustowość.

Zamiast tego algorytm Szybkiego Odzyskiwania robi, co następuje:

1. Mnożeniowy Spadek: Obniża próg powolnego startu ('ssthresh') o połowę $(\text{ssthresh} = \text{cwnd} / 2)$. Następnie ustawia 'cwnd' na tę nową wartość 'ssthresh'. To jest część kontroli przeciążenia "mnożeniowego spadku".
2. Tymczasowe Zwiększenie: Czekając na potwierdzenie retransmitowanego segmentu, nadawca tymczasowo zwiększa swoje 'cwnd' za każde dodatkowe zduplikowane ACK, które dotrze. Pozwala to na wysyłanie nowych segmentów i utrzymanie przepływu danych, zapobiegając opróżnieniu "rury" sieciowej.
3. Wznowienie Unikania Przeciążenia: Gdy dotrze ACK dla retransmitowanych danych, 'cwnd' jest "opróżniane" z powrotem do wartości 'ssthresh', a nadawca wznawia swój normalny, liniowy wzrost od tego nowego, niższego punktu w fazie Unikania Przeciążenia.

Razem, Szybka Retransmisja i Szybkie Odzyskiwanie pozwalają TCP efektywnie naprawić pojedynczy utracony segment w ciągu jednego czasu obiegu, bez zatrzymywania transmisji i niepotrzebnego zwalniania, co prowadzi do znacznie wyższej i bardziej stabilnej wydajności.

Ograniczenie Potwierdzeń Kumulatywnych i Rozwiązanie: SACK

Chociaż mechanizm Szybkiej Retransmisji/Odzyskiwania jest doskonały przy pojedynczych utratach pakietów, ma znaczącą słabość, gdy z jednego okna transmitowanych danych zginie wiele pakietów.

Problem Wielokrotnej Utraty Pakietów

Rozważmy ponownie analogię z dostawą części. Nadawca wysyła 10 pudełek (segmentów). Firma kurierska gubi pudełka 3 i 6. Odbiorca dostaje pudełka 1, 2, 4, 5, 7, 8, 9 i 10. Używając systemu potwierdzeń kumulatywnych, jedyne co odbiorca może zgłosić, to: Wciąż czekam na pudełko 3.

Nadawca w końcu otrzyma trzy zduplikowane ACK dla pudełka 3 i wykona Szybką Retransmisję. Wyśle ponownie pudełko 3. To retransmitowane pudełko musi następnie przebyć drogę przez sieć. Dopiero gdy odbiorca otrzyma pudełko 3, może wreszcie potwierdzić odbiór aż do pudełka 5 i zgłosić: Teraz czekam na pudełko 6. Nadawca musi czekać cały czas obiegu, aby dowiedzieć się o drugim zgubionym pudełku. Odzyskanie dwóch utraconych pakietów zajmuje dwa RTT. To jest bardzo nieefektywne.

Potwierdzenie Selektywne (SACK) na Ratunek

Aby przezwyciężyć to ograniczenie, opracowano rozszerzenie do TCP zwane Potwierdzeniem Selektywnym (SACK). SACK to Opcja TCP, na której użycie obie strony muszą się zgodzić podczas początkowego trójetapowego uzgadniania.

Opcja SACK pozwala odbiorcy na znacznie więcej niż tylko zgłaszanie ostatniego bajtu w kolejności. Wraz z normalnym potwierdzeniem kumulatywnym, odbiorca może dołączyć bloki SACK w opcjach nagłówka TCP. Te bloki jawnie wymieniają nieciągłe zakresy danych, które zostały pomyślnie odebrane.

Jak SACK Działa w Praktyce

Wróćmy do naszego przykładu z włączonym SACK. Nadawca wysyła segmenty 1-10. Segmenty 3 i 6 giną.

1. Odbiorca otrzymuje segmenty 1 i 2. Wysyła normalne ACK z Numerem Potwierdzenia dla początku segmentu 3.
2. Odbiorca otrzymuje segment 4. Zauważa lukę. Natychmiast wysyła zduplikowane ACK dla początku segmentu 3, ale tym razem dołącza Opcję SACK mówiącą: Przy okazji, otrzymałem blok danych odpowiadający segmentowi 4.
3. Odbiorca otrzymuje segment 5. Wysyła kolejne zduplikowane ACK dla segmentu 3, teraz z opcją SACK mówiącą: Otrzymałem blok danych odpowiadający segmentom 4-5.
4. Nadawca otrzymuje te zduplikowane ACK. Trzecie wyzwala Szybką Retransmisję segmentu 3. Ale co kluczowe, nadawca przetwarza również informacje SACK. Teraz wie, że segmenty 4 i 5 zostały pomyślnie odebrane i nie trzeba ich retransmitować. Oznacza je w swoich strukturach danych jako "SACKed".
5. Następnie odbiorca otrzymuje segment 7. Wysyła jeszcze jedno zduplikowane ACK dla segmentu 3, ale opcja SACK jest zaktualizowana, aby zgłosić: Otrzymałem bloki 4-5 i 7.
6. Z tą nową informacją SACK nadawca ma pełny obraz. Wie, że pomyślnie retransmitował segment 3 i że segmenty 4, 5, 7 i wszystkie kolejne dotarły. Jedyną pozostałą "dziurą" w strumieniu danych jest segment 6. Nadawca może natychmiast retransmitować segment 6, nie czekając na kolejny RTT.

Dostarczając szczegółową mapę odebranych danych, SACK pozwala nadawcy wypełnić wszystkie "dziury" w ciągu jednego czasu obiegu, radykalnie poprawiając wydajność i przepustowość TCP w sieciach, które doświadczają więcej niż sporadycznej utraty pakietów. Jest to kluczowa funkcja dla wysokiej wydajności współczesnego internetu.