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

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) + α

(1 – α) RTT(k-1) + ...

... + α

(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.

Document Outline