Protokół TCP (Transmission Control Protocol) to jeden z fundamentów współczesnych sieci. Jako część stosu TCP/IP gwarantuje dostarczenie wszystkich danych w całości, we właściwej kolejności i bez duplikatów, wykorzystując numery sekwencyjne, potwierdzenia, kontrolę przepływu i zarządzanie zatorami. W typowych warunkach internetowych TCP osiąga skuteczność dostarczenia na poziomie 99,999%, nawet przy 1–2% utraconych pakietów.
W porównaniu z UDP TCP wymaga więcej zasobów i wprowadza większy narzut, ale zapewnia integralność i porządek dostarczania, co czyni go idealnym m.in. dla poczty, transferu plików czy połączeń SSH.
Podstawowa charakterystyka protokołu TCP i pozycja w modelu TCP/IP
TCP działa na warstwie transportowej modelu TCP/IP i jest protokołem połączeniowym – zanim wyśle dane, ustanawia logiczne połączenie pomiędzy końcami komunikacji. Został opisany w RFC 793 i rozwijany w kolejnych dokumentach.
Model TCP/IP składa się z czterech warstw, których role można streścić następująco:
- Warstwa dostępu do sieci – transmisja ramek w medium i dostęp do łącza;
- Warstwa internet – adresowanie i routing pakietów IP;
- Warstwa transportowa – komunikacja end-to-end między procesami (TCP/UDP);
- Warstwa aplikacji – protokoły usług, np. HTTP, SMTP, SSH.
TCP używa numerów portów do dostarczania danych do właściwych procesów i obsługuje wiele jednoczesnych połączeń na jednym urządzeniu.
TCP działa w trybie klient–serwer: serwer nasłuchuje na porcie, a klient inicjuje połączenie. Po ustanowieniu sesji transmisja jest pełnodupleksowa, a dane są traktowane jako ciąg bajtów (nie osobne pakiety).
Warstwowa architektura i współpraca TCP z IP
Warstwa internet (IP) zapewnia dostarczanie typu best effort bez gwarancji kolejności czy braku duplikatów. TCP przekształca tę zawodną usługę IP w uporządkowaną i bezbłędną transmisję, dodając potwierdzenia, retransmisje i kontrolę przepływu.
Trzyetapowy proces nawiązywania połączenia TCP (three-way handshake)
Nawiązanie połączenia synchronizuje numery sekwencyjne i ustala parametry (np. MSS, opcje):
- SYN: klient wysyła segment z flagą SYN oraz losowym ISN i przechodzi do SYN-SENT.
- SYN-ACK: serwer odpowiada własnym ISN i potwierdza ISN klienta, przechodząc do SYN-RECEIVED.
- ACK: klient potwierdza ISN serwera i przechodzi do ESTABLISHED; serwer również przechodzi do ESTABLISHED.
Struktura segmentu TCP i pola nagłówka
Nagłówek TCP ma od 20 do 60 bajtów (z opcjami do 40 bajtów). Poniższa tabela zbiera kluczowe pola, ich rozmiar i znaczenie:
| Pole | Rozmiar | Opis |
|---|---|---|
| Port źródłowy | 16 bitów | identyfikuje proces nadawcy |
| Port docelowy | 16 bitów | identyfikuje proces odbiorcy |
| Numer sekwencyjny | 32 bity | pozycja pierwszego bajtu danych w strumieniu |
| Numer potwierdzenia | 32 bity | numer następnego oczekiwanego bajtu |
| Długość nagłówka (data offset) | 4 bity | długość nagłówka w słowach 32-bitowych |
| Flagi sterujące (np. SYN, ACK, FIN, RST, PSH, URG) | 1 bit (każda) | sterują ustanawianiem, przesyłaniem i zamykaniem połączenia |
| Rozmiar okna | 16 bitów | liczba bajtów, które odbiorca może przyjąć (kontrola przepływu) |
| Suma kontrolna | 16 bitów | weryfikacja integralności nagłówka i danych |
| Wskaźnik pilności (urgent pointer) | 16 bitów | wskazuje koniec danych pilnych (gdy URG=1) |
| Opcje | 0–40 bajtów | rozszerzenia, np. SACK, MSS, timestamps, window scaling |
Mechanizmy zapewniania niezawodności transmisji
Najważniejsze elementy niezawodności TCP działają wspólnie, aby utrzymać spójny, uporządkowany strumień danych mimo strat i zmian kolejności:
- Potwierdzenia (ACK) – odbiorca sygnalizuje poprawnie odebrane bajty, a nadawca może zwolnić bufor;
- Retransmission Timeout (RTO) – czasomierz wyzwala retransmisję, gdy ACK nie nadejdzie na czas;
- Suma kontrolna – wykrywa błędy, a niespójny segment jest odrzucany i niepotwierdzany;
- Buforowanie poza kolejnością – odbiorca składa strumień, czekając na brakujące segmenty;
- Fast retransmit – przyspiesza retransmisję po serii zduplikowanych ACK (zwykle trzech).
Kontrola przepływu i mechanizm przesuwnego okna
Kontrola przepływu chroni odbiorcę przed zalaniem danymi. Wykorzystywany jest mechanizm przesuwnego okna, który określa liczbę bajtów możliwych do wysłania bez oczekiwania na ACK.
Kluczowe składniki kontroli przepływu to:
- Sliding window – okno przesuwa się wraz z potwierdzeniami, równoważąc tempo nadawcy i odbiorcy;
- Zero-window probing – małe segmenty testowe wznawiają transmisję, gdy okno u odbiorcy spada do zera;
- Window scaling – zwiększa efektywny rozmiar okna do kilku megabajtów, co jest niezbędne przy wysokim BDP.
Dobrze dobrane parametry okna mogą zwiększyć efektywną przepustowość nawet o ok. 40%.
Kontrola przeciążenia sieci i algorytmy zarządzania zatorami
Kontrola przepływu chroni końcówkę, ale nie całą sieć. Dlatego TCP implementuje kontrolę przeciążenia, która ogranicza tempo transmisji po wykryciu strat (RTO lub zduplikowane ACK):
- Slow start – szybkie (wykładnicze) zwiększanie okna do progu lub do wystąpienia straty;
- Congestion avoidance – wolniejszy, liniowy wzrost po osiągnięciu progu;
- Fast retransmit/fast recovery – szybszy powrót do wyższej przepustowości po utracie segmentu;
- TCP Reno/NewReno – klasyczne odmiany z udoskonalonym odzyskiwaniem po stratach;
- TCP Cubic – agresywniejsze zwiększanie przepustowości w sieciach o wysokim BDP;
- BBR – estymuje przepustowość i opóźnienie, celując w iloczyn bandwidth-delay product.
Zakończenie połączenia TCP i stany połączenia
Połączenie zamyka się przez wymianę FIN i ACK. Jedna strona sygnalizuje zakończenie wysyłania (FIN), druga to potwierdza (ACK); zwykle obie wysyłają FIN i końcowe ACK.
Zgodnie z RFC 793 połączenie może pozostawać w TIME-WAIT do ok. 4 minut, aby upewnić się, że wszystkie związane pakiety opuściły sieć. TCP utrzymuje stany odzwierciedlające cykl życia połączenia (m.in. LISTEN, SYN-SENT, ESTABLISHED, FIN-WAIT, CLOSE-WAIT, TIME-WAIT), a właściwe zarządzanie stanami jest kluczowe dla stabilności i efektywnego wykorzystania zasobów.
Porównanie TCP z protokołem UDP
Aby szybko porównać kluczowe właściwości obu protokołów, skorzystaj z poniższej tabeli:
| Cecha | TCP | UDP |
|---|---|---|
| Tryb pracy | połączeniowy (handshake) | bezpołączeniowy |
| Niezawodność i kolejność | gwarantowane dzięki ACK/retransmisjom | brak gwarancji |
| Narzut protokołu | 20–60 bajtów nagłówka | 8 bajtów nagłówka |
| Kontrola przepływu i zatorów | tak (okno, algorytmy CC) | nie (zwykle logika w aplikacji) |
| Opóźnienia | wyższe (potwierdzenia, zarządzanie) | niższe |
| Typowe zastosowania | WWW, e-mail, FTP, SSH, transakcje | VoIP, gry, streaming na żywo |
Wybór zależy od wymagań aplikacji: niezawodność (TCP) kontra minimalne opóźnienia (UDP).
Praktyczne zastosowania protokołu TCP
Najczęstsze usługi oparte na TCP obejmują:
- HTTP/HTTPS – przeglądanie stron i API oparte na protokole WWW;
- FTP/SFTP – niezawodny transfer plików i synchronizacja danych;
- SMTP/IMAP/POP3 – wysyłanie i odbiór poczty elektronicznej;
- SSH – bezpieczny zdalny dostęp i tunelowanie;
- Bazy danych – trwałe połączenia klient–serwer w aplikacjach biznesowych.
W typowym przedsiębiorstwie TCP obsługuje dziesiątki tysięcy połączeń dziennie; szacuje się, że ponad 80% ruchu internetowego wykorzystuje TCP, z czego ok. 60% stanowi ruch HTTP/HTTPS. SSL/TLS dodaje szyfrowanie i uwierzytelnianie nad kanałem TCP.
Optymalizacja i zaawansowane mechanizmy TCP
Poniższe rozszerzenia poprawiają wydajność i odporność na straty:
- SACK (Selective Acknowledgment) – precyzyjnie wskazuje odebrane zakresy, ograniczając zbędne retransmisje;
- TCP Timestamps – dokładniejsze szacowanie RTT i strojenie RTO;
- Early Retransmit – szybsze wykrywanie strat przy małej liczbie pakietów w locie;
- Tail Loss Probe (TLP) – adresuje utraty końcowych segmentów sesji;
- Window scaling – pozwala na okna większe niż ~64 KB, kluczowe przy wysokim BDP;
- TCP BBR – sterowanie tempem według estymacji przepustowości i opóźnienia łącza.
Wyzwania i problemy wydajności TCP
W sieciach o wysokim BDP (np. satelity, trasy transkontynentalne) standardowe ustawienia mogą wykorzystywać tylko ułamek dostępnego pasma, jeśli okno nie rośnie wystarczająco.
Retransmission timeouts (RTO) silnie dewastują przepustowość: gdy ACK nie przychodzą, nadawca wstrzymuje wysyłanie co najmniej na czas RTO (często ≥1 s). Lepsze estymowanie zegarów i szybsze wykrywanie strat ogranicza te straty wydajności.