TCP a UDP: różnice w transporcie i praktyczne przykłady
TCP i UDP przenoszą dane aplikacji przez IP, ale świadczą różne usługi. TCP daje aplikacjom uporządkowany strumień bajtów z potwierdzeniami i retransmisją. UDP wysyła pojedyncze datagramy bez tych gwarancji na poziomie transportu. Żaden wybór nie jest automatycznie lepszy: decydują wymagania aplikacji.
Co zapewnia TCP
TCP nawiązuje połączenie między punktami końcowymi, zanim nastąpi wymiana danych aplikacji. Numeruje segmenty, może ponownie przesłać brakujące dane i dostarcza bajty aplikacji odbierającej we właściwej kolejności. Mechanizmy kontroli przepływu i przeciążenia chronią odbiorcę i sieć przed zalaniem danymi przez nadawcę. Dzięki temu TCP dobrze sprawdza się przy plikach, poczcie e-mail i wielu połączeniach WWW. Nie oznacza to jednak szyfrowania: do ochrony treści potrzebny jest osobny protokół bezpieczeństwa, taki jak TLS.
Gdy segment zostanie utracony, aplikacja może musieć czekać na brakujące bajty, zanim przetworzy kolejne. To właściwe dla dokumentu, który musi dotrzeć w całości, ale może dodawać opóźnienie w ruchu interaktywnym. TCP nie zachowuje też granic komunikatów aplikacji. Dwa zapisy po stronie nadawcy nie muszą pojawić się jako dwa odczyty u odbiorcy; aplikacja musi sama określić, jak dzieli swoje komunikaty.
Co UDP pozostawia aplikacji
UDP zachowuje granice datagramów i nie nawiązuje połączenia w stylu TCP. Sam UDP nie potwierdza dostarczenia, nie porządkuje pakietów ani nie przesyła ponownie brakujących danych. Aplikacja zbudowana na UDP może w razie potrzeby dodać te funkcje, a także kontrolę przeciążenia i szyfrowanie. DNS zwykle używa UDP do zapytań. QUIC działa na UDP, a mimo to implementuje niezawodne strumienie i nowoczesne zabezpieczenia w wyższej warstwie.
W przypadku mowy na żywo lub gry bardzo spóźniony pakiet może być mniej przydatny niż kolejny, który dotrze na czas. Dlatego niektóre aplikacje same zarządzają utratą pakietów i terminami. Użycie UDP nie przyspiesza przeciążonej sieci: kolejki i odrzucenia dotyczą obu protokołów transportowych. Mierz rzeczywistą aplikację, zamiast zakładać, że nazwa protokołu przesądza o wydajności. Opóźnienie i trasę do celu sprawdzisz w narzędziu 2IP „Sprawdź dostępność adresu IP lub strony”.
Porty i wybór protokołu
Oba protokoły używają numerów portów, ale port TCP 443 i port UDP 443 oznaczają różne punkty końcowe. Sprawdzenie portu TCP nie dowodzi, że działa usługa UDP o tym samym numerze. HTTP/1.1 i HTTP/2 zwykle używają TCP z TLS, a HTTP/3 używa QUIC na UDP. Gdy łączność UDP zawodzi, klient może użyć wersji HTTP opartej na TCP; dokładny wynik zależy od obu stron.
Zacznij od potrzeb aplikacji: pełnego dostarczenia, kolejności, granic komunikatów i limitów czasu. Następnie sprawdź obsługę w sieci i wymagania bezpieczeństwa. Specyfikacje TCP i UDP definiują ich usługi transportowe. Znaczenie numerów wyjaśnia artykuł o portach sieciowych.