Sieci Komputerowe Protokół TCP Transmission Control Protocol

Sieci Komputerowe
Protokół TCP
Transmission Control Protocol
dr Zbigniew Lipiński
Instytut Matematyki i Informatyki
ul. Oleska 48
50-204 Opole
[email protected]
Zagadnienia
Protokół TCP
Transmisja strumieniowa
Niezawodność TCP
Opis Segmentu TCP
Przykład segmentu TCP (TCP Connect Request Telnetu)
Struktura nagłówka segmentu TCP
Porty i połączenia TCP
Aplikacje i protokoły korzystające z TCP
Mechanizm przesuwających się okien
Przesyłanie z użyciem buforów
2
Protokół TCP
TCP, ang. Transmission Control Protocol.
RFC 793, J. Postel, Transmission Control Protocol, 1981.
RFC 813, David D. Clark, WINDOW AND ACKNOWLEDGEMENT STRATEGY IN TCP, 1982.
RFC-896, J. Nagle, Congestion Control in IP/TCP, January 1984.
RFC 1122, R. Braden, Requirements for Internet Hosts - Communication Layers, 1989.
RFC 3168, K. Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, 2001.
RFC 2474, K. Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers, 1998.
RFC 4379, K. Kompella, G. Swallow, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures, 2006.
RFC 6093, F. Gont, A. Yourtchenko, On the Implementation of the TCP Urgent Mechanism, 2011.
RFC 6528, F. Gont, S. Bellovin, Defending against Sequence Number Attacks, 2012.
V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM-88, 1988.
P. Karn, C. Partridge, Round Trip Time Estimation, ACM SIGCOMM-87, 1987.
3
Protokół połączeniowy
TCP jest protokołem warstwy transportowej modelu OSI.
Pakiet danych TCP nazywa się segmentem, RFC 793, 1122.
Protokół TCP jest protokołem połączeniowym umożliwiającym wykrywanie błędów transmisji.
Cechy protokołu TCP:
•
stosuje pozytywne potwierdzanie odbioru danych (pole ACK=1),
•
ma możliwość ustalania priorytetu przesyłania segmentów,
•
ma możliwość kontroli i usuwania błędów (retransmisji niepotwierdzonych pakietów).
4
Protokół połączeniowy
Proces trasmisji składa się z trzech etapów:
•
budowa połączenia,
•
przesyłanie danych,
•
zamknięcie połączenia.
Budowa połączenia polega na:
•
lokalizacji odbiorcy,
•
ustaleniu parametrów połączenia.
Połączenie to logiczna ścieżka transmisji między dwoma gniazdami (RFC 793).
Połączenie TCP to zbiór parametrów (RFC 793):
•
numer portu, adres IP odbiorcy
(pola: Source port, Source Address)
•
numer portu, adres IP nadawcy
(pola: Destination port, Destination Address)
•
kolejny numer wysłanego segmentu (pole: Sequence number)
•
wielkość okna
(pole: Window).
5
Transmisja strumieniowa
W transmisji wykorzystującej protokół TCP między nadawcą a odbiorcą wymieniany jest strumień bajtów.
Protokół TCP nie umieszcza znaczników początku i końca danych, usługa strumienia bajtów (byte stream service).
Jeśli nadawca wyśle kolejno 100 bajtów, 200, 300 bajtów to odbiorca nie wie jakiej
wielkości segmenty były wysłane. Do odbiorcy dane mogą dotrzeć w 4 segmentach po 150 bajtów każdy.
Nadawca wysyła strumień danych i odbiorca odbiera strumień danych.
6
Niezawodność TCP
Protokół TCP umożliwia weryfikację czy transmitowane dane są:
•
uszkodzone,
•
zgubione,
•
powielone,
•
dostarczone w nieodpowiedniej kolejności do odbiorcy.
W celu zapewnienia niezawodności transmisji:
•
każdy wysłany segment danych TCP jest numerowany,
•
każdy segment TCP potwierdzający odbiór jest numerowany,
•
protokół wykorzystuje mechanizm pozytywnego potwierdzenia odbioru danych z retransmisją
PAR, (ang.) Positive Acknowledgment with Re-transmission.
7
Pozytywne potwierdzanie z retransmisją (PAR)
Protokół TCP stosuje mechanizm 'pozytywnego potwierdzania z retransmisją’, tzn. potwierdzany jest poprawny odbiór
danych.
Nadawca po wysłaniu segmentu TCP, uruchamia zegar mierząc czas oczekiwania na potwierdzenie odbioru.
Po odebraniu segmentu TCP odbiorca wysyła pakiet w którym flaga ACK = 1.
Nadawca wysyła ponownie segment jeżeli:
•
zostanie przesłany komunikat z wartością pola ACK=0 (brak pozytywnego potwierdzenia),
•
po określonym czasie nie nadejdzie potwierdzenie prawidłowego obioru danych.
Odbiorca po prawidłowym odebraniu segmentu TCP wysyła potwierdzenie odbioru do nadawcy.
Jeżeli potwierdzenie nie nadejdzie w określonym czasie, nadawca wysyła segment ponownie.
Pakiet jest wysyłany tak długo dopóki nadawca nie otrzyma potwierdzenia o bezbłędnie odebraniu pakietu.
8
Przykład. Pozytywne potwierdzenie odbioru danych.
# ----- Naglowek Ethernetowy ----Packet 7 arrived at 17:37:24.00
Packet size = 60 bytes
Destination = 8:0:20:86:35:4b, Sun
Source
= 0:e0:f7:26:3f:e9, CISCO Router
Ethertype = 0800 (IP)
# ----- Naglowek IP ----Version = 4
Header length = 20 bytes
Type of service = 0x00 (normal)
Total length = 40 bytes
Identification = 43773
Flags = 0x0
.0.. .... = may fragment
..0. .... = last fragment
Fragment offset = 0 bytes
Time to live = 252 seconds/hops
Protocol = 6 (TCP)
Header checksum = 3a56
Source address = 150.168.233.2,
server.math.edu.pl
Destination address = 150.168.27.110, client
No options
# ----- Naglowek TCP ----Source port = 23
Destination port = 36869
Sequence number = 2486243368
Acknowledgement number = 1913975089
Data offset = 20 bytes
Flags = 0x10
..0. .... = No urgent pointer
...1 .... = Acknowledgement
.... 0... = No push
.... .0.. = No reset
.... ..0. = No Syn
.... ...0 = No Fin
Window = 8760
Checksum = 0x1c65
Urgent pointer = 0
No options
9
Numerowanie bajtów w segmentach TCP
Do numerowania wysłanych bajtów danych i informowania o liczbie bezbłędnie odebranych bajtów danych nadawca i
odbiorca wykorzystują pola 'Sequence number' i Acknowledgement number w nagłówku protokołu TCP.
Pole 'Sequence number' zawiera liczbę ISN + N, gdzie N jest liczbą wysłanych bajtów, przy czym numeruje się pierwszy
bajt danych w przesłanym segmencie.
Segmenty TCP są kapsułkowane w warstwie sieci w datagramy IP. Protokół IP jest protokołem bezpołączeniowym bez
obsługi błędów dlatego, datagramy IP mogą nie dotrzeć do odbiorcy lub dotrzeć w rożnej kolejności. Pole 'Sequence
number‘ pozwala sprawdzić czy jakiś segment TCP nie zaginął, służy również do uporządkowania odebranego
strumienia danych we właściwej kolejności.
Obiorca wysyła pakiet z flagą ACK = 1 (pakiety potwierdzające prawidłowy odbiór danych) wykorzystuje pole Numer
potwierdzenia (Acknowledgement number) do poinformowania nadawcy o liczbie prawidłowo odebranych bajtów i o
spodziewanej wartości w polu 'Sequence number‘.
10
Suma kontrolna w nagłówku segmentu TCP
Mechanizm sum kontrolnych służy zapewnieniu integralności danych podczas transmisji.
Nagłówek protokołu TCP zawiera pole 'Checksum'.
Wartość pola jest liczbą 16-bitowych słów w pseudonagłówku, nagłówku i polu 'dane'.
Jeżeli segment zostanie nadesłany z niepoprawną sumą kontrolną, odbiorca porzuca go i nie wysyła potwierdza odbioru.
11
Sterowanie szybkością transmisji
Pole 'Window' w nagłówku segmentu TCP służy do informowania nadawcy ile bajtów może odebrać odbiorca.
Zmieniając wartość w polu 'Window' odbiorca może określać wielkość/liczbę wysyłanych segmentów.
Np. wysłany segment TCP z wartością pola 'Window = 0' wstrzymuje transmisję.
Jeżeli odległość między nadawcą a odbiorcą jest duża, liczona liczbą routerów, i są możliwe opóźnienia w transmisji,
odbiorca danych stopniowo zwiększa wartość pola 'Window ‘ – stosuje mechanizm ‘slow start’.
Algorytm TCP slow start stosowany przez protokół TCP ma na celu określenie optymalnej wartości dla pola ‘Window’, gdy
nadawca i odbiorca znajdują się w różnych sieciach (segmentach sieci), RFC 2001.
W segmentach TCP nadawcy i odbiorcy wartość w polu ‘Window’ może być różna.
12
Psedonagłówek TCP
Pseudonagłówek poprzedza nagłówek segmentu TCP (RFC 793).
Wilekość pseudonagłówka 12 bajtów (96 bitów).
Pole:
Adres nadawcy. Wielkość pola: 32 bity. Pole określa adres IP nadawcy.
Pole:
Adres odbiorcy. Wielkość pola: 32 bity. Pole określa adres IP odbiorcy.
Pole:
Zero
Pole:
Protokół. Wielkość pola: 8 bitów. Pole określa typ protokołu. Wartość: 6 oznacza TCP.
Pole:
Długość TCP. Wielkość pola: 16 bitów. Liczba bajtów w nagłówku i polu dane segmentu TCP.
W polu nie uwzględnia się wielkości pseudonagłówka.
Pole ‘długość TCP’ nie jest przesyłane w pakietach. W nagłówku datagramu IP po polu ‘Protokół’ jest pole
‘Suma kontrolna nagłówka’.
Bity
1-4
5-8
Zero
9-12
13-16
17-20
Source Address
Destination Address
Protocol
21-24
25-28
29-32
TCP Length
Pseudonagłówek TCP
13
Pola w nagłówku segmentu TCP
Pole:
Port źródłowy (Source port). Wielkość pola: 16 bitów.
1-4
5-8
9-10
11-12
Bity
13-16
17-20
Source port
Pole:
Port docelowy (Destination port). Wielkość pola: 16 bitów.
Pola zawierają numery portów aplikacji wymieniających dane.
21-24
25-28
Destination port
Sequence number
Acknowledgement number
Data
offset
Not used
Checksum
Flags
Options
Window
Urgent pointer
Padding
Data …
Pole:
Kolejny numer (Sequence number). Wielkość pola: 32 bity.
Struktura segmentu TCP
Numer pierwszego bajtu przesyłanych danych w segmencie liczony od początku transmisji.
Przy nawiązywaniu połączenia, gdy pole SYN= 1, w polu 'kolejny numer' jest wpisywany początkowy
numer ISN od którego rozpoczęta będzie numeracja przesyłanych segmentów (pierwszy wysłany bajt danych
ma numer ISN + 1).
Liczba ISN jest generowana losowo z gwarancją niepowtórzenia się w sieci przez około 4.55 godz..
Pole:
Numer potwierdzenia (Acknowledgement number).
Wielkość pola: 32 bity.
Jeśli flaga ACK = 1, to pole 'numer potwierdzenia' zawiera oczekiwaną wartość w polu 'kolejny numer‘ .
Pole:
Długość nagłówka (Data offset). Wielkość pola: 4 bity.
Wartość w polu określa liczbę 32-bitowych słów w nagłówku TCP. Pole pozwala określić początek bitów z
danymi.
Pole:
Pole nieużywane. Wielkość pola: 6 bitów.
Pole jest przeznaczone dla przyszłych zastosowań.
14
29-32
Pola w nagłówku segmentu TCP
1-4
Pole:
5-8
Atrybuty pola flagi: UGR, ACK, PSH, RST, SYN, FIN.
11-12
Bity
13-16
17-20
Source port
Flagi, (Flags). Wielkość pola: 6 bitów.
Pole zawiera parametry określające tryb transmisji.
9-10
21-24
25-28
Destination port
Sequence number
Acknowledgement number
Data
offset
Wartości atrybutów pola flagi: 0,1.
UGR - wskaźnik pilności
ACK - określa ważność pola numer potwierdzania.
Not used
Checksum
Flags
Options
Window
Urgent pointer
Padding
Data …
Struktura segmentu TCP
PSH - wskazuje na zastosowanie funkcji wymuszającej.
RST - wyzerowanie połączenia (dla wartości 1 oznacza polecenie zerowania połączenia).
SYN - wskazuje, że w polu 'kolejny numer' umieszczony jest inicjujący numer INS. Wartość 0
nowe połączenie.
oznacza
FIN - wartość 1 oznacza koniec połączenia.
Pole:
Okno, (Window). Wielkość pola: 16 bitów.
Pole służy do sterowania transmisją danych.
Pole określa liczbę bajtów jaką może jeszcze odebrać odbiorca (wielkość bufora odbiorcy).
Pole 'Okno' o wartości zero, oznacza, ze nadawca powinien wstrzymać transmisje, dopóki nie otrzyma
potwierdzenia z niezerowa wartością pola.
15
29-32
Pola w nagłówku segmentu TCP
Pole:
Suma kontrolna (Checksum). Wielkość pola: 16 bitów.
Suma kontrolna jest liczbą 16-bitowych słów w pseudonagłówku (12 bajtów), nagłówku i polu dane
segmentu TCP .
Jeżeli liczba bajtów jest nieparzysta to dodawany jest bajt zer w polu dane tak, aby suma kontrolna
była liczona dla 16-bitowych słów. Dodany bajt zer w polu dane nie jest transmitowany.
Pole:
Priorytet (Urgent pointer). Wielkość pola: 16 bitów.
Pole określa pilności przesyłanego segmentu, jest interpretowane tylko wtedy, gdy flaga 'UGR' ma wartość 1.
Pole zawiera kolejny numer bajtu następującego po pilnych danych.
Pole:
Opcje (Options). Wielkość pola: zmienna, wielokrotność 8 bitów.
Pole zawiera numery opcji, każdy numer zapisany w jednym bajcie.
Dla protokołu TCP zdefiniowano trzy opcje:
0 - koniec listy opcji
1 - brak działania
1-4
5-8
9-10
11-12
Bity
13-16
17-20
21-24
25-28
29-32
2 - maksymalna długość segmentu.
Source port
Destination port
Sequence number
Acknowledgement number
Data
offset
Not used
Checksum
Flags
Options
Window
Urgent pointer
Padding
Data …
Struktura segmentu TCP
16
Pola w nagłówku segmentu TCP
Pole:
Uzupełnienie (Padding). Wielkość pola: zmienna.
Pole zawiera uzupełnienia zerami nagłówka TCP do wielkości 32 bitów.
Pole:
Dane (Data). Wielkość pola: zmienna.
Pole zawiera dane aplikacji.
1-4
5-8
9-10
11-12
Bity
13-16
17-20
Source port
21-24
25-28
29-32
Destination port
Sequence number
Acknowledgement number
Data
offset
Not used
Checksum
Flags
Options
Window
Urgent pointer
Padding
Data …
Struktura segmentu TCP
17
Budowa połączenia TCP
W procesie synchronizacji 'połączenia TCP' między nadawcą (A) i odbiorcą (B) wymieniane są trzy segmenty TCP.
Proces uzgadniania wartości w polach 'Sequence number‘, ‘Acknowledgement number w wysyłanych i potwierdzanych
pakietach (RFC 793).
(1) A ----> B flaga ACK=0,
SYN=1
(2) A <---- B flagi ACK=1,
SYN=1
pole ‘Sequence number=X’, ISN nadawcy (A),
Np. X=100
pole ‘Sequence number=Y’, ISN odbiorcy (B),
pole ‘Acknowledgement number=X+1’
Np. SeqNumber=Y = 300, AckNumber = X+1 = 101
Uwaga: B spodziewa się, że w następnym segmencie A w polu Seq. Number wpisze
wartość X+1=101.
(3) A ----> B flaga ACK=1
SYN=0
pole ‘Acknowledgement number=Y+1,
Np. SeqNumber=X+1=101, AckNumber=Y+1=301
18
Synchronizacja numeracji segmentów
Uzgadnionie wartości w polu Sequence number (Kolejny numer) jest wymagana ponieważ, wartości początkowe ISN (initial
sequence number) są wyliczane na podstawie lokalnego czasu nadawcy i odbiorcy.
Maximum Segment Lifetime (MSL) w sieci dla segmentów TCP wynosi 2 minuty (RFC 793).
Każdy przesłany bajt ma swój ‘sequence number’.
Mechanizm potwierdzania pakietów jest przyrostowy, tzn. potwierdzenie odebrania bajtu o numerze X (wartość w polu
‘sequence number’=X), oznacza, że potwierdzony jest odbiór strumienia X bajtów.
19
Przykład segmentu TCP
# ----- naglowek ethernetowy -----
# ----- naglowek TCP -----
Packet 10 arrived at 12:35:32.17
Source port = 23
Packet size = 69 bytes
Destination port = 36869
Destination = 8:0:20:85:55:4b, Sun
Sequence number = 2486243368
Source
= 0:e0:f7:22:3f:d9, CISCO Router
Ethertype = 0800 (IP)
# ----- naglowek IP ----Version = 4
Header length = 20 bytes
Acknowledgement number = 1913975089
Data offset = 20 bytes
Flags = 0x18
..0. .... = No urgent pointer
Type of service = 0x00 (normal)
...1 .... = Acknowledgement
Total length = 55 bytes
.... 1... = Push
Identification = 43775
.... .0.. = No reset
Flags = 0x0
.... ..0. = No Syn
.0.. .... = may fragment
.... ...0 = No Fin
..0. .... = last fragment
Window = 8760
Fragment offset = 0 bytes
Checksum = 0xc10c
Time to live = 252 seconds/hops
Urgent pointer = 0
Protocol = 6 (TCP)
No options
Header checksum = 3a45
Source address = 152.148.13.32,
server.math.edu.pl
# ----- dane aplikacji TELNET: ----dane
Destination address = 155.181.171.109, client
No options
20
Porty i połączenia TCP
Aby dane trafiły do odpowiednich aplikacji uruchomionych na danym hoscie protokół TCP numeruje połączenia.
Każdemu połączeniu aplikacja przypisuje liczbę, port TCP, z przedziału 1 - 65355.
Gniazdo internetowe TCP, (ang.) TCP internet socket, to adres IP hosta, numeru portu, wartość pola typ portu = TCP.
Aplikacja która chce przesłać dane musi zbudować połączenie:
•
odnaleźć odbiorcę
•
wysłać komunikat z zadaniem budowy połączenia.
Zarezerwowane numery portów dla 'dobrze znanych aplikacji' sieciowych służą serwerom aplikacji do nasłuchiwania
żądań usługi przez klientów aplikacji.
Protokoły korzystające w warstwie transportowej z TCP:
ftp,
porty: 20, 21
ssh,
port: 22
telnet,
port: 23
SMTP,
port: 25
kerberos,
porty: 88, 464, 749
21
Transmisja danych między klientem a serwerem HTTP
Pobieranie pliku 192 kB ze strony WWW. Pole Wielkość okna = 64240 bajtów
K->S HTTP seq: 2428465110 ack: 404447982
S->K TCP seq: 404447982 ack: 2428466109
S->K TCP seq: 404449442 ack: 2428466109
S wysłał do K 1460 B
K->S TCP seq: 2428466109 ack: 404450902
S->K TCP seq: 404450902 ack: 2428466109
S->K TCP seq: 404452362 ack: 2428466109
S wysłał do K 1460 B
K->S TCP seq: 2428466109 ack: 404453822
S->K TCP seq: 404453822 ack: 2428466109
S->K TCP seq: 404455282 ack: 2428466109
S wysłał do K 1460 B
K->S TCP seq: 2428466109 ack: 404456742
S->K TCP seq: 404456742 ack: 2428466109
S->K TCP seq: 404458202 ack: 2428466109
S wysłał do K 1460 B
...
S->K TCP seq: 404643622 ack: 2428466109
S->K HTTP seq: 404645082 ack: 2428466109
K->S TCP seq: 2428466109 ack: 404645384
K->S TCP seq: 404645384 ack: 2428466109 (FIN=1)
Liczba odebranych bajtów: 404645082 - 404447982 = 19 7100
22
Czas retransmisji segmentów TCP
Czas RTO (retransmission timeout) to czas po którym następuje retransmisja segmentu TCP.
Czas retransmisji jest obliczany dynamicznie dla każdego segmentu TCP.
Czas RTT (Round Trip Time) to czas jaki upłynął od wysłania segmentu z danym numerem sekwencyjnym (pole
Seq.Number) do odebrania segmentu potwierdzenia.
Występowanie retransmisji segmentów TCP powoduje:
•
problemy z wyliczeniem czasu RTT,
•
problemy z wyliczeniem średniego czasu RTT (czasu SRTT), ponieważ są zbyt duże odchylenia od kolejnych
wartości czasu RTT.
23
Algorytm Jacobson’a, algorytm Karn’a
RFC 1122, R. Braden, Requirements for Internet Hosts - Communication Layers, 1989.
Do wyznaczania czasu retransmisji segmentów TCP (czasu RTT) aplikacje muszą stosować:
•
algorytm Jacobson’a, służący do wyliczania średniego czasu RTT (SRTT - Smoothed Round Trip Time),
•
algorytm Karn’a, służący do wyboru takich czasów RTT, aby nie spowodowały blokady algorytmu wyznaczającego
czas średni (czas SRTT).
V. Jacobson, Congestion Avoidance and Control , ACM SIGCOMM-88, 1988.
P. Karn, C. Partridge, Round Trip Time Estimation, ACM SIGCOMM-87, 1987.
24
Czas RTT, czas SRTT
Dla ciągu czasów
RTTi
, i=1,2,… jaki upłynął między wysłaniem a odebraniem sekwencji pakietów i=1,2,…
wylicza się czas SRTT (Smoothed Round Trip Time, średni czas RTT), na podstawie wzoru
SRTTi +1 ← α ∗ SRTTi + (1 − α ) ∗ RTTi
α współczynnik określający szybkość zmian SRTT, ma wartości między (0,1), np. 0.9.
Czas RTO (retransmission timeout) i-tego segementu TCP obliczany jest ze wzoru
RTOi = β ∗ RTTi
β
współczynnik opóźnienia (delay variance factor), stosowane wartości z zakresu 1.3 – 2.0.
25