TCP: protokół kontroli transmisji. Co to? Jak działa?

Czym jest protokół kontroli transmisji (TCP)? Jak działa? Wyjaśnienie procesu, stany połączenia, zastosowania i różnice względem UDP.

Spis treści

Czym jest TCP, czyli protokół sterowania transmisją? Poznaj jego charakterystykę i dowiedz się, w jaki sposób działa, krok po kroku. Odkryj jego zastosowanie i poznaj różnice między nim i protokołem UDP.

TCP znany jest pod różnymi nazwami. Najczęściej określany jest jako protokół kontroli transmisji lub protokół sterowania transmisją. Niezależnie od nazwy, pełni niezwykle istotną funkcję w świecie internetu. Jest przy tym również zagadnieniem dość zaawansowanym technicznie. To sprawia, że z jego istnienia nawet nie zdaje sobie sprawy wielu właścicieli stron internetowych, a tym bardziej przeciętnych internautów.

Jaka jest rola protokołu TCP w procesie przesyłania danych i czym się on charakteryzuje? W tym artykule znajdziesz wszystkie najważniejsze informacje na temat tego rozwiązania. Poznasz cały proces jego działania, od nawiązania połączenia, przez transmisję danych, aż po jej zakończenie. Co więcej, odkryjesz wszystkie najpopularniejsze zastosowania TCP i dowiesz się, czym różni się od niego protokół UDP.

Co to jest protokół TCP (Transmission Control Protocol)?

Protokół TCP (ang. Transmission Control Protocol) jest wykorzystywany do przesyłania danych między różnymi maszynami. To protokół połączeniowy i strumieniowy, uznawany powszechnie za rozwiązanie niezawodne. Umożliwia transfer informacji między odrębnymi procesami, a jest częścią powszechnie wykorzystywanego stosu TCP/IP. Nazwa ta związana jest z faktem, że to protokół najczęściej stosowany na szczycie IP.

Do odbierania oraz przesyłania plików wykorzystuje usługi protokołu IP. Co więcej, pozwala na fragmentację transferowanych danych, gdy zachodzi taka konieczność. TCP jest ceniony ze względu na obsługę licznych mechanizmów stanowiących odpowiedź na różnorodne problemy występujące podczas przesyłania wiadomości opartych na pakietach. Mowa w tym przypadku m.in. o:

utraconych pakietach,
zduplikowanych pakietach,
pakietach występujących poza kolejnością,
uszkodzonych pakietach.

Protokół TCP operuje w warstwie transportowej modelu OSI. Działa w trybie klient-serwer WWW. Ten ostatni oczekuje na nawiązanie połączenia w kreślonym porcie, podczas gdy klient inicjuje połączenie.

Charakterystyczną cechą protokołu TCP jest fakt, że gwarantuje on dostarczanie pakietów danych w całości. Zachowuje przy tym ich kolejność i nie grozi stworzeniem duplikatów. Dzięki temu realizowane połączenie i transfer cechuje najwyższy poziom wiarygodności. Odbywa się to jednak kosztem większej liczby przesyłanych pakietów, a także większego narzutu (nagłówek TCP). Ostatecznie zatem TCP nie cechuje się zbyt dużą szybkością działania.

Charakterystyka TCP

Wyższa warstwa aplikacji (oprogramowania) postrzega dane transferowane przy użyciu TCP jako ciąg oktetów. Mowa tu o 8-bitowej jednostce informacji. Nie przeszkadza w tym definiowanie protokołu przez pakiet TCP. Pojedyncze wywołanie funkcji interfejsu programowania aplikacji nie musi zatem odpowiadać wysłanie pojedynczego pakietu.

Pochodzące z wywołania dane mogą ostatecznie zostać podzielone na dwa i więcej pakietów. Alternatywnie również, dane przesyłane w kilku wywołaniach mogą zostać połączone i transferowane jako jeden pakiet. Co w takiej sytuacji dzieje się z funkcjami odbierającymi dane (recv())? Odbierając informacje, nie traktują ich jako konkretne pakiety, a jako zawartość bufora stosu TCP/IP. Jest on z kolei wypełniany danymi pochodzącymi z kolejnych, przyjmowanych pakietów.

HTTP 1.1, HTTP/2 i HTTP/3 a protokół TCP

Urządzenia sieciowe, działające w oparciu o HTTP 1.1, korzystają z protokołu TCP podczas realizacji transferów. Nie jest to jednak rozwiązanie polecane, przede wszystkim ze względu na liczne ograniczenia. Największym problemem w tym przypadku jest konieczność otrzymania potwierdzenia każdego żądania w protokole TCP.

To z kolei przekłada się na każdorazowe oczekiwanie i prowadzi do tzw. blokowania nagłówka. Mowa tu o sytuacji, w której procesy są wstrzymywane, dopóki każde z żądań nie zostanie potwierdzone. Ostatecznie zatem dochodzi do opóźnień warstwy transportowej, bo realizacja transferów nie odbywa się równolegle.

Odpowiedzią na problemy HTTP 1.1 korzystającego z protokołu TCP jest HTTP/2. Jego najważniejszą cechą jest możliwość wykorzystania z multipleksowania. Pozwala to bowiem na zniwelowanie opisanych powyżej opóźnień. Dodatkowo wykorzystanie protokołu SPDY (zaawansowanego rozwinięcia TCP) odpowiada za opcję procesowania kilku zapytań jednocześnie. W ten sposób przesyłanie danych odbywa się szybciej, choć i tak nie jest bez wad.

HTTP/2 eliminuje blokowanie nagłówka, ale nadal może wymagać przeprowadzenia retransmisji. Dotyczy to szczególnie sytuacji, gdy jeden z pakietów danych się zgubi lub wywoła błąd. Prace nad usunięciem tego problemu wprawdzie się rozpoczęły, w międzyczasie jednak doszło do rozpoczęcia implementacji nowej wersji protokołu – HTTP/3. Ta natomiast opiera się na ulepszonej wersji protokołu HTTP, czyli QUIC. On korzysta już ze znacznie szybszego rozwiązania, jakim jest protokół UDP. Porównamy go z TCP w dalszej części tekstu.

Jak działa protokół TCP? Wyjaśnienie procesu krok po kroku

Wiesz już, jak wykorzystywany jest protokół TCP w komunikacji z komputerami w innej sieci. Czas więc przyjrzeć się bliżej samemu procesowi, za pomocą którego komputer w internecie może wysłać i odebrać informacje z innego urządzenia. Poniżej omówiliśmy ten proces krok po kroku.

Nawiązywanie połączenia

W protokole sterowania transmisją wykorzystywana jest procedura nazywana trójstronnym uściskiem dłoni (ang. three-way handshake). Dzięki niej możliwe jest nawiązanie połączenia między urządzeniami nadawcy oraz odbiorcy. W większości przypadków rozpoczyna się ona w chwili, gdy host nadający (nazwijmy go „host A”) inicjuje chęć nawiązania połączenia z hostem odbierającym (nazwijmy go „host B”). Cały ten proces można przedstawić w kilku punktach:

host A wysyła segment SYN do hosta B. Wraz z nim transmitowana jest informacja o numerach sekwencyjnych o dolnej wartości. Są one wykorzystywane przez host A do numerowania przesyłanych segmentów. Następnie przechodzi on w stan SYN-SENT;
host odbierający (host B) otrzymuje segment SYN i przechodzi w stan SYN-RECEIVED. Jeśli chce nawiązać połączenie, wysyła w odpowiedzi segment SYN, zawierający informację o dolnej wartości numerów sekwencyjnych. Dodatkowo obecny jest tu segment ACK , któremu towarzyszy konkretny numer sekwencyjny. Jest ono ustawione na wartość o jeden większą niż ta z pola sekwencji segmentu SYN hosta A;
host A odbiera dwa segmenty: SYN i ACK. Następnie przechodzi w stan ESTABLISHED, po czym wysyła do hosta B segment ACK z potwierdzeniem odebrania segmentu SYN;
host B odbiera segment ACK i również przechodzi w stan ESTABLISHED;
host A może w tym momencie rozpocząć przesyłanie określonych danych.

Co się stanie, jeśli wysłaniu pakietu przeszkodzi brak chęci nawiązania połączenia ze strony hosta B? W takim przypadku powinien on wystosować odpowiedź zawierającą pakiet z flagą RST (reset).

Transmisja danych

Protokół weryfikuje wysyłkę i odbiór informacji za pomocą sekwencji numerów pakietów oraz sum kontrolnych. Ze strony odbiorcy (host B) wystosowywane jest potwierdzenie otrzymania określonych pakietów. Charakteryzują się one konkretnymi numerami sekwencyjnymi. Dowodem na realizację takiego działania jest flaga ACK.

Co się dzieje, jeśli dojdzie do wykrycia brakujących pakietów? W takiej sytuacji są one retransmitowane. Host B defragmentuje je, a następnie porządkuje zgodnie z numerami sekwencyjnymi. Robi to, by przekazać pełny, złożony segment, do wyższych warstw modeli OSI.

Zakończenie połączenia

Co się stanie, gdy pożądane informacje dotrą do miejsca przeznaczenia? Wtedy dochodzi do zakończenia połączenia. Może ono zostać zainicjowane przez każdą ze stron – zarówno hosta A, jak i hosta B. W takim przypadku wystarczy tylko, że z serwera zostanie wysłany pakiet z flagą FIN (finished).

Taki pakiet musi być następnie potwierdzony kolejną flagą – ACK. W większości przypadków otrzymanie pakietu z flagą FIN sprawia, że druga strona automatycznie kończy komunikację. Realizowane jest to poprzez wysłanie pakietu z dwoma flagami – FIN i ACK. Tego typu pakiet natomiast również wymaga potwierdzenia w formie ACK.

Protokoły mogą skorzystać z rozwiązania awaryjnego. Jest ono wykorzystywane jednak stosunkowo rzadko. Polega na przerwaniu połączenia przy pomocy przesłanego pakietu z flagą RST (reset). W takim przypadku potwierdzenie nie jest już wymagane.

Obsługa nieuporządkowanych pakietów

Protokół TCP jest w stanie wykryć nieuporządkowane pakiety. Jest to możliwe dzięki numerom sekwencji oraz potwierdzeniom. Jak jednak taka sytuacja wygląda od strony technicznej?

Host B może zauważyć, że numer sekwencji jest zdecydowanie wyższy niż te zatwierdzane do tej pory. Na tej podstawie wysnuwa wniosek, że brakuje mu co najmniej jednego pakietu. Wysyła więc do nadawcy (hosta A) wiadomość, że mogło dojść do błędu. Robi to przy pomocy pakietu z numerem potwierdzenia zawierającego oczekiwany numer sekwencyjny.

Do takiej sytuacji mogą doprowadzić różne scenariusze, ale najczęściej odpowiada za to:

poruszanie się „zagubionego pakietu” w wolniejszym tempie, np. przez słabe łącze internetowe. W tym przypadku dotrze on w końcu do odbiorcy, ale zapewne zajmie mu to więcej czasu;
brak pakietu, który po prostu został utracony. W tym przypadku nie dotrze on „samodzielnie” do odbiorcy. Nadawca musi więc go retransmitować ponownie.

Niezależnie od przyczyny problemu, host B jest zmuszony poradzić sobie z nieuporządkowanymi pakietami. Wykorzystuje do tego numery sekwencji, składając dane w prawidłowej kolejności.

Wykrywanie utraconych pakietów

Protokół TCP jest w stanie wykryć utracony pakiet przy pomocy limitu czasu. Gdy host A wysyła pakiet, uruchomiony zostaje automatycznie licznik czasu. Wtedy też dane trafiają do kolejki retransmisji. Po upływie określonego czasu i braku ACK od hosta B, pakiet zostaje wysłany ponownie.

Jak zapewne już się domyślasz, tak przeprowadzona retransmisja może skończyć się duplikacją pakietów u hosta B. Dzieje się tak, jeśli pakiet nie został utracony, a jedynie „podróżował wolniejszą trasą”. W takim przypadku odbiorca zwyczajnie odrzuca otrzymywane pakiety będące powieleniem już otrzymanych danych.

Stany połączenia w TCP

Podczas realizacji połączenia TCP, może dojść do wystąpienia różnego rodzaju stanów. Są zależne zarówno od etapu transferu, jak i odpowiedzi wysyłanych przez obie strony. Wyróżnia się 11 głównych stanów połączenia TCP:

LISTEN – stan wskazujący na gotowość do przyjęcia połączenia. Dotyczy określonego przez serwer WWW portu;
SYN-SENT – stan wskazujący na realizację pierwszej fazy nawiązywania połączenia, zainicjowanej przez klienta. Oznacza, że pakiet z flagą SYN został już wysłany i trwa oczekiwanie na odpowiedź z pakietami SYN+ACK;
SYN-RECEIVED – stan wskazujący na odebranie pakietu SYN oraz wysłanie pakietów SYN+ACK. Oznacza oczekiwanie na odpowiedź z pakietem ACK. W praktyce więc połączenie jest w trybie tzw. half-open („w połowie otwarte” czy „częściowo otwarte”);
ESTABLISHED – stan wskazujący na prawidłowe nawiązanie połączenia. Oznacza, że właśnie najprawdopodobniej realizowana jest transmisja danych;
FIN-WAIT-1 – stan wskazujący na wysłanie pakietu FIN. W tym momencie dane nadal mogą być odbierane przez host B. Niemożliwa jest natomiast ich dalsza wysyłka przez host A;
FIN-WAIT-2 – stan wskazujący na otrzymanie potwierdzenia własnego pakietu FIN. Oznacza oczekiwanie na wysłanie przez serwer pakietu FIN;
CLOSE-WAIT – stan wskazujący na otrzymanie pakietu FIN oraz wysłanie w odpowiedzi pakietu ACK. Trwa oczekiwanie na wysyłkę własnego pakietu FIN. Dojdzie do tego w chwili, gdy aplikacja zakończy nadawanie;
CLOSING – stan wskazujący na realizację zamykania połączenia;
LAST-ACK – stan wskazujący na to, że otrzymano i wysłano pakiet FIN. Oznacza, że trwa oczekiwanie na wysyłkę ostatniego pakietu ACK;
TIME-WAIT – stan wskazujący na oczekiwanie na upewnienie się, że host B otrzymał potwierdzenie rozłączenia. Domyślnie stan ten nie może być utrzymywany przez dłużej niż 4 minuty (zgodnie z wytycznymi RFC 793);
CLOSED – stan oznaczający, że połączenie zostało zamknięte.

Zastosowanie protokołu TCP

Obecnie zastosowanie protokołu TCP jest ograniczone – głównie ze względu na konkurencyjne rozwiązanie, jakim jest UDP. Nie oznacza to natomiast, że nie ma miejsc w sieci, gdzie nadal ta technologia się sprawdza. Mowa tu przede wszystkim o sektorach, w których jego skuteczność i niezawodność cenione są bardziej niż prędkość. Głównym jego minusem jest w końcu wysoki koszt utrzymania sesji połączenia TCP przez stos sieciowy.

TCP sprawdza się w przypadku konkretnych aplikacji i programów. Mowa tu o rozwiązaniach wykorzystujące do działania protokoły warstwy aplikacji, takie jak przede wszystkim SSH, HTTP oraz FTP. Oprócz nich wymienić można natomiast także SMTP/POP3 oraz IMAP4. W praktyce bywa zatem wykorzystywany do nawiązywania połączeń między takimi urządzeniami sieciowymi, jak np.:

drukarki,
routery,
serwery,
komputery.

Nadal zdarza się również, że sięga się po niego w przypadku tworzenia połączeń sieciowych między różnymi sieciami. Zdarza się, że bywa wykorzystywany do tworzenia połączeń Virtual Private Network (VPN). Częściej jednak w tej sferze zastępuje go UDP.

Czym TCP różni się od UDP?

Wielokrotnie w tym artykule odwoływaliśmy się do protokołu UDP (User Datagram Protocol), uważanego za doskonalszą wersję TCP. Wynika to przede wszystkim z faktu, że jest on w stanie wykonywać te same zadania. Pozostaje przy tym jednak szybszy i zużywa mniej danych. Nie oznacza to jednak, że pod każdym względem jest lepszy i zawsze skorzystanie z niego jest dobrym rozwiązaniem. Obie technologie mają swoje mocne i słabe strony. Za najważniejsze, dzielące je różnice, uznać można to, że:

UDP nie porządkuje pakietów i nie zajmuje się ich sprawdzaniem pod kątem błędów. Dzięki temu może działać zdecydowanie szybciej;
TCP dba o to, by pakiety przesyłanych danych docierały do odbiorcy w prawidłowej kolejności. Jest przez to wolniejszy, ale jednocześnie cieszy się większą wiarygodnością;
TCP monitoruje wszystkie przesyłane pakiety, co sprawia, że w jego przypadku ewentualne wstrzyknięcie złośliwych danych jest trudniejsze. To przekłada się z kolei na jego opinię rozwiązania bezpieczniejszego.