Działanie i konfiguracja TCP

1.  Wprowadzenie do TCP

ˇ       Transmission Control Protocol

§         Komponent warstwy transportowej

Protokół sterujący transmisją TCP jest komponentem warstwy transportowej stosu protokołów TCP/IP. W hierarchii protokołów lokuje się on ponad protokołem IP.

§         Niezawodna wymiana danych

Protokół TCP realizuje usługę niezawodnej wymiany danych w łączach zorientowanych na połączenie. Oznacza to, że pisanie aplikacji sieciowych wymieniających dane i wiadomości z innymi komputerami – a tym samym komunikujących się z niższymi warstwami protokołów sieciowych w celu przesyłania tych danych – nie ma potrzeby tworzenia funkcji weryfikujących, czy dane zostały odebrane. To zadanie realizuje niezawodny protokół TCP.

§         Wykorzystanie protokołu IP

Protokół TCP wykorzystuje protokół IP do przesyłania informacji poprzez sieć. Zaskakujące jest jednak to, że IP jest bezpołączeniowym protokołem sieciowym, nie gwarantującym niezawodnego przekazu danych. W zamian za to IP oferuje efektywny mechanizm transmisji. Jego wady związane z niezawodnością eliminuje nadrzędny protokół TCP. Dane i wiadomości TCP (oficjalnie nazwane segmentami) są umieszczane w datagramach IP i przesyłane przez ten protokół poprzez sieć.

§         Hermetyzacja realizowana przez router

W zamyśle protokół TCP stworzony został w celu sprzęgania komputerów wielu różnych typów znajdujących się w instytutach badawczych, na uniwersytetach i w agencjach rządowych. Projektanci opracowali technikę hermetyzacji, w celu wyeliminowania konieczności dokonywania zmian w wewnętrznych protokołach sieciowych użytkowników, ( co byłoby niezbędne w przypadku łączenia różnych typów sieci). Założono, że każda sieć może korzystać z własnego protokołu komunikacyjnego. Funkcję hermetyzacji realizują routery (oryginalnie nazywane bramami (gateways)).

ˇ       Cechy TCP

§         Połączenie TCP realizowane jest w trybie full-duplex

Połączenia w TCP są realizowane w trybie full-duplex poprzez dwukierunkowe kanały wirtualne, co pozwala każdemu z systemów końcowych przesyłać dane w dowolnej chwili. W związku z tym połączenie sprawia wrażenie realizowanego poprzez dwa niezależne kanały nadawania i odbioru. Dane wysyłane i odbierane są buforowane, więc proces komunikacji nie wpływa na żadne inne procesy.

§         Odbiorca może potwierdzić odebrane datagramy (ACK)

Odbiorca może potwierdzać (acknowledge) odebranie datagramów, aby nadawca mógł być pewny, że dotarły one na miejsce.

§         Kontrola przepływu (flow control)

Kontrola przepływu daje możliwość aktywnej współpracy dwóch systemów w czasie transmisji danych i pozwala zapobiec nadmiarom i utracie datagramów, które to sytuacje powodowane są poprzez szybkich nadawców. Cecha ta pozwala systemom transmitującym szybko dostosować się do poziomu ruchu w sieci oraz/lub ustalić odpowiednią wielkość bufora u odbiorcy.

§         Porządkowanie numeracji datagramów (sequencing)

Porządkowanie jest techniką numerowania datagramów, która pozwala odbiorcy ułożyć je we właściwym porządku i ewentualnie określić brakujące elementy.

§         Generowanie sum kontrolnych (checksumming)

Generowanie sumy kontrolnej pozwala integralność pakietów.

ˇ       Segment TCP

§         Pole portu źródła I przeznaczenia

Pole to zawiera numer portu gniazd po stronie odbiorcy i nadawcy.

§         Pole numeru porządkowego

Pole to zawiera numer porządkowy stanowiący informację dla odbiorcy, identyfikujący dane zawarte w segmencie oraz ich miejsce w całym strumieniu transmitowanych danych. Odbiorca może, na podstawie tego pola, uporządkować pakiety przychodzące w przypadkowej kolejności. Możliwe jest również stwierdzenie faktu zagubienia segmentu.

§         Pole numeru potwierdzenia

Pole to jest wykorzystywane przez odbiorcę w celu poinformowania nadawcy (w wiadomości zwrotnej) o fakcie odebrania pakietu. Liczba zapisana w tym polu stanowi w rzeczywistości numer porządkowy następnego segmentu, który spodziewa się odebrać odbiorca. Wylicza się ją inkrementując wartość pola numeru porządkowego.

§         Pole długości nagłówka

§         Pole kodów

Pole to może zawierać następujące kody bitowe, służące jako flagi opisujące pewne określone sytuacje.

ACK – (Acknowledgement - potwierdzenie)

SYN – (Synchronize – synchronizuj)

URG – (Urgent – pilny)

PSH – (Push – prześlij bezpośrednio)

RST – (Reset – połącz ponownie)

FIN – (Finish – zakończ)

§         Pole rozmiaru okna przesuwnego

Pole to zawiera informacje na temat dostępnych w buforach odbiorcy przestrzeni. Pole to wykorzystywane jest przez odbiorcę w celu poinformowania nadawcy o konieczności zmniejszenia szybkości transmisji – wtedy, gdy odbiorca nie jest w stanie nadążyć z przetwarzaniem nadchodzących danych. Jeśli odbiorca chce zmusić nadawcę do zaprzestania transmisji w ogóle, w polu tym przesyła wartość 0. Gdy dalszy odbiór stanie się już możliwy, nadawca zapisuje w omawianym polu wartość różną od zera oraz – w polu numeru potwierdzenia – umieszcza numer kolejnego żądanego segmentu.

§         Pole sumy kontrolnej

Zawiera wartość używaną do kontroli wystąpienia błędów w segmencie.

§         Pole wskaźnika pilności

Pole to może być wykorzystywane przez nadawcę w celu identyfikacji miejsca umieszczenia pewnych pilnych danych w polu danych segmentu.

§         Pole opcji

Zmiennej długości pole dodatkowe przeznaczone dla opcji specjalnych.

§         Pole danych

Zmiennej długości pole przechowujące wiadomości lub dane od aplikacji.

ˇ       Nawiązywanie i przerywanie połączeń

Warstwa transportowa realizuje sesję zorientowaną na połączenie, w czasie trwania, której następuje bezbłędna transmisja danych. Sesja rozpoczyna się nawiązaniem połączenia, następnie przesyłane są dane, po czym połączenie zostaje zamknięte. Nawiązanie połączenia polega na przesłaniu żądania połączenia do hosta przeznaczenia. Jeśli realizacja połączenia jest możliwa, host odpowiada komunikatem potwierdzającym zawiązanie połączenia. Następnie oba komputery mogą ustalać parametry połączenia (parametry te mogę być ewentualnie przesłane w polu opcji segmentu TCP). Jedna ze stacji może na przykład określić – w wiadomości ustalania połączenia – maksymalną wielkość odbieranych bloków danych na 2000 bajtów. Stacja przeciwna określa tę wielkość dla siebie jako 1000 bajtów. Wartości niższa poddana, więc musi zostać negocjacjom. Również kilka innych parametrów może być negocjowanych w celu zapewnienia odpowiedniej efektywności transmisji.

W nawiązaniu połączenia stosowany jest mechanizm trzystopniowego uzgodnienia (tree-way handshake), którego przebieg jest następujący:

1. Nadawca do Odbiorcy: SYN=1 i ACK=0

            2. Odbiorca do Nadawcy: SYN=1 i ACK=1

            3. Nadawca do Odbiorcy: SYN=0 i ACK=1

            Po dokonaniu wymiany danych sesja jest zamykana:

            1. Odbiorca do Nadawcy: FIN=1 i ACK=0

            2.  Nadawca do Odbiorcy: FIN=1 i ACK=1

            3.  Odbiorca do Nadawcy: FIN=0 i ACK=1

ˇ       Rodzaje przepływu danych

§        Interaktywny przepływ danych

~ 10% wszystkich przesyłanych danych w sieci

np. : Telnet, Rlogin

~ 10 bajtów danych użytkownika w 1 segmencie

§         Przepływ danych masowych

~ 90% wszystkich przesyłanych danych w sieci

np.. : FTP, poczta elektroniczna

~ 512 bajtów danych użytkownika w 1 segmenci

2. Retransmisja w TCP

ˇ       Prosta idea retransmisji

Po fazie ustalenia połączenia obydwa komputery mogą zacząć wysyłać dane między sobą.

Nadawca wysyła pakiet z danymi do odbiorcy, włącza licznik i w ustalonym czasie (TimeOut’u) czeka na potwierdzenie odbioru pakietu od odbiorcy. Jeśli potwierdzenie nie przyjdzie w czasie ustalonego TimeOut’u od odbiorcy, nadawca retransmituje ponownie pakiet, który nie został potwierdzony, włącza licznik i ponownie zaczyna odmierzać czas (TimeOut).

TCP reguluje TimeOut na podstawie RTT, a raczej na podstawie jego przybliżonej wartości SRTT, która jest mierzona od momentu wysłania pakietu do momentu potwierdzenia jego odebrania.

SRTT[i] = (1-a) * SRTT[i-1] + a * RTT

0 < a < 1; za zwyczaj a = 1/8

RTO = 2 * SRTT - Retransmit TimeOut

ˇ       Algorytm Karna

Problem 1

TCP nie jest w stanie odróżnić ACK pakietu o tym samym numerze.

Przykład problemu

1.      Nadawca wysyła pakiet i czeka na ACK – potwierdzenie od odbiorcy, oraz mierzy czas RTT.

2.      Po upłynięciu TimeOut’u i nie otrzymaniu ACK od odbiorcy nadawca ponownie wysyła pakiet do odbiorcy i od początku zaczyna mierzyć RTT

3.      Do nadawcy dociera ACK pierwszego pakietu – nadawca nie jest w stanie odróżnić go – czas RTT zostaje błędnie oszacowany.

Rozwiązanie modyfikacji TCP – Karn’s Algorytm

1.      Nie brać pod uwagę, w obliczaniu czasu RTT, czasów pakietów retransmitowanych.

2.      Przy następnej retransmisji ustawić TimeOut dwukrotnie większy niż poprzednio.

ˇ       Algorytm Jacobsona

Problem 1 :

Sieć jest bardzo stabilna – czas RTO jest dwa razy większy od RTT, jeśli jakiś pakiet zostanie zgubiony w tym czasie – TimeOut zwiększy się dwukrotnie – długo czekamy na retransmisję.

Problem 2 :

Sieć jest bardzo niestabilna – czas RTO może mieć wartość mniejszą od RTT – pakiet jeszcze nie doszedł do odbiorcy a już został retransmitowany.

Jacobson’s Algorytm :

RTO = SRTT + u*Dev(RTT)

Dev(RTT) – odchylenie RTT

u = 4

W sytuacji dużego obciążenie sieci i dużych skoków RTT – RTO jest obliczane odpowiednio do wahań RTT, z kolei w przypadku bardzo stabilnej sytuacji czas RTO jest bardzie zbliżony do RTT niż w przypadku algorytmu Karna (RTO = 2 * SRTT)

3.  Kontrola przepływu w TCP

ˇ       Wprowadzenie

Kontrola przepływu daje możliwość aktywnej współpracy dwóch systemów w czasie transmisji danych i pozwala zapobiec nadmiarom i utracie, datagramów, które to  sytuacje powodowane są poprzez szybkich nadawców. Cecha ta pozwala systemom transmitującym szybko dostosować się do poziomu ruchu w sieci oraz/lub ustalić odpowiednią wielkość bufora u odbiorcy.

ˇ       Stop and Wait Algorytm

Jest to najprostsza metoda kontroli przepływu :

o       Nadawca wysyła pakiet i czeka na potwierdzenie odbioru w pewnym ustalonym czasie ( TimeOut )

o       Jeśli dostanie potwierdzenie przed upłynięciem tego czasu wysyła następny pakiet

o       Jeśli upłynie TimeOut wysyła ponownie pakiet i czeka na potwierdzenie od odbiorcy w pewnym określonym czasie (TimeOut)

ˇ       Sliding Window

Problem :

Algorytm Stop-And-Wait jest taktowany przez ACK (ACK-clocked), nie można wysłać kolejnego pakietu aż nie zostanie potwierdzony poprzedni.

Stosując technikę przesuwnego okna możemy wysłać kilka pakietów do odbiorcy, a on może potwierdzić w jednym ACK kilka pakietów.

Technika ta wprowadza tzw. Okno rozgłaszane to implementacji TCP - (Adwertising window) - Największa porcja danych, jaką możemy wysłać bez czekania na ACK odbiorcy 

ˇ       Slow Start Algorytm

Problem :

Sliding Window nie zna stanu sieci, która może nie wchłonąć całego okna z kilkoma pakietami.

Rozwiązaniem jest algorytm Powolnego startu

Obecnie od implementacji TCP wymaga się, aby obsługiwała algorytm powolnego startu (skow start). Działa on w sposób, że na podstawie częstości zwracanych przez drugą stronę potwierdzeń, określa częstość wysyłania do sieci nowych pakietów.

Powolny start dodaje nowe okno do protokołu TCP strony wysyłającej: okno przeciążenia (congestion window), zwane cwmd. Kiedy nawiązane jest nowe połączenie z hostem odbierającym dane np. w innej sieci, wysyłana jest informacja o oknie przeciążenia. Za każdym razem, kiedy odbierany jest ACK, okno to jest powiększane o wartość poprzedniego okna cwmd – jest to wzrost wykładniczy.

Nadawca może wysłać dane do ilości określonej jako minimum okna przeciążenia i okna rozgłaszanego.

Okno przeciążenia pozwala na kontrolę przepływu narzucona przez nadawcę, podczas gdy okno rozgłoszeniowe jest kontrolą przepływu narzucona przez odbiorcę

ˇ       Congestion-Avoidance

Problem :

Congestion window (Slow Start Algorytm) w pewnym momencie może osiągnąć górny limit możliwości routerów lub wzrośnie obciążenie sieci - pakiety zaczną być odrzucane.

Congestion Avoidance – zapobieganie powstawania zatorów – jest jednym ze sposobów poradzenia sobie z rosnącą liczbą odrzuconych pakietów. Założeniem leżące u podstaw działania algorytmu jest to, że straty pakietów spowodowane ich uszkodzeniem są niewielkie (znacznie mniejsze, niż 1%), dlatego wzrastająca liczba zagubionych pakietów świadczy o powstaniu zatoru w sieci pomiędzy źródłem a punktem przeznaczenia danych.

O zagubionych pakietach świadczy (zator):

- Przekroczenie czasu oczekiwania (TimeOut)

- Odebranie zduplikowanego ACK

Zapobieganie zatorom i powolny start są niezależnymi algorytmami, które mają różne zadania. Kiedy jednak wystąpi zator, będziemy chcieli zmniejszyć prędkość transmisji pakietów w sieci, a następnie wykonać powolny start, aby ponownie rozpocząć przesyłanie danych z optymalną prędkością. W praktyce algorytmy te stosowane są, więc razem.

Zapobieganie zatorom i powolny start wymagają mierzenia i obliczania dla każdego połączenia dwóch zmiennych : okna przeciążenia (cwmd) i progu powolnego startu (sstresh).

Zapobieganie zatorom charakteryzuje się tym, że wzrost cwmd jest wzrostem liniowym.

Opis działania algorytmu Powolnego startu i zapobiegania zatorom:

§         Inicjacja zmiennych ssthresh=65535 i cwnd=1 pakiet

§         Wysyłanie pakietów w oknie o wielkości min(cwnd, adwertised window) zwiększanie cwnd wykładniczo po każdym odebranym ACK – Slow Start

§         Kiedy wystąpi zator ssthresh= 1 * min(cwnd, adwertised window) ale minimalnie ssthresh=2 pakiety

§         Dodatkowo, jeśli zator powstał w skutek przekroczenia TimeOut cwnd=1 pakiet

§         Jeśli cwnd <= ssthresh – wykonywany jest Slow Start do momentu osiągnięcia przez cwnd połowy wartości cwnd kiedy wystapił zator – potem wykonywany jest Congestion Avoidance

§         Jeśli cwnd > ssthresh – wykonywany jest Congestion Avoidance

ˇ       Fast Retransmit Algorytm

TCP generowanie potwierdzenia (zduplikowany ACK)  kiedy zostanie naruszony porządek.

Problem :

Jeśli Nadawca odbierze zduplikowany ACK nie wie czy został on wysłany w odpowiedzi na zaginiony segment, czy też w skutek zmiany kolejności wysyłanych segmentów

Jeśli zostanie odebrany 3 lub więcej zduplikowanych ACK – wyraźny znak, że pakiet zaginął

Algorytm szybkiej retransmisji (Fast Retransmit) - jeśli zostanie odebrany 3 zduplikowany ACK, wykonywana jest retransmisja bez oczekiwania na upłynięcie TimeOut

ˇ       Fast Recowery Algorytm

Problem :

Zduplikowany ACK mówi nam więcej niż, to, że został zgubiony pakiet, – Kiedy odbiorca otrzyma pakiet naruszający porządek zapisuje go w buforze – świadczy to o tym, że między dwoma hostami nadal płyną dane i nie trzeba redukować przepływu.

Problem ten rozwiązuje się stosując algorytm szybkiego odtwarzania połączenia zamiast algorytmu powolnego startu.

W praktyce, więc algorytm szybkiej retransmisji i szybkiego odtwarzania połączenia działają razem

Opis działania algorytmu algorytm szybkiej retransmisji i szybkiego odtwarzania :

§         Kiedy odebrany zostanie trzeci zduplikowany ACK, ustaw wartość sstresh na połowę bieżącej wartości cwnd. Wykonaj retransmisję brakującego segmentu. Wartość cwmd przestaw na wartość sstresh plus 3 razy rozmiar segmentu.

§         Za każdym razem, kiedy odebrany zostanie zduplikowany ACK, powiększ cwmd o rozmiar tego segmentu i wyślij pakiet (jeśli jest to możliwe przy nowej wartości cwmd)

§         Kiedy odebrany zostanie następny ACK dotyczący nowych danych, ustaw wartość cwmd na wartość sstresh (wartość z kroku 1). Powinno to być potwierdzenie retransmisji z kroku 1, ale nadesłane po upływie RTT od momentu retransmisji. Ten segment ACK powinien również potwierdzać wszystkie segmenty pośrednie, które wysłane zostały pomiędzy zagubionym pakietem a odebraniem pierwszego zduplikowanego ACK. Ten krok jest działaniem zapobiegającym zatorom, ponieważ zwalniamy transmisję do połowy wartości, przy której nastąpiła utrata pakietu. 

4.  Porównanie implementacji TCP

ˇ        TCP Vegas

ˇ        TCP Tahoe

ˇ        TCP Reno

Wersja 4.3BSD Tahoe wykonywało Slow Start  tylko wtedy, kiedy druga strona pracowała w innej sieci. Podejście to zostało zmienione w wersji 4.3BSD Reno, które wykonywało Slow Start za każdym razem.

Algorytm Fast Retransmit pojawił się po raz pierwszy w wersji 4.3BSD Tahoe, lecz żle działał z algorytmem Slow Start.

Algorytm Fast Recovery pojawił się po raz pierwszy w wersji 4.3BSD Reno

5.  Konfiguracja stosu TCP

Rozmiar okna oferowanego przez odbiorcę może być kontrolowany przez proces obsługujący odbiór danych, co jednak może wpłynąć na wydajność TCP.

W systemie 4.2BSD domyślna wartość bufora wyjściowego i wejściowego jest 2048 bajtów. W systemie 4.3BSD obie wartości zostały zwiększone do 4096 bajtów. SunOS 4.1.3 używa wartości 4096, inne systemy takie jak Solaris 2.2, 4.4BSD używają większej wartości, takich jak 8192 lub 16384 bajty.

API gniazd pozwala procesowi ustawiać rozmiar bufora wejściowego i wyjściowego. Rozmiar bufora wejściowego jest maksymalnym rozmiarem okna, ogłoszonego dla połączenia. Niektóre aplikacje zmieniają rozmiar bufora po to, aby poprawić osiągi.

Powszechna stosowana domyślna wartość buforów w sieci Ethernet wynosi 4096 bajtów. Około 40% wzrostu przepływności można zaobserwować po zwiększeniu obu buforów do 16384 bajtów.

Można teraz odpowiedzieć na pytanie: jak duże powinno być okno ?

Wartość ta może się znacznie różnić w zależności od prędkości sieci i czasu RTT pomiędzy dwoma końcami połączenia.

Pojemność(bity) = szerokość pasma(bity/s)/ RTT (s)

Np. : Łącze T1

ˇ        szerokość pasma = 1 544 000 bity/s (przez całe USA)

ˇ        RTT = 60 ms

Co daje opóźnienie rzędu 11 580 bajtów – można zastosować bufor 16 384 bajtowy.

Np. : Łącze T3

ˇ        szerokość pasma = 45 000 000 bity/s (przez całe USA)

ˇ        RTT = 60 ms

Co daje opóźnienie rzędu 337 500 bajtów – Nie możemy zastosować 16 384 a większy bufor – stosuje się metodę skalowania okna  16 000 do 32 000