Protokół sterowania transmisją

Protokół sterowania transmisją, protokół kontroli transmisji, TCP (od ang. Transmission Control Protocol) – połączeniowy, niezawodny, strumieniowy protokół komunikacyjny stosowany do przesyłania danych między procesami uruchomionymi na różnych maszynach, będący częścią szeroko wykorzystywanego obecnie stosu TCP/IP (korzysta z usług protokołu IP do wysyłania i odbierania danych oraz ich fragmentacji wtedy, gdy jest to konieczne^[1]), jego numer porządkowy to 6(inne języki). Protokół sterowania transmisją operuje w warstwie transportowej modelu OSI. Opracowano go na podstawie badań Vintona Cerfa oraz Roberta Kahna^[1]^[2]. Został opisany w dokumencie RFC 793 ↓.

Charakterystyka protokołu

TCP jest protokołem działającym w trybie klient–serwer. Serwer oczekuje na nawiązanie połączenia na określonym porcie. Klient inicjuje połączenie do serwera.

W przeciwieństwie do UDP, TCP gwarantuje wyższym warstwom komunikacyjnym dostarczenie wszystkich pakietów w całości, z zachowaniem kolejności i bez duplikatów. Zapewnia to wiarygodne połączenie kosztem większego narzutu w postaci nagłówka i większej liczby przesyłanych pakietów. Chociaż protokół definiuje pakiet TCP, z punktu widzenia wyższej warstwy oprogramowania dane płynące połączeniem TCP należy traktować jako ciąg oktetów. W szczególności, jednemu wywołaniu funkcji interfejsu programowania aplikacji (np. send()) nie musi odpowiadać wysłanie jednego pakietu. Dane z jednego wywołania mogą zostać podzielone na kilka pakietów lub odwrotnie – dane z kilku wywołań mogą zostać połączone i wysłane jako jeden pakiet (dzięki użyciu algorytmu Nagle'a). Również funkcje odbierające dane (recv()) w praktyce odbierają nie konkretne pakiety, ale zawartość bufora stosu TCP/IP, wypełnianego sukcesywnie danymi z przychodzących pakietów.

Nawiązywanie połączenia

three-way handshake

W protokole sterowania transmisją do nawiązania połączenia między dwoma hostami stosowana jest procedura nazwana three-way handshake. W sytuacji normalnej jest rozpoczynana, gdy host A chce nawiązać połączenie z hostem B. Wygląda ona następująco^[1]:

Host A wysyła do hosta B segment SYN wraz z informacją o dolnej wartości numerów sekwencyjnych używanych do numerowania segmentów wysyłanych przez host A (np. 100), a następnie przechodzi w stan SYN-SENT.
Host B, po otrzymaniu segmentu SYN, przechodzi w stan SYN-RECEIVED i, jeżeli również chce nawiązać połączenie, wysyła hostowi A segment SYN z informacją o dolnej wartości numerów sekwencyjnych używanych do numerowania segmentów wysyłanych przez host B (np. 300) oraz segment ACK z polem numeru sekwencji ustawionym na wartość o jeden większą niż wartość pola sekwencji pierwszego segmentu SYN hosta A, czyli 101.
Host A po odebraniu segmentów SYN i ACK od hosta B przechodzi w stan ESTABLISHED i wysyła do niego segment ACK potwierdzający odebranie segmentu SYN (numer sekwencji ustawiony na 301).
Host B odbiera segment ACK i przechodzi w stan ESTABLISHED.
Host A może teraz rozpocząć przesyłanie danych.

Jeśli host odbierający połączenie nie chce lub nie może odebrać połączenia, powinien odpowiedzieć pakietem z ustawioną flagą RST (reset).

Transmisja danych

W celu weryfikacji wysyłki i odbioru TCP używa sum kontrolnych i sekwencyjnych numerów pakietów. Odbiorca potwierdza otrzymanie pakietów o określonych numerach sekwencyjnych, ustawiając flagę ACK. Brakujące pakiety są retransmitowane. Host odbierający pakiety TCP defragmentuje je i porządkuje je według numerów sekwencyjnych tak, by przekazać wyższym warstwom modelu OSI pełny złożony segment.

Zakończenie połączenia

Prawidłowe zakończenie połączenia może być zainicjowane przez dowolną stronę. Polega ono na wysłaniu pakietu z ustawioną flagą FIN (finished). Pakiet taki wymaga potwierdzenia flagą ACK. Najczęściej po otrzymaniu pakietu z flagą FIN, druga strona również kończy komunikację, wysyłając pakiet z flagami FIN i ACK. Pakiet taki również wymaga potwierdzenia przez przesłanie ACK.

Dopuszcza się również awaryjne przerwanie połączenia poprzez przesłanie pakietu z flagą RST (reset). Pakiet taki nie wymaga potwierdzenia.

Stany połączenia

Połączenie TCP może znajdować się w jednym z następujących stanów:

LISTEN: Gotowość do przyjęcia połączenia na określonym porcie przez serwer.
SYN-SENT: Pierwsza faza nawiązywania połączenia przez klienta. Wysłano pakiet z flagą SYN. Oczekiwanie na pakiet SYN+ACK.
SYN-RECEIVED: Otrzymano pakiet SYN, wysłano SYN+ACK. Trwa oczekiwanie na ACK. Połączenie jest w połowie otwarte (ang. half-open).
ESTABLISHED: Połączenie zostało prawidłowo nawiązane. Prawdopodobnie trwa transmisja.
FIN-WAIT-1: Wysłano pakiet FIN. Dane wciąż mogą być odbierane, ale wysyłanie jest już niemożliwe.
FIN-WAIT-2: Otrzymano potwierdzenie własnego pakietu FIN. Oczekuje na przesłanie FIN od serwera.
CLOSE-WAIT: Otrzymano pakiet FIN, wysłano ACK. Oczekiwanie na przesłanie własnego pakietu FIN (gdy aplikacja skończy nadawanie).
CLOSING: Połączenie jest zamykane.
LAST-ACK: Otrzymano i wysłano FIN. Trwa oczekiwanie na ostatni pakiet ACK.
TIME-WAIT: Oczekiwanie w celu upewnienia się, że druga strona otrzymała potwierdzenie rozłączenia. Zgodnie z RFC 793 ↓ połączenie może być w stanie TIME-WAIT najdłużej przez 4 minuty.
CLOSED: Połączenie jest zamknięte.

Segment TCP

TCP
Offset	Oktet	0								1								2								3
Oktet	`Bit`	`0`	`1`	`2`	`3`	`4`	`5`	`6`	`7`	`8`	`9`	`10`	`11`	`12`	`13`	`14`	`15`	`16`	`17`	`18`	`19`	`20`	`21`	`22`	`23`	`24`	`25`	`26`	`27`	`28`	`29`	`30`	`31`
0	`0`	Port nadawcy																Port odbiorcy
4	`32`	Numer sekwencyjny
8	`64`	Numer potwierdzenia (jeżeli flaga `ACK` jest ustawiona)
12	`96`	Długość nagłówka				Zarezerwowane			`N S`	`C W R`	`E C E`	`U R G`	`A C K`	`P S H`	`R S T`	`S Y N`	`F I N`	Szerokość okna
16	`128`	Suma kontrolna																Wskaźnik priorytetu (jeżeli flaga `URG` jest ustawiona)
20 ...	`160 ...`	Opcje (jeżeli długość nagłówka > 5, to pole jest uzupełniane „0”) ...

Port nadawcy – 16-bitowy numer identyfikujący port nadawcy.

Port odbiorcy – 16-bitowy numer identyfikujący port odbiorcy.

Numer sekwencyjny – 32-bitowy identyfikator określający miejsce pakietu danych w pliku przed fragmentacją (dzięki niemu, można „poskładać” plik z poszczególnych pakietów).

Numer potwierdzenia – 32-bitowy numer będący potwierdzeniem otrzymania pakietu przez odbiorcę, co pozwala na synchronizację nadawanie-potwierdzenie.

Długość nagłówka – 4-bitowa liczba, która oznacza liczbę 32-bitowych wierszy nagłówka, co jest niezbędne przy określaniu miejsca rozpoczęcia danych. Dlatego też nagłówek może mieć tylko taką długość, która jest wielokrotnością 32 bitów.

Zarezerwowane – 3-bitowy ciąg zer, zarezerwowany dla ewentualnego przyszłego użytku.

Flagi – 9-bitowa informacja/polecenie dotyczące bieżącego pakietu. Poszczególne flagi oznaczają:

NS – (ang. Nonce Sum) jednobitowa suma wartości flag ECN (ECN Echo, Congestion Window Reduced, Nonce Sum) weryfikująca ich integralność
CWR – (ang. Congestion Window Reduced) flaga potwierdzająca odebranie powiadomienia przez nadawcę, umożliwia odbiorcy zaprzestanie wysyłania echa.
ECE – (ang. ECN-Echo) flaga ustawiana przez odbiorcę w momencie otrzymania pakietu z ustawioną flagą CE
URG – informuje o istotności pola „Priorytet”
ACK – informuje o istotności pola „Numer potwierdzenia”
PSH – wymusza przesłanie pakietu
RST – resetuje połączenie (wymagane ponowne uzgodnienie sekwencji)
SYN – synchronizuje kolejne numery sekwencyjne
FIN – oznacza zakończenie przekazu danych

Szerokość okna – 16-bitowa informacja o tym, ile danych może aktualnie przyjąć odbiorca. Wartość 0 wskazuje na oczekiwanie na segment z innym numerem tego pola. Jest to mechanizm zabezpieczający komputer odbiorcy przed zbyt dużym napływem danych.

Suma kontrolna – 16-bitowa liczba, będąca wynikiem działań na bitach całego pakietu, pozwalająca na sprawdzenie tego pakietu pod względem poprawności danych. Obliczana jest z całego nagłówka TCP z wyzerowanymi polami sumy kontrolnej oraz ostatnich ośmiu pól nagłówka IP stanowiących adresy nadawcy i odbiorcy pakietu.

Wskaźnik priorytetu – 16 bitów, jeżeli flaga URG jest włączona, informuje o ważności pakietu.

Opcje – czyli ewentualne dodatkowe informacje i polecenia:

0 – koniec listy opcji
1 – brak działania
2 – ustawia maksymalna długość segmentu

W przypadku opcji 2 to tzw. Uzupełnienie, które dopełnia zerami długość segmentu do wielokrotności 32 bitów (patrz: informacja o polu „Długość nagłówka”)

Zastosowania

Aplikacje, w których zalety protokołu sterowania transmisją przeważają nad wadami (większy koszt związany z utrzymaniem sesji TCP przez stos sieciowy), to między innymi programy używające protokołów warstwy aplikacji: HTTP, SSH, FTP czy SMTP/POP3 i IMAP4.

Zobacz też

Przypisy

↑ ^a ^b ^c RFC 793 ↓.
↑ Vinton G. Cerf, Robert E. Icahn. A protocol for packet network intercommunication. „ACM SIGCOMM Computer Communication Review”. 35 (2), kwiecień 2005. ACM. DOI: 10.1145/1064413.1064423. ISSN 0146-4833.

Bibliografia

JonJ. Postel JonJ., Transmission Control Protocol, RFC 793, IETF, wrzesień 1981, DOI: 10.17487/RFC0793, ISSN 2070-1721, OCLC 943595667 (ang.).

Linki zewnętrzne

V.V. Jacobson V.V., R.R. Braden R.R., D.D. Borman D.D., TCP Extensions for High Performance, RFC 1323, IETF, maj 1992, DOI: 10.17487/RFC1323, ISSN 2070-1721, OCLC 943595667 (ang.).
Opis protokołu TCP w języku angielskim

[CITEREFRFC_793-1] RFC 793 ↓.

[2] Vinton G. Cerf, Robert E. Icahn. A protocol for packet network intercommunication. „ACM SIGCOMM Computer Communication Review”. 35 (2), kwiecień 2005. ACM. DOI: 10.1145/1064413.1064423. ISSN 0146-4833.

[1]

[2]