Co to jest protokół TCP i jak zapewnia niezawodną transmisję danych?

Protokół TCP (Transmission Control Protocol) to podstawowy standard komunikacyjny w internecie, który odpowiada za dzielenie danych na mniejsze segmenty i dostarczanie ich we właściwej kolejności do odbiorcy. Zapewnia on niezawodną transmisję danych poprzez mechanizm trójetapowego nawiązywania połączenia, ciągłe śledzenie numerów sekwencyjnych pakietów oraz wymuszanie retransmisji w przypadku zgubienia informacji po drodze. To jest absolutna podstawa działania sieci komputerowych. Bez tego mechanizmu nie moglibyśmy pobrać pliku, otworzyć strony internetowej ani wysłać maila z pewnością, że dotrze w całości.

My w IT na co dzień pracujemy z modelem OSI oraz modelem TCP/IP. Warstwa transportowa, w której operuje omawiany standard, ma jedno konkretne zadanie. Musi wziąć surowe dane z warstwy aplikacji, potiąć je na strawne kawałki i przepchnąć przez sieć. Pakiety IP odpowiadają tylko za adresację i trasowanie. Nie obchodzi ich, czy dotrą na miejsce. To właśnie Transmission Control Protocol dodaje warstwę logiki, która pilnuje porządku. Wymusza potwierdzenia odbioru. Kontroluje przepływ. A to zmienia postać rzeczy w budowaniu stabilnych systemów rozproszonych.

Dlaczego protokół TCP jest fundamentem przesyłania danych w internecie?

Większość aplikacji wymaga absolutnej pewności, że wysłane bity dotrą do celu w nienaruszonym stanie. Wyobraźcie sobie transfer środków na koncie bankowym. Zgubienie jednego zera w kwocie przelewu to katastrofa. Dlatego protokół TCP zdominował rynek i obsługuje dzisiaj lwią część ruchu w globalnej sieci. Obejmuje to ruch HTTP, HTTPS, FTP, SSH i pocztę elektroniczną. Pakiety krążące między routerami są narażone na opóźnienia, duplikacje i całkowite zniszczenie. Mechanizmy zaszyte w nagłówkach segmentów radzą sobie z tym chaosem.

Prawda jest zresztą absolutnie taka, że teoria to jedno, a praktyka na produkcji to zupełnie inna bajka. Pamiętam wdrożenie systemu magazynowego w zeszłym roku w małej hali na wrocławskich Krzykach. Zwykły wtorek. Switch na hali produkcyjnej gubił pakiety przez zakłócenia od starych maszyn tokarskich. Wireshark na moim laptopie wypluwał setki retransmisji na sekundę. Szlag mnie trafiał na miejscu. Wszyscy dyrektorzy winią oprogramowanie bazodanowe, a to po prostu fizyka i nieekranowane kable leżące obok kabli siłowych. TCP próbowało ratować sytuację, dławiąc okno transmisyjne do zera. TO JEST WŁAŚNIE ten moment w karierze, w którym rozumiesz, że wyuczone na pamięć regułki z podręczników Cisco mają się nijak do brudnej rzeczywistości kabli leżących w smarze.

Wprowadziliśmy wtedy fizyczną separację okablowania. Błędy CRC na interfejsach spadły do zera. Dopiero wtedy mechanizmy retransmisyjne mogły odetchnąć. Aplikacja zaczęła działać poprawnie. To pokazuje, jak algorytmy transportowe próbują kompensować braki w infrastrukturze fizycznej, czasami całkowicie maskując prawdziwe źródło problemu przed oczami niedoświadczonego administratora.

W jaki sposób TCP nawiązuje połączenie z serwerem?

Proces ten nazywamy trójetapowym nawiązywaniem połączenia. Z języka angielskiego to po prostu three-way handshake. Zanim poleci jakikolwiek bajt użytecznych danych, obie strony muszą się dogadać. Klient wysyła do serwera segment z ustawioną flagą SYN. Mówi w ten sposób: chcę z tobą rozmawiać, mój początkowy numer sekwencyjny to X. Serwer odbiera ten komunikat. Odpowiada segmentem z dwiema flagami: SYN oraz ACK. Potwierdza otrzymanie prośby i podaje swój własny numer sekwencyjny Y. Na samym końcu klient wysyła segment ACK. Potwierdza numery serwera. Połączenie jest ustanowione. Gniazda (sockets) po obu stronach przechodzą w stan ESTABLISHED.

Cały ten proces wydaje się stratą czasu. Dodaje opóźnienie (latency) równe jednemu pełnemu cyklowi RTT (Round Trip Time). Mimo to daje gwarancję, że obie maszyny są gotowe na przyjęcie danych. Alokują bufory w pamięci operacyjnej. Ustalają maksymalny rozmiar segmentu (MSS). Bez tej wstępnej negocjacji wysyłanie danych w ciemno skończyłoby się natychmiastowym przepełnieniem buforów i odrzuceniem ruchu.

Co się dzieje, gdy pakiety danych zginą po drodze?

Sieci IP działają w trybie best-effort. Routery po prostu przekazują pakiety dalej. Jeśli zderzą się z brakiem miejsca w kolejce wyjściowej interfejsu, bezlitośnie wyrzucają pakiety do kosza. I tu wkracza mechanizm potwierdzeń. Odbiorca musi odesłać komunikat ACK dla każdego odebranego kawałka danych. Jeśli nadawca nie otrzyma potwierdzenia w określonym czasie, uznaje segment za zgubiony. Uruchamia się licznik RTO (Retransmission Timeout). Nadawca ponownie wysyła ten sam fragment danych. Czeka znowu.

Zgubienie pakietów wynika z reguły z dwóch konkretnych powodów. Przepełnienia buforów na routerach w drodze pomiędzy operatorem a klientem. Oraz fizycznego uszkodzenia lub zakłócenia sygnału w medium transmisyjnym. Nie ma innych magicznych przyczyn zjawiska utraty danych w sieci.

Mechanizm retransmisji działa brutalnie. Jeśli wyślesz milion pakietów, a zginie jeden w środku stawki, odbiorca nie potwierdzi niczego powyżej tej dziury. Nadawca musi cofnąć się i wysłać brakujący element. W starych implementacjach musiał wysłać ponownie wszystko od momentu zgubienia. Współczesne systemy stosują mechanizm SACK (Selective Acknowledgments). Odbiorca informuje nadawcę o konkretnych dziurach w strumieniu. To drastycznie poprawia przepustowość na łączach o wysokich opóźnieniach.

Czym różni się TCP od UDP i kiedy używamy tego drugiego?

Nie każdy ruch w sieci potrzebuje gwarancji dostarczenia. Czasami szybkość ma większe znaczenie niż dokładność. UDP (User Datagram Protocol) to alternatywa w warstwie transportowej. Pozbywa się całego narzutu. Nie ma nawiązywania połączenia. Nie ma potwierdzeń. Nie ma retransmisji. Aplikacja po prostu wypluwa datagramy na interfejs sieciowy i ma nadzieję, że dotrą na miejsce. To idealne rozwiązanie dla gier wieloosobowych, komunikatorów głosowych i streamingu wideo na żywo.

Zastanawiacie się zresztą, dlaczego wasz stream na konferencji czasami ucina klatki obrazu zamiast zatrzymać się całkowicie? Sam się nad tym borykałem dzisiaj u siebie podczas spotkania zarządu. Kiedy pakiety UDP giną, aplikacja po prostu ignoruje brakującą ramkę wideo. Wyświetla artefakt na ekranie i idzie dalej. Gdybyśmy użyli tutaj protokołu połączeniowego, zgubienie pakietu zatrzymałoby odtwarzanie obrazu u wszystkich uczestników do czasu retransmisji. To zabiłoby całą płynność rozmowy.

Jak działa okno przesuwne i kontrola przepływu?

Wysyłanie danych z czekaniem na potwierdzenie każdego pojedynczego segmentu przed wysłaniem kolejnego byłoby potwornie wolne. Sieć spędzałaby większość czasu na bezczynnym czekaniu. Rozwiązaniem jest okno przesuwne (sliding window). Nadawca może wysłać określoną partię danych bez czekania na ACK. Rozmiar tej partii dyktuje odbiorca. W nagłówku każdego potwierdzenia znajduje się pole Window Size. Odbiorca mówi wprost: mam w buforze miejsce na 64 kilobajty danych. Nadawca ładuje dane w łącze, dopóki nie wyczerpie tego limitu.

W miarę jak aplikacja po stronie odbiorcy czyta dane z bufora, okno się przesuwa i otwiera miejsce na nowe segmenty. Jeśli aplikacja się zawiesi i przestanie czytać dane, bufor się zapełni. Odbiorca wyśle segment z rozmiarem okna ustawionym na zero (Zero Window). Nadawca natychmiast przerywa transmisję. Czeka na sygnał o zwolnieniu miejsca. To chłodny, mechaniczny sposób na to, by szybki serwer nie zalał powolnego klienta nadmiarem informacji.

W jaki sposób systemy operacyjne radzą sobie z przeciążeniem sieci?

Kontrola przepływu chroni odbiorcę. Kontrola przeciążenia chroni samą sieć. Na początku lat 80. internet doświadczył serii katastrofalnych zapaści. Routery nie nadążały z przetwarzaniem pakietów. Wprowadzono algorytmy Congestion Control. Kiedy maszyna zaczyna transmisję, nie wie, jaką przepustowość ma ścieżka do celu. Zaczyna więc powoli. Mechanizm Slow Start wysyła jeden segment. Jeśli wróci ACK, wysyła dwa. Potem cztery. Podwaja liczbę wysyłanych danych w każdym cyklu RTT, dopóki nie wystąpi utrata pakietu. Utrata oznacza, że uderzyliśmy w sufit przepustowości jakiegoś węzła po drodze.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj z logów na głównym węźle, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem infrastruktury. Zazwyczaj w takich sytuacjach algorytm przechodzi w tryb Congestion Avoidance. Zmniejsza okno wysyłania o połowę. Następnie powoli, liniowo zwiększa tempo, badając granice możliwości łącza. Przez lata standardem był algorytm CUBIC. Dzisiaj Google forsuje algorytm BBR (Bottleneck Bandwidth and Round-trip propagation time). Zamiast czekać na stratę pakietu, BBR aktywnie mierzy opóźnienia i przepustowość. Pozwala to na pełne wykorzystanie szybkich łącz bez generowania zatorów w buforach routerów (zjawisko bufferbloat).

Jak czytać nagłówek segmentu podczas analizy ruchu?

Administratorzy sieci spędzają godziny w analizatorach protokołów takich jak Wireshark. Zrozumienie struktury nagłówka to podstawa rozwiązywania problemów z łącznością. Standardowy nagłówek ma 20 bajtów bez opcji dodatkowych. Zawiera konkretne, twarde liczby niezbędne do zestawienia transmisji.

• Port źródłowy i docelowy: Numery od 0 do 65535. Pozwalają systemowi operacyjnemu skierować odebrane dane do właściwej aplikacji. Przeglądarka internetowa uderza na port 443 serwera.
• Numer sekwencyjny (Sequence Number): 32-bitowa liczba oznaczająca pozycję pierwszego bajtu w danym segmencie względem całego strumienia danych. Służy do układania puzzli w odpowiedniej kolejności po stronie odbiorcy.
• Numer potwierdzenia (Acknowledgment Number): Działa tylko z flagą ACK. Wskazuje numer sekwencyjny następnego bajtu, którego spodziewa się odbiorca.
• Flagi kontrolne: Pojedyncze bity sterujące logiką stanu. URG, ACK, PSH, RST, SYN, FIN. Flaga RST (Reset) brutalnie zrywa połączenie w przypadku błędu krytycznego.

Analiza tych pól pozwala wyłapać anomalie. Jeśli widzisz mnóstwo pakietów z flagą SYN, a brak odpowiedzi SYN-ACK, oznacza to, że serwer docelowy jest martwy, zablokowany przez zaporę sieciową, albo właśnie jesteś ofiarą ataku SYN Flood. Hakerzy wysyłają tysiące fałszywych żądań połączenia. Serwer alokuje zasoby i czeka na ostatnie ACK, które nigdy nie nadchodzi. Tabela stanów się przepełnia. Maszyna przestaje obsługiwać legalnych klientów.

Jakie błędy najczęściej popełniają administratorzy przy konfiguracji protokołów transportowych?

Złe ustawienie rozmiaru MTU (Maximum Transmission Unit) to najczęstszy powód problemów na wdrożeniach. MTU określa maksymalną wielkość pakietu IP, jaki może przejść przez dany interfejs. Zazwyczaj jest to 1500 bajtów. Jeśli dodamy tunelowanie IPSec lub nagłówki GRE, dostępne miejsce na użyteczne dane (MSS) drastycznie spada. Pakiety muszą być fragmentowane. Fragmentacja obciąża procesory routerów. Co gorsza, czasami konfiguracja firewalla potrafi tak uciąć pakiety ICMP, że mechanizm Path MTU Discovery po prostu zdycha i szlag trafia całą transmisję. Dane zawieszają się w próżni. Użytkownik widzi biały ekran ładowania w przeglądarce.

Zmieniliśmy te zasady na robocie. Wymuszamy na firewallach opcję TCP MSS Clamping. Firewall w locie podmienia wartość MSS w pakietach SYN. Zmusza obie strony do wysyłania mniejszych segmentów. Omija to całkowicie problem fragmentacji. To brudny hack, ale działa w stu procentach przypadków na styku sieci korporacyjnych z operatorami VPN.

Kolejnym potężnym błędem jest ignorowanie stanów zamykania połączenia. Zakończenie transmisji wymaga czterech kroków. Inicjator wysyła FIN. Odbiorca odpowiada ACK. Następnie odbiorca sam wysyła swój pakiet FIN, a inicjator kończy proces ostatnim ACK. Po tym wszystkim gniazdo przechodzi w stan TIME_WAIT na kilkadziesiąt sekund. Serwer trzyma to w pamięci na wypadek, gdyby opóźnione pakiety z tej sesji wciąż błąkały się po sieci. Na mocno obciążonych serwerach proxy zła konfiguracja limitów powoduje wyczerpanie dostępnych portów efemerycznych. Nowe połączenia są odrzucane, mimo że procesor i RAM serwera nudzą się w najlepsze.

Podsumowanie problematyki optymalizacji ruchu sieciowego

Rozbiliśmy protokół TCP na części pierwsze. Pokazaliśmy, w jaki sposób surowa matematyka numerów sekwencyjnych i rozmiarów okien ratuje nas przed chaosem utraty danych na fizycznych łączach operatorów. Mechanizmy retransmisji, kontroli przepływu oraz zatory w buforach to nie jest czarna magia. To twarde reguły inżynieryjne zdefiniowane w dokumentach RFC dekady temu, które dziś muszą radzić sobie z ruchem liczonym w terabitach na sekundę.

Sprawdźcie jutro rano logi swoich firewalli na brzegu sieci. Zobaczcie, ile sesji wisi bezużytecznie w stanie TIME_WAIT na waszych balancerach ruchu. Zalogujcie się na router brzegowy i odpalcie zrzut pakietów. Zobaczcie na własne oczy, jak wygląda flaga RST ubijająca połączenia od natrętnych skanerów portów. Zrozumienie, co to jest protokół TCP i jak zapewnia niezawodną transmisję danych, kończy się w momencie, gdy zamykasz podręcznik i wklepujesz komendę tcpdump na konsoli serwera produkcyjnego.

Najczęściej zadawane pytania (FAQ)

• Co to jest protokół TCP?
  TCP (Transmission Control Protocol) to połączeniowy protokół warstwy transportowej, który dzieli dane na segmenty i gwarantuje ich dostarczenie do odbiorcy we właściwej kolejności, bez błędów i duplikatów.
• Jak TCP zapewnia niezawodną transmisję danych?
  Wykorzystuje system numerów sekwencyjnych i potwierdzeń (ACK). Jeśli nadawca nie otrzyma potwierdzenia odbioru w wyznaczonym czasie, automatycznie retransmituje zgubiony segment danych.
• Czym jest three-way handshake?
  To trójetapowy proces nawiązywania połączenia między klientem a serwerem. Obejmuje wymianę trzech pakietów z ustawionymi flagami: SYN, następnie SYN-ACK, a na końcu ACK.
• Czym różni się TCP od UDP?
  TCP gwarantuje dostarczenie danych kosztem wyższego narzutu i opóźnień. UDP wysyła dane natychmiast, bez sprawdzania czy dotarły na miejsce, co jest szybsze, ale podatne na gubienie informacji.
• Co to jest okno przesuwne (sliding window)?
  To mechanizm kontroli przepływu. Określa, ile danych nadawca może wysłać w sieć, zanim będzie musiał zatrzymać się i poczekać na potwierdzenie odbioru od drugiej strony.
• Dlaczego pakiety TCP giną w sieci?
  Pakiety giną głównie z powodu przepełnienia buforów na routerach w przypadku przeciążenia łącza oraz z powodu fizycznych zakłóceń sygnału na kablach lub w sieciach bezprzewodowych.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. Główny Urząd Statystyczny – https://stat.gov.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. Wydawnictwo Naukowe PWN – https://pwn.pl
5. Narodowe Centrum Badania i Rozwoju – https://www.gov.pl/web/ncbr