Protokół TCP

Plan prezentacji Budowa TCP Sterowanie przepływem połączenia transportowego TCP Przeciwdziałanie przeciążeniom Zarządzanie zwłoką czasową Zarządzanie oknem nadawczym Przypadki użycia TCP

Wprowadzenie Protokół transportowy TCP (Transport Control Protocol) jest stykiem pomiędzy aplikacją realizowaną w systemie końcowym a siecią transmisji danych. Protokół TCP został konstrukcyjnie dostosowany do aplikacji sieciowych generujących ruch elastyczny, tolerujący w dużym stopniu zmienne opóźnienie tranzytowe, ale żądający też niezawodnej transmisji. Dostosowanie TCP do obsługi ruchu strumieniowego – ruchu tolerującego straty, ale wymagającego dochowania ścisłego reżimu czasowego pomiędzy stacjami końcowymi – wymaga wielu modyfikacji jego podstawowych mechanizmów. W koncepcjach dostarczania jakości usług (Integrated Services i Differentiated Services) integrowane są różne metody zarządzania (przejmowane z sieci ATM i Frame Relay) oraz właściwości sieci IP (bezpołączeniowość, sterowanie przepływem oraz przetwarzanie dotyczące QoS na styku sieć – użytkownik).

Protokół TCP Protokół TCP zapewnia: w pełni dwukierunkową, strumieniową usługę transportową, usługę gwarantującą poprawną transmisję (retransmisje, eliminacja duplikatów, zapewnienie kolejności), sterowanie przepływem, oraz przeciwdziałanie przeciążeniom.

Nagłówek TCP Bajty: 1 – 4 5 – 8 9 – 12 13 – 16 17 - 20 0 3 7 11 15 19 23 27 31 numer portu źródłowego numer portu docelowego numer sekwencyjny numer potwierdzenia ACK długość rezerwa znaczniki szerokość okna nagłówka suma kontrolna TCP wskaźnik pilności opcje + dane użytkowe

Nagłówek TCP Nagłówek otwierający segmentu TCP zawiera co najmniej 20 bajtów (160 bitów). 2-bajtowe pola numer portu źródłowego i numer portu docelowego podają numery portów procesów aplikacyjnych wykonywanych w systemach końcowych. 4-bajtowe pola numer sekwencyjny SN i numer potwierdzenia ACK oraz 2-bajtowe pole szerokość okna WND są wykorzystywane do sterowania przepływem (flow control) oraz usuwania błędów (error control). W protokole TCP stosowany jest mechanizm kredytowy sterowania przepływem (credit allocation scheme) wykorzystujący numerację poszczególnych bajtów danych użytkowych: każdy bajt danych użytkowych przekazywanych w segmencie TCP jest identyfikowany przez swój numer będący sumą numeru sekwencyjnego SN oraz jego położenia w polu danych użytkownika, Początkowy numer sekwencyjny ISN (Initial Sequence Number) jest ustalany przez systemy końcowe w fazie nawiązywania połączenia.

Nagłówek TCP Moduł transportowy TCP potwierdza otrzymane dane zapisując w wysyłanym segmencie dwa pola: ACK = i – potwierdzenie odbioru wszystkich bajtów do numeru i-1 włącznie (SN = i jest numerem sekwencyjnym następnego bajtu danych oczekiwanego w systemie końcowym odbierającym segmenty), WND = j – zezwolenie (kredyt, okno) na przekaz następnych j bajtów danych użytkowych, tzn. bajtów o numerach sekwencyjnych SN ze zbioru [ACK, ACK + j-1]. mechanizm udzielania kredytu jest niezależny od potwierdzenia odbioru danych. bajty potwierdzone bajty niepotwierdzone bajty do wysłania ACK WND bajty wysłane

Sterowanie przepływem TCP Prawidłowe ustawienie sterowania przepływem (jakość sterowania) zależy nie tylko od zarządzania oknem (windows management), ale również od sposobu implementacji zasad: nadawania, przyjmowania, dostarczania, retransmisji, potwierdzania.

Sterowanie przepływem TCP - zasady Zasada nadawania: określa sposób tworzenia nadawanego segmentu TCP, segment może być tworzony dla każdego bloku dostarczanego z poziomu aplikacji do bufora nadawczego, albo dla zbioru danych, implementacja zasady jest kompromisem pomiędzy czasem odpowiedzi systemu (komunikujących się procesów aplikacyjnych) a opóźnieniem wynikającym z przetwarzania segmentów TCP.

Sterowanie przepływem TCP - zasady Zasada przyjmowania: dotyczy przypadków, gdy segmenty TCP pojawiają się poza kolejnością, w wariancie pierwszym zasady wszystkie segmenty pojawiające się poza kolejnością są usuwane – zwiększane jest obciążenie sieci ze względu na rosnącą liczbę retransmisji, w wariancie drugim poprawne segmenty pojawiające się poza kolejnością ale należące do okna odbiorczego są przyjmowane za cenę znacznego skomplikowania procedur obsługujących bufor odbiorczy.

Sterowanie przepływem TCP - zasady Zasada dostarczania: jest zwierciadlanym odbiciem zasady nadawania, dotyczy sposobu oddawania danych użytkowych z poziomu TCP do aplikacji: częsta komunikacja pomiędzy TCP a aplikacją skraca czas odpowiedzi systemu (nie licząc czasu obsługi dodatkowych przerwań), sporadyczna komunikacja pomiędzy TCP a aplikacją wydłuża czas odpowiedzi systemu.

Sterowanie przepływem TCP - zasady Zasada retransmisji: definiuje sposób powtórnego nadawania segmentów, dla których upłynęła już kontrolowana zwłoka czasowa (time-out) – czas oczekiwania na potwierdzenie odbioru, zasada retransmisji indywidualnych: wiąże z każdym segmentem (wstawionym do kolejki segmentów oczekujących na retransmisję) zegar odmierzający zwłokę czasową, jeżeli potwierdzenie nadejdzie przed upływem zwłoki, segment jest usuwany z kolejki, a zegar kasowany; w przeciwnym przypadku segment jest nadawany ponownie, a jego zwłoka uruchamiana ponownie. zasada retransmisji grupowej: wiąże jeden zegar z całą kolejką segmentów oczekujących na potwierdzenia, potwierdzane segmenty są usuwane, zegar kasowany i dla pozostałej kolejki uruchamiany ponownie, upływ zwłoki czasowej grupowej powoduje retransmisje wszystkich kolejkowanych segmentów połączoną z ponowny uruchomieniem zegara. grupowa retransmisja jest prosta w implementacji, ale powoduje dodatkowe obciążenia sieci, kompromisem pomiędzy retransmisją indywidualną i grupową jest retransmisja kolejkowana, w której kontrolowana zwłoka czasowa jest odmierzana dla całej kolejki segmentów, natomiast retransmitowany jest wyłącznie pierwszy segment.

Sterowanie przepływem TCP - zasady Zasada potwierdzania: określa czas wysłania potwierdzenia odebranych segmentów, potwierdzanie bezzwłoczne – niekiedy zachodzi konieczność wysyłania pustych segmentów (bez danych użytkowych) zawierających jedynie numer potwierdzenia, potwierdzenia zwłoczne – jest równoważne przekazywaniu potwierdzeń włożonych (piggybacking) do segmentów TCP transmitowanych w przeciwnym kierunku (potwierdzenie bezzwłoczne generuje dodatkowe obciążenie sieci), potwierdzenia zwłoczne generują dodatkowe opóźnienie (ale nie generuje dodatkowego obciążenia sieci), gdy potwierdzający moduł TCP musi najpierw zgromadzić odpowiednią ilość danych użytkowych.

Przeciwdziałanie przeciążeniom TCP Mechanizm kredytowy sterowania przepływem w protokole TCP ma charakter end-to-end i służy do takiej synchronizacji systemów końcowych, aby szybkość nadawania segmentów nie przekraczała szybkości ich odbierania. Efektywna szybkość wysyłania segmentów przez nadawczy system końcowy (w stanie ustalonym) zależy (przede wszystkim) od: zarządzania zwłoką czasową retransmisji (zasady retransmisji) (retransmission timer management), zarządzania oknem nadawczym (window management). Zarządzanie retransmisją i zarządzanie oknem mają wpływ na obciążenie sieci, a ich nieprawidłowa konfiguracja może prowadzić do przeciążenia sieci.

Przeciwdziałanie przeciążeniom TCP - zarządzanie zwłoką czasową i oknem Zarządzanie zwłoką czasową retransmisji: krótka zwłoka czasowa retransmisji jest przyczyną częstych retransmisji, a więc wzrostu wolumenu ruchu i w efekcie przeciążenie sieci, która w stanie zapaści (deadlock) zajmuje się wyłącznie retransmisją utraconych segmentów, zbyt długa zwłoka czasowa powoduje z kolei, że wymiana informacji pomiędzy systemami końcowymi jest wolna. Zarządzanie oknem: zbyt szerokie okno pozwala równoczesnym połączeniom TCP wprowadzić do sieci wiele segmentów, co może powodować wzrost prawdopodobieństwa ich straty, a więc względnie częste retransmisje, czyli wzrost ilości przenoszonego ruchu. Zarządzanie zwłoką czasową i oknem zawiera algorytmy (nie naruszające specyfikacji protokołu TCP) powodujące, że TCP – zaprojektowany do sterowania przepływem – zabezpiecza sieć również przed przeciążeniami.

Zarządzanie zwłoką czasową retransmisji Oznaczenia: RTO(k) – długość zwłoki czasowej retransmisji dla k-tego segementu – czas, po upływie którego następuje retransmisja niepotwierdzonego dotychczas segmentu (Retransmission Time Out), RTT(k) – opóźnienie potwierdzenia segmentu dla k-tego segmentu – różnica pomiędzy czasem otrzymania potwierdzenia segmentu a czasem jego wysłania (Round Trip Time). Do zarządzania zwłoką czasową retransmisji wykorzystywane są m.in. algorytmy: estymacja wariancji RTT, wykładnicze wydłużanie RTO, reguła Karna.

Zarządzanie zwłoką czasową retransmisji - estymacja wariancji RTT Definicja zwłoki czasowej retransmisji dla (k+1)-szego segmentu (TCP RFC793): RTO(k+1) = β x SRTT(k+1) przy czym na ogół β = 2, a ważone opóźnienie potwierdzenia SRTT (Smoothed Round-trip Time) jest dane zależnością: SRTT(k+1) = α SRTT(k) + (1 – α) RTT(k+1), przy czym 0 < α < 1. SRTT jest ważonym czasem potwierdzenia segmentów RTT; SRTT można zapisać w postaci sumy w której wcześniejsze pomiary RTT mają mniejsze znaczenie: SRTT(k+1) = (1 – α) RTT(k+1) + α(1 – α) RTT(k) + α2(1 – α) RTT(k-1) + ... ... + αk(1 – α) RTT(1) + αk+1 RTT(0) .

Zarządzanie zwłoką czasową retransmisji - estymacja wariancji RTT

Zarządzanie zwłoką czasową retransmisji - wykładnicze wydłużanie RTO

Zarządzanie zwłoką czasową retransmisji - reguła Karna

Zarządzanie zwłoką czasową retransmisji - reguła Karna

Zarządzanie oknem nadawczym Sposób zarządzania oknem nadawczym protokołu TCP istotnie wpływa na zabezpieczanie sieci przed przeciążeniem. Do zarządzania oknem nadawczym stosowane są m.in. następujące algorytmy: spowolniony start (slow start), dynamiczne wymiarowanie okna (dynamic window sizing), przyśpieszona retransmisja (fast retransmission), przyśpieszone odzyskiwanie (fast recovery).

Zarządzanie oknem nadawczym - spowolniony start Pomiędzy modułem nadawczym i odbiorczym TCP występuje efekt synchronizacji (self-clocking) – moduł nadawczy wysyła segmenty w rytm otrzymywanych od modułu odbiorczego potwierdzeń. Rytm ten jest determinowany przez „wąskie gardło” połączenia. Możliwe przypadki niedostosowania: w przypadku początku transmisji i braku synchronizacji (brak potwierdzeń) transmisja segmentów może być niepotrzebnie spowolniona. nadmierne rozszerzenie okna nadawczego, dające możliwość transmisji bez potwierdzeń, może doprowadzić do przeciążenia sieci.

Zarządzanie oknem nadawczym - spowolniony start Aktualna szerokość okna nadawczego – zgodnie z algorytmem spowolnionego startu – wynosi: AWND = min (CRD, CWND) gdzie: AWND (Allowed Window) jest aktualną szerokością okna, CWND (Congestion Window) jest zredukowaną szerokością okna stosowaną w warunkach przeciążenia oraz przy nawiązywaniu połączenia, CRD = WND/MSS jest szerokością okna odbiorczego wyznaczoną w segmentach (credit) jako iloraz wartości pola WND przekazywanego w nagłówkach segmentów nadawanych przez moduł odbiorczy TCP oraz długości segmentu MSS (Maximum Segment Size) Po nawiązaniu połączenia moduł nadawczy TCP ustala zredukowaną szerokość okna CWND = 1; zredukowana szerokość okna CWND jest powiększana o 1 z każdym otrzymanym potwierdzeniem do chwili wejścia w stan ustalony, w którym transmisja jest kontrolowana wyłącznie przez okno odbiorcze CRD. Indywidualne potwierdzanie segmentów prowadzi do szybkiego (wykładniczego) wzrostu aktualnej szerokości okna.

Zarządzanie oknem nadawczym - dynamiczne wymiarowanie okna Jak powinien zareagować protokół TCP na przeciążenie w sieci, za którego objaw można uznać pierwszą retransmisję segmentu? Naturalnym jest przyjęcie założenia, że w warunkach potencjalnego przeciążenia moduł nadawczy TCP powinien zmniejszyć szybkość nadawania segmentów, a to można uzyskać uruchamiając od chwili pierwszej retransmisji algorytm spowolnionego startu. Rozładowanie przeciążenia sieci jest z reguły czasochłonne, a algorytm spowolnionego startu (z wykładniczym poszerzaniem okna) jest zbyt agresywny i może utrudniać rozładowanie przeciążenia. Spowolnienie procesu rozszerzania okna nadawczego można uzyskać korzystając z algorytmu dynamicznego wymiarowania okna (dynamic window sizing) uruchomianego w chwilą retransmisji segmentu.

Zarządzanie oknem nadawczym - dynamiczne wymiarowanie okna Algorytm dynamicznego wymiarowania okna – modyfikacja algorytmu powolnego startu. Algorytm dynamicznego wymiarowania: z chwilą retransmisji w module nadawczym TCP jest wyliczana wartość progowa SSTRESH = CWND/2 (Slow Start Threshold), uruchamiana jest procedura powolnego startu dla CWND = 1, z każdym otrzymanym potwierdzeniem okno powiększane jest o 1 aż do CWND = SSRTESH (wykładnicze rozszerzanie okna), po przekroczeniu wartości progowej CWND > SSRTESH okno nadawcze CWND jest rozszerzane o 1 w odstępach czasu równych opóźnieniu potwierdzenia RTT (liniowe rozszerzanie okna).

Zarządzanie oknem nadawczym - przyśpieszona retransmisja Procedura przyśpieszonej retransmisji (fast retransmission) zabezpiecza połączenie TCP przed specyficznym przeciążeniem pojawiającym się zawsze wtedy, gdy połączenie gubi pierwszy segment należący do ciągu segmentów. Moduł odbiorczy gromadzi wszystkie odebrane segmenty (leżące w oknie odbiorczym), ale nie może ich przekazać do warstwy aplikacji bo nie ma kompletu segmentów. Jeżeli retransmisja zagubionego segmentu przeciąga się, to możliwe jest wstrzymanie przyjmowania poprawnych segmentów (ze względu na brak wolnej pamięci buforowej), które – z kolei – uruchamia narastającą liczbę retransmisji.

Zarządzanie oknem nadawczym - przyśpieszona retransmisja Zasada przyśpieszonej retransmisji: moduł odbiorczy TCP w chwilą otrzymania segmentu poza kolejnością wysyła natychmiast potwierdzenie dla ostatniego segmentu odebranego jeszcze w kolejności, moduł odbiorczy wysyła to potwierdzenie z każdym odebranym segmentem aż do chwili otrzymania brakującego segmentu, gdy moduł odbiorczy otrzyma brakujący segment, opróżnia bufor oraz wysyła potwierdzenie zbiorcze, Możliwe interpretacje odbioru duplikatu potwierdzenia w module nadawczym TCP: segment wysyłany po ostatnim potwierdzonym segmencie został opóźniony, ale w końcu dotarł i retransmisja nie jest potrzebna, nastąpiło zgubienie segmentu i retransmisja jest konieczna. W praktyce przyjmuje się, że moduł nadawczy TCP decyduje o retransmisji (druga interpretacja) po otrzymaniu 4 potwierdzeń tego samego segmentu. Procedura umożliwia przyśpieszoną retransmisję zagubionego segmentu jeszcze przed upływem przypisanej mu zwłoki czasowej.

Prewencyjne i reaktywne metody przeciwdziałania przeciążeniom

Metody aktywnego zarządzania kolejkami

Metody aktywnego zarządzania kolejkami