Transmission Control Protocol

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

Transmission Control Protocol (TCP) – połączeniowy, niezawodny, strumieniowy protokół komunikacyjny wykorzystywany do przesyłania danych pomię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]. Protokół TCP operuje w warstwie transportowej modelu OSI. Opracowano go na podstawie badań Vintona Cerfa oraz Roberta Kahna[1][2]. Został opisany w dokumencie RFC793.

Charakterystyka protokołu[edytuj | edytuj kod]

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, to 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 API (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[edytuj | edytuj kod]

three-way handshake

W protokole TCP do nawiązania połączenia pomiędzy dwoma hostami wykorzystywana jest procedura nazwana three-way handshake. W sytuacji normalnej jest ona rozpoczynana, gdy host A chce nawiązać połączenie z hostem B, procedura wygląda 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[edytuj | edytuj kod]

W celu weryfikacji wysyłki i odbioru TCP wykorzystuje sumy kontrolne i numery sekwencyjne 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łen złożony segment.

Zakończenie połączenia[edytuj | edytuj kod]

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[edytuj | edytuj kod]

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.

Nagłówek TCP[edytuj | edytuj kod]

TCP Header
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 nadawcy 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.

Wskaźnik priorytetu – 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[edytuj | edytuj kod]

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

Zobacz też[edytuj | edytuj kod]

Przypisy

  1. 1,0 1,1 1,2 RFC - Transmission Control Protocol (ang.). [dostęp 2011-10-21].
  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. 

Linki zewnętrzne[edytuj | edytuj kod]