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
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
Bajty:
1 – 4
5 – 8
9 – 12
13 – 16
17 - 20
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
WND
bajty wysłane
ACK
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
Implementacja zależności:
RTO(k+1) = SRTT(k+1) oraz
SRTT(k+1) = SRTT(k) + (1-) RTT(k+1)
“uczula” protokół TCP na fluktuacje opóźnienia potwierdzenia
segmentów RTT.
Ten sposób zarządzania zwłoką czasową retransmisji RTO
nie zdaje egzaminu wtedy, gdy fluktuacje opóźnienia
potwierdzenia segmentów RTT stają się zbyt duże, których
przyczyną mogą być nagłe zmiany poziomu ruchu w sieci lub
zwłoczne potwierdzanie segmentów.
Działanie protokołu TCP można poprawić, gdy do obliczania
wartości kolejnych zwłok retransmisji wykorzystywany jest
algorytm J acobsona:
RTO(k+1) = SRTT(k+1) + f + SDEV(k+1)
gdzie f = 2, a SDEV jest estymatorem wariancji opóźnienia
RTT.
Zarządzanie zwłoką czasową
retransmisji
- wykładnicze wydłużanie RTO
Algorytm J acobsona:
RTO(k+1) = SRTT(k+1) + f + SDEV(k+1)
nie precyzuje sposobu ustalania długości zwłoki czasowej
retransmisji RTO dla retransmitowanych segmentów.
W specyfikacji RFC793 wartość zwłoki czasowej RTO dla
pierwszych transmisji segmentów i ich ewentualnych
retransmisji jest taka sama – strategia ta nie jest najlepsza,
bo jeżeli dochodzi do retransmisji to najprawdopodobniej sieć
jest przeciążona.
Zasadnym jest więc założenie, że konieczność retransmisji
może być powodowana przeciążeniem sieci i zbyt krótkim –
w sytuacji przeciążenia sieci – czasem zwłoki RTO.
Uzasadnionym jest więc rozwiązanie, w którym przyjmuje się
że zwłoka retransmisji RTO jest wykładniczo wydłużana
(exponential backoff):
RTO(j+1) = q RTO(j);
najczęściej q = 2 (binarne – wykładnicze wydłużanie zwłoki).
Zarządzanie zwłoką czasową
retransmisji
- reguła Karna
Ważone opóźnienie potwierdzenia segmentu:
RTO(k+1) = SRTT(k) + (1 - ) RTT(k+1)
zależy od opóźnienia potwierdzenia segmentów RTT
mierzonego jako różnica pomiędzy czasem otrzymania
potwierdzenia segmentu T.ACK a czasem jego wysłania
T.SND (T.ACK – T.SND).
Problem z wyznaczeniem opóźnienia RTT występują wtedy,
gdy pojawiają się retransmisje segmentów.
Możliwe szacowania (w przypadku retransmisji – moduł
nadawczy nie rozróżnia, czy potwierdzenie dotyczy pierwszej
transmisji, czy retransmisji):
RTT = T.ACK(2) – T.SND(1) – opóźnienie zbyt duże w
porównaniu do rzeczywistego opóźnienia T.ACK(2) –
T.SND(2) potwierdzenia,
RTT = T.ACK(1) – T.SND(2) – zbyt małe w porównaniu do
wartości rzeczywistego opóźnienia potwierdzenia T.ACK(1)
– T.SND(1).
Zarządzanie zwłoką czasową
retransmisji
- reguła Karna
Wstawienie do wyrażenia na ważone opóźnienie potwierdzenia
segmentu:
RTO(k+1) = SRTT(k) + (1 - ) RTT(k+1)
powiększonego opóźnienia RTT spowoduje wydłużenie zwłoki
retransmisji RTO, a w efekcie spowolnienie wymiany danych
pomiędzy systemami końcowymi.
Wstawienie do wyrażenia na ważone opóźnienie potwierdzenia
segmentu zmniejszonego opóźnienia RTT spowoduje skrócenie
zwłoki retransmisji RTO, a w efekcie częstsze retransmisje
systemami końcowymi powodujące wzrost obciążenia sieci.
Stosowane rozwiązanie polega na tym, że z chwilą pojawienia się
retransmisji „wyłączany” jest algorytm szacowania ważonej zwłoki
czasowej, a zastosowanie ma wykładnicze wydłużanie zwłoki
czasowej retransmisji.
Kolejne retransmisje kontrolowane są zwłoką czasową RTO
wyliczaną z algorytmu wydłużania wykładniczego aż do nadejścia
potwierdzenia segmentu nieretransmitowanego – od tego momentu
kolejne zwłoki czasowe RTO są obliczane z użyciem algorytmu
ważonego.
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