W12 Protokół TCP

background image

Protokół TCP

background image

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

background image

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

background image

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.

background image

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

background image

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

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.

background image

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

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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

background image

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.

background image

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

background image

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

background image

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.

background image

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

background image

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.

background image

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.

background image

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.

background image

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

background image

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.

background image

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.

background image

Prewencyjne i reaktywne metody
przeciwdziałania przeciążeniom

background image

Metody aktywnego zarządzania
kolejkami

background image

Metody aktywnego zarządzania
kolejkami


Document Outline


Wyszukiwarka

Podobne podstrony:
Protokół TCP IP, R03 5
Protokol TCP IP R08 5 id 834124 Nieznany
Protokół TCP IP, R12 5
Protokół TCP IP, R11 5
Bezpieczeństwo protokołów TCP IP oraz IPSec
Protokół TCP IP, R13 5
Protokół TCP IP, R09 5
PROTOKOŁY TCP 2
Protokół TCP IP nagłówki
PROTOKOŁY TCP
SIECI KOMPUTEROWE Stos protokołów TCP IP
Bezpieczeństwo protokołów TCP IP oraz IPSec (2)
Podstawy Protokołu TCP
Protokół TCP IP Protokóły internet-u, edukacja i nauka, Informatyka
Wykład13 Sieć teleinformatyczna z protokołem TCP IP
Protokół TCP IP
protokół tcp ip P5XCBJNJZYVPWLAHE2LUZNY6WE75MVPFAUP3ENY

więcej podobnych podstron