Gdy pobierasz plik, brak jednego fragmentu może go uszkodzić. Gdy rozmawiasz przez internet, czekanie na ponowne przesłanie spóźnionego kawałka dźwięku potrafi zepsuć rozmowę bardziej niż jego pominięcie. Na tym opiera się podstawowa różnica między TCP a UDP: pierwszy protokół pilnuje kompletności i kolejności danych, drugi stawia na prostotę oraz możliwie małe opóźnienia.
Nie da się uczciwie powiedzieć, że jeden z nich jest zawsze szybszy albo lepszy. Decyzję należy oprzeć na skutkach utraty pakietu. Jeżeli strata oznacza błędny dokument, niepełną transakcję lub uszkodzony plik, potrzebna jest niezawodność. Jeżeli dane po kilkuset milisekundach tracą wartość, ważniejsza staje się aktualność.
TCP kontroluje transmisję, ale każda kontrola kosztuje
TCP, czyli Transmission Control Protocol, jest protokołem połączeniowym. Zanim klient i serwer rozpoczną przesyłanie właściwych danych, muszą zestawić połączenie. Służy do tego mechanizm three-way handshake:
- klient wysyła segment SYN z prośbą o rozpoczęcie połączenia,
- serwer odpowiada segmentem SYN-ACK,
- klient potwierdza odpowiedzią ACK.
Dopiero po tej wymianie rusza właściwa transmisja. Dla pojedynczej strony internetowej taki narzut może wydawać się niewielki, ale przy dużym opóźnieniu między urządzeniami dodatkowe rundy komunikacji są odczuwalne. Właśnie dlatego nowoczesne protokoły ograniczają liczbę koniecznych wymian przed przesłaniem danych.
TCP traktuje przesyłane informacje jak uporządkowany strumień. Poszczególne segmenty są numerowane, a odbiorca potwierdza ich otrzymanie. Gdy fragment zaginie, nadawca przesyła go ponownie. Jeżeli segmenty dotrą w złej kolejności, zostaną uporządkowane przed przekazaniem aplikacji.
W praktyce TCP zapewnia:
- retransmisję brakujących danych,
- zachowanie właściwej kolejności,
- wykrywanie błędów za pomocą sumy kontrolnej,
- kontrolę przepływu, aby szybki nadawca nie zasypał wolniejszego odbiorcy,
- kontrolę przeciążenia, która ogranicza tempo transmisji, gdy sieć zaczyna gubić pakiety.
To duże ułatwienie dla programisty. Aplikacja nie musi samodzielnie prowadzić listy odebranych fragmentów, prosić o brakujące dane ani składać ich we właściwej kolejności. Wadą jest większy narzut. Minimalny nagłówek TCP ma 20 bajtów, a po dodaniu opcji może być dłuższy. Do tego dochodzą potwierdzenia, zestawianie połączenia i ewentualne retransmisje.
Najbardziej irytujący problem pojawia się na niestabilnym Wi-Fi, przeciążonym łączu komórkowym albo źle działającym tunelu VPN. Utrata jednego segmentu może zatrzymać przekazanie aplikacji późniejszych danych, mimo że fizycznie dotarły już do odbiorcy. To head-of-line blocking, czyli blokowanie początku kolejki.
Użytkownik widzi wtedy:
- zatrzymujące się pobieranie,
- stronę, która przez chwilę nie reaguje,
- aplikację czekającą na odpowiedź,
- skokowe działanie usługi mimo niezłej przepustowości łącza.
TCP jest właściwym wyborem wszędzie tam, gdzie wynik musi być kompletny. Dotyczy to między innymi przesyłania plików, poczty elektronicznej, połączeń SSH, komunikacji z bazami danych, formularzy, paneli administracyjnych i transakcji. HTTP/1.1 oraz HTTP/2 najczęściej działają na TCP, podobnie jak klasyczne połączenia HTTPS wykorzystujące TCP i TLS.
Nie należy jednak mylić niezawodności z poufnością. TCP sam nie szyfruje danych. Pilnuje ich transportu, lecz bez TLS, VPN lub innej warstwy kryptograficznej przesyłana treść nadal może zostać odczytana przez osobę mającą dostęp do ruchu sieciowego. Określenie TCP jako „bezpieczniejszego UDP” jest więc technicznie nieprecyzyjne.
UDP wysyła dane bez czekania na potwierdzenie
UDP, czyli User Datagram Protocol, działa bez zestawiania połączenia. Nadawca przygotowuje datagram, wskazuje port źródłowy i docelowy, a następnie przekazuje go do sieci. Nie sprawdza wcześniej, czy odbiorca jest gotowy, i nie czeka na potwierdzenie dostarczenia.
Nagłówek UDP ma 8 bajtów. Zawiera:
- port źródłowy,
- port docelowy,
- długość datagramu,
- sumę kontrolną.
Na tym kończy się praca samego protokołu. UDP nie numeruje datagramów, nie układa ich we właściwej kolejności i nie przesyła ponownie utraconych danych.
Datagram może więc dotrzeć prawidłowo, zostać odebrany kilka razy, przyjść po wiadomości wysłanej później albo zniknąć po drodze. Może go odrzucić przeciążony router, firewall, urządzenie realizujące translację NAT lub sam odbiorca.
Nie oznacza to, że UDP „gubi pakiety”. Straty powstają w sieci niezależnie od protokołu. UDP po prostu nie próbuje ich ukryć przed aplikacją. Gdy datagram nie dotrze, protokół nie podejmie automatycznej retransmisji.
Takie zachowanie jest korzystne, gdy dane szybko się dezaktualizują. Podczas wideokonferencji nie ma sensu zatrzymywać obrazu, aby odzyskać klatkę sprzed dwóch sekund. W grze sieciowej spóźniona informacja o dawnej pozycji przeciwnika jest zwykle bezwartościowa. Lepiej przesłać nową pozycję i kontynuować działanie.
UDP jest często wykorzystywany przez:
- zapytania DNS,
- telefonię VoIP,
- wideokonferencje,
- transmisje na żywo,
- gry online,
- systemy telemetryczne,
- synchronizację czasu,
- część tuneli VPN,
- protokół QUIC, na którym opiera się HTTP/3.
Aplikacja korzystająca z UDP nie musi rezygnować z kontroli. Może we własnej warstwie dodawać numery sekwencyjne, potwierdzenia, retransmisje, korekcję błędów i mechanizmy sterowania przeciążeniem. Dobrym przykładem jest QUIC. Korzysta on z UDP, ale zapewnia szyfrowanie, obsługę połączenia, kontrolę transmisji i odzyskiwanie utraconych danych.
To istotne rozróżnienie. Zdanie „TCP gwarantuje dostarczenie, a UDP nie” opisuje zachowanie samych protokołów. Nie przesądza o niezawodności całej aplikacji. Program oparty na UDP może dostarczać dane niezawodnie, lecz musi sam zbudować potrzebne mechanizmy.
UDP ma również ograniczenie, które często wychodzi dopiero podczas wdrożenia. Zbyt duży datagram może zostać podzielony na fragmenty IP. Jeżeli zaginie jeden fragment, odbiorca nie odtworzy całego datagramu. Dlatego aplikacje czasu rzeczywistego powinny unikać pakietów zbliżonych do granicy MTU.
W typowym Ethernecie MTU wynosi 1500 bajtów, ale nie oznacza to, że aplikacja może bezpiecznie umieścić 1500 bajtów danych w jednym datagramie. Część miejsca zajmują nagłówki IP i UDP. Tunele VPN, PPPoE oraz dodatkowe warstwy enkapsulacji jeszcze bardziej ograniczają dostępną przestrzeń. Zbyt duże pakiety mogą działać w jednej sieci, a po zmianie operatora lub uruchomieniu VPN nagle zacząć znikać.
Protokół wybiera się według skutków utraty pakietu
Najpraktyczniejsze pytanie nie brzmi: „który protokół jest szybszy?”, lecz: co stanie się po utracie jednego pakietu?
Jeżeli skutkiem będzie uszkodzony plik, niepełna odpowiedź z bazy, błędna transakcja lub przerwane logowanie, wybierz TCP albo protokół zapewniający podobną kontrolę. Kilka zaoszczędzonych milisekund nie ma znaczenia, gdy wynik jest niepoprawny.
Jeżeli pojedyncza strata spowoduje krótkie pogorszenie dźwięku, pominięcie klatki lub niewielką korektę pozycji gracza, lepszym rozwiązaniem może być UDP. Warunek jest prosty: aplikacja musi umieć rozpoznać brak danych i kontynuować pracę bez zawieszania całej sesji.
Decyzję najlepiej podjąć w następującej kolejności:
- Określ wymagania dotyczące kompletności.
Jeżeli każdy fragment jest potrzebny do odtworzenia wyniku, potrzebujesz retransmisji i kontroli kolejności. - Ustal maksymalne akceptowalne opóźnienie.
W rozmowie głosowej opóźnienie jednokierunkowe rzędu 150–200 ms zaczyna utrudniać naturalną wymianę zdań. W systemie księgowym dodatkowe 200 ms zwykle nie ma większego znaczenia, o ile operacja zakończy się poprawnie. - Sprawdź, czy stare dane nadal mają wartość.
Fragment archiwum ZIP jest potrzebny nawet po kilku sekundach. Pozycja postaci sprzed kilku sekund nie powinna zastępować aktualnego stanu gry. - Oceń narzut dopiero na końcu.
Różnica między 8-bajtowym nagłówkiem UDP a co najmniej 20-bajtowym nagłówkiem TCP jest istotna głównie przy ogromnej liczbie małych komunikatów. Przy dużych transferach ważniejsze stają się stabilność sieci, sterowanie przeciążeniem i liczba retransmisji. - Oddziel transport od szyfrowania.
TCP można łączyć z TLS. Dla UDP stosuje się między innymi DTLS, IPsec albo szyfrowanie wbudowane w QUIC. Sam wybór TCP lub UDP nie zapewnia poufności.
Różne są również metody diagnostyki. Gdy zacina się połączenie TCP, w pierwszej kolejności należy sprawdzić:
- liczbę retransmisji,
- czas RTT,
- utratę pakietów,
- rozmiar okna TCP,
- przeciążenie łącza,
- blokowanie portów,
- błędne wartości MTU lub MSS.
Przy UDP najważniejsze są:
- utrata datagramów,
- jitter, czyli zmienność opóźnienia,
- przeciążenie sieci Wi-Fi,
- reguły firewalla,
- działanie NAT,
- problemy tunelu VPN,
- zbyt duży rozmiar pakietów.
Sama przepustowość niewiele mówi o jakości transmisji czasu rzeczywistego. Łącze 600 Mb/s może fatalnie obsługiwać rozmowę VoIP, gdy pakiety przychodzą nierówno lub kilka procent z nich ginie. Stabilne łącze 30 Mb/s może zapewnić lepszą wideokonferencję, jeśli ma niski jitter i krótkie opóźnienia.
Typowym błędem jest odblokowanie całego ruchu UDP na routerze, gdy gra lub komunikator nie działa poprawnie. To wygodne, ale niepotrzebnie zwiększa powierzchnię ataku. Najpierw należy sprawdzić dokumentację aplikacji, wymagane porty oraz kierunek komunikacji, a dopiero później utworzyć możliwie wąską regułę firewalla.
FAQ
Czy TCP jest zawsze wolniejsze od UDP?
Nie. TCP ma większy narzut i może czekać na retransmisję, ale przy przesyłaniu dużych plików skutecznie wykorzystuje łącze dzięki kontroli przeciążenia. UDP daje przewagę przede wszystkim tam, gdzie liczy się małe opóźnienie, a aplikacja toleruje straty.
Czy UDP zawsze gubi pakiety?
Nie. W stabilnej sieci wszystkie datagramy mogą dotrzeć. UDP nie gwarantuje jednak dostarczenia i nie ponawia transmisji po wykryciu straty.
Czy TCP szyfruje dane?
Nie. Za szyfrowanie odpowiada osobna warstwa, najczęściej TLS. Zwykłe połączenie TCP może przesyłać dane otwartym tekstem.
Dlaczego gry online korzystają z UDP?
Ponieważ aktualne informacje są ważniejsze od starych. Gra może wysyłać bieżące pozycje bez retransmisji, a jednocześnie osobno potwierdzać operacje krytyczne, takie jak zakup przedmiotu, wynik akcji lub zmiana ekwipunku.
Czy strony internetowe działają na TCP czy UDP?
HTTP/1.1 i HTTP/2 najczęściej korzystają z TCP. HTTP/3 działa przez QUIC oparty na UDP, ale sam zapewnia szyfrowanie, kontrolę transmisji i obsługę utraty danych.
Czy firewall może blokować UDP, gdy TCP nadal działa?
Tak. Reguły mogą osobno filtrować oba protokoły oraz konkretne porty. Dlatego po zmianie routera lub uruchomieniu VPN strony WWW mogą działać poprawnie, a komunikator, gra lub telefonia internetowa przestać się łączyć.
Co sprawdzić najpierw, gdy połączenie się zacina?
Dla TCP zacznij od RTT i retransmisji. Dla UDP zmierz utratę pakietów i jitter. Test prędkości wykonaj później, ponieważ wysoka przepustowość nie naprawi niestabilnego połączenia.
Najpierw sklasyfikuj przesyłane dane. Pliki, logowanie, formularze i transakcje wymagają kompletności, więc naturalnym wyborem jest TCP. Rozmowy, transmisje na żywo i dynamiczne dane z gry wymagają aktualności, dlatego lepiej pasuje do nich UDP albo protokół zbudowany na jego bazie. Przy awarii nie zaczynaj od wymiany routera ani zakupu szybszego internetu. Najpierw zmierz opóźnienie, utratę pakietów i jitter — te trzy parametry najszybciej pokażą, czy problem leży w sieci, konfiguracji protokołu czy samej aplikacji.
