Sieci Komputerowe Protokół TCP

Sieci Komputerowe Protokół TCP Transmission Control Protocol dr Zbigniew Lipiński Instytut Matematyki i Informatyki ul. Oleska 48 50-204 Opole zlipinski@math.uni.opole.pl

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). Adres nadawcy. Wielkość pola: 32 bity. Pole określa adres IP nadawcy. Adres odbiorcy. Wielkość pola: 32 bity. Pole określa adres IP odbiorcy. Zero Protokół. Wielkość pola: 8 bitów. Pole określa typ protokołu. Wartość: 6 oznacza TCP. 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 9-12 13-16 17-20 21-24 25-28 29-32 Source Address Destination Address Zero Protocol TCP Length Pseudonagłówek TCP 13

Pola w nagłówku segmentu TCP Port źródłowy (Source port). Wielkość pola: 16 bitów. Port docelowy (Destination port). Wielkość pola: 16 bitów. Pola zawierają numery portów aplikacji wymieniających dane. Kolejny numer (Sequence number). Wielkość pola: 32 bity. Bity 1-4 5-8 9-10 11-12 13-16 17-20 21-24 25-28 29-32 Source port Destination port Sequence number Acknowledgement number Data offset Not used Flags Window Checksum Urgent pointer Options Padding Data 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.. Numer potwierdzenia (Acknowledgement number). Wielkość pola: 32 bity. Jeśli flaga ACK = 1, to pole 'numer potwierdzenia' zawiera oczekiwaną wartość w polu 'kolejny numer. 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 nieużywane. Wielkość pola: 6 bitów. Pole jest przeznaczone dla przyszłych zastosowań. 14

Pola w nagłówku segmentu TCP Bity 1-4 5-8 9-10 11-12 13-16 17-20 21-24 25-28 29-32 Flagi, (Flags). Wielkość pola: 6 bitów. Pole zawiera parametry określające tryb transmisji. Atrybuty pola flagi: UGR, ACK, PSH, RST, SYN, FIN. Wartości atrybutów pola flagi: 0,1. UGR - wskaźnik pilności ACK - określa ważność pola numer potwierdzania. PSH - wskazuje na zastosowanie funkcji wymuszającej. Source port Destination port Sequence number Acknowledgement number Data offset Not used Flags Window Checksum Urgent pointer Options Padding Data Struktura segmentu TCP 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. FIN - wartość 1 oznacza koniec połączenia. oznacza 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

Pola w nagłówku segmentu TCP 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. 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. 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 2 - maksymalna długość segmentu. Bity 1-4 5-8 9-10 11-12 13-16 17-20 21-24 25-28 29-32 Source port Destination port Sequence number Acknowledgement number Data offset Not used Flags Window Checksum Urgent pointer Options Padding Data Struktura segmentu TCP 16

Pola w nagłówku segmentu TCP Uzupełnienie (Padding). Wielkość pola: zmienna. Pole zawiera uzupełnienia zerami nagłówka TCP do wielkości 32 bitów. Dane (Data). Wielkość pola: zmienna. Pole zawiera dane aplikacji. Bity 1-4 5-8 9-10 11-12 13-16 17-20 21-24 25-28 29-32 Data offset Options Source port Sequence number Acknowledgement number Destination port Not used Flags Window Checksum 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, pole Sequence number=x, ISN nadawcy (A), SYN=1 Np. X=100 (2) A <---- B flagi ACK=1, pole Sequence number=y, ISN odbiorcy (B), SYN=1 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 pole Acknowledgement number=y+1, SYN=0 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 ----- Packet 10 arrived at 12:35:32.17 Packet size = 69 bytes Destination = 8:0:20:85:55:4b, Sun Source = 0:e0:f7:22:3f:d9, CISCO Router Ethertype = 0800 (IP) # ----- naglowek IP ----- Version = 4 Header length = 20 bytes Type of service = 0x00 (normal) Total length = 55 bytes Identification = 43775 Flags = 0x0.0..... = may fragment..0.... = last fragment Fragment offset = 0 bytes Time to live = 252 seconds/hops Protocol = 6 (TCP) Header checksum = 3a45 Source address = 152.148.13.32, server.math.edu.pl Destination address = 155.181.171.109, client No options # ----- naglowek TCP ----- Source port = 23 Destination port = 36869 Sequence number = 2486243368 Acknowledgement number = 1913975089 Data offset = 20 bytes Flags = 0x18..0.... = No urgent pointer...1... = Acknowledgement... 1... = Push....0.. = No reset.....0. = No Syn......0 = No Fin Window = 8760 Checksum = 0xc10c Urgent pointer = 0 No options # ----- dane aplikacji TELNET: ----- dane 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 RTT i Dla ciągu czasów, 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 SRTT i+ 1 α SRTTi + (1 α ) RTT i α 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 = β RTT i współczynnik opóźnienia (delay variance factor), stosowane wartości z zakresu 1.3 2.0. 25