TCP i UDP w projekcie aplikacji
Wybór TCP lub UDP określa właściwości dostarczania dostępne dla aplikacji w warstwie transportowej. TCP ustanawia połączenie i zapewnia uporządkowany, niezawodny strumień bajtów z potwierdzeniami i retransmisjami. Transfer plików, dostarczanie dokumentów HTML i poczta elektroniczna korzystają z tych właściwości, ponieważ brakujące lub przestawione bajty zmieniłyby wynik.
Protokół Datagramów Użytkownika (UDP) wysyła niezależne wiadomości bez ustanawiania połączenia między końcowymi hostami. Nie zapewnia dostarczenia, kolejności ani ochrony przed duplikatami, a jego nagłówek zawiera niewiele informacji sterujących. Aplikacja wybiera UDP, gdy może określić własną obsługę strat i gdy starsza wiadomość ma mniejszą wartość od nowszej.
Te aplikacje czasu rzeczywistego przypisują termin każdej jednostce mediów lub stanu. Klatka wideo, która nie zdążyła do czasu odtwarzania, albo stara pozycja gracza ma zwykle małą wartość. Odbiornik może ukryć stratę, interpolować próbkę lub pominąć aktualizację i kontynuować pracę z nowszymi danymi. Aplikacja korzystająca z UDP w Internecie musi także sterować szybkością wysyłania, ponieważ UDP nie ma własnego mechanizmu kontroli przeciążenia.
IP może odrzucić, zduplikować lub zmienić kolejność datagramów przed ich dotarciem do celu. UDP przekazuje odebrany datagram do gniazda wybranego na podstawie portu docelowego oraz udostępnia aplikacji adres i port źródłowy. Suma kontrolna wykrywa wiele błędów transmisji, lecz nie wskazuje nadawcy sposobu naprawy brakującej wiadomości.
Protokoły aplikacyjne dobierają także rozmiar wiadomości i sposób ich wysyłania. Datagram większy od możliwości ścieżki może zostać pofragmentowany albo odrzucony, a seria datagramów UDP może konkurować z innymi przepływami bez zachowania uczciwego podziału pasma. Wdrożenie łączy więc obsługę terminów i strat z limitem rozmiaru, regułami ponawiania oraz szybkością reagującą na przeciążenie.
Komunikacja głosowa i wideo w czasie rzeczywistym (VoIP, wideokonferencje)
Systemy głosowe i wideo, takie jak Skype, Zoom, Google Meet czy Discord, często używają RTP albo ścieżek medialnych WebRTC działających przez UDP. Przy ograniczeniach sieciowych mogą korzystać z innych transportów, dlatego wybór zależy od protokołu mediów i sposobu wdrożenia.
Retransmisja TCP a media interaktywne
Interaktywny dźwięk i obraz mogą lepiej tolerować krótką stratę niż późniejszą naprawę. Kodek mowy może ukryć brakującą próbkę, a dekoder obrazu może kontynuować pracę z późniejszą klatką. Uporządkowany strumień bajtów, który czeka na wcześniejszy segment, opóźnia dane zaplanowane do odtworzenia.
TCP retransmituje brakujące bajty i zachowuje ich kolejność. Takie działanie służy kompletnemu plikowi, lecz może powodować opóźnienie kolejnych danych strumienia mediów. Aplikacja nadal musi dostarczyć każdą jednostkę audio lub wideo przed terminem odtwarzania, więc późna retransmisja może zostać odrzucona przez warstwę mediów.
Jak UDP wspiera komunikację w czasie rzeczywistym
UDP pozwala aplikacji medialnej ustalić kompromis między stratą, opóźnieniem i naprawą. Nadawca VoIP koduje mowę w małe jednostki i umieszcza je w datagramach UDP, a odbiornik decyduje, jak obsłużyć jednostki spóźnione lub przychodzące poza kolejnością.
- Mniejsze opóźnienie protokołu: UDP nie ustanawia połączenia transportowego i nie retransmituje utraconego datagramu. Opóźnienie propagacji i kolejek nadal zależy od ścieżki, lecz transport nie zatrzymuje późniejszej wiadomości w oczekiwaniu na wcześniejszą.
- Kontrola w warstwie aplikacji: Stos mediów obsługuje straty przez maskowanie, interpolację, wybiórczą naprawę albo pominięcie jednostki. Utrata datagramu głosowego nie musi zatrzymywać reszty strumienia w oczekiwaniu na retransmisję.
- Obsługa Jittera: Aplikacje czasu rzeczywistego działające na UDP często implementują po stronie odbiorczej. Bufor opóźnia odtwarzanie o ustaloną wartość, aby pakiety przychodzące w tym oknie można było zwalniać zgodnie z zegarem mediów. Pakiety przychodzące po terminie są zwykle maskowane lub odrzucane.
RTP (Real-time Transport Protocol) jest często przenoszony przez UDP. Typ ładunku, numer sekwencyjny i znacznik czasu pozwalają odbiornikowi rozpoznać media, wykrywać straty i planować odtwarzanie. RTP nie gwarantuje dostarczenia ani jakości usług.
Transmisja mediów na żywo
Transmisja wydarzeń sportowych i interaktywnych, na przykład stream na Twitchu, ma określony budżet opóźnienia. Ścieżki medialne oparte na RTP mogą używać UDP, gdy aplikacja akceptuje straty i sama obsługuje czas odtwarzania. Dostarczanie przez przeglądarkę za pomocą HLS lub DASH korzysta z HTTP, który może działać przez TCP albo przez QUIC z HTTP/3.
Terminy odtwarzania mediów na żywo
Klatka, która jest już spóźniona, nie poprawi bieżącej pozycji odtwarzania. W uporządkowanym strumieniu odzyskanie wcześniejszego segmentu może opóźnić późniejsze bajty i zwiększyć opóźnienie transmisji na żywo. Protokół mediów akceptujący straty może przejść do późniejszej klatki.
Ścieżka medialna UDP może pominąć utraconą klatkę i wyświetlić następną możliwą do zdekodowania. Wynikiem może być krótka przerwa obrazu albo artefakt dekodera, przy zachowaniu mniejszego opóźnienia względem wydarzenia. Takie działanie wynika z protokołu mediów i jego polityki odzyskiwania po stratach, a UDP nie zapewnia go samodzielnie.
Wideo na żądanie, na przykład standardowy YouTube albo Player.pl, ma inny cel. Klient może buforować segmenty i pobierać je ponownie, dlatego usługi często używają HTTP przez TCP albo HTTP/3 przez QUIC. Kilka sekund początkowego buforowania może być lepsze od widocznej przerwy w zapisanym programie.
Gry online i aktualizacje stanu
Szybkie gry online, w tym strzelanki pierwszoosobowe i gry wyścigowe, często wysyłają częste aktualizacje stanu przez UDP. Inne gry używają TCP albo niezawodnego transportu, gdy ich protokół wymaga uporządkowanego dostarczania. W grach, często szacuje się za pomocą pomiaru czasu obiegu zwanego pingiem. Jest to jeden z kilku parametrów interakcji, obok strat, jittera, czasu przetwarzania serwera i częstotliwości aktualizacji.
Wybór niezawodności dla stanu gry
Serwer gry stale synchronizuje stan świata, w tym pozycje graczy, działania i trajektorie pocisków. Wysyła strumień małych aktualizacji, których użyteczność maleje wraz ze starzeniem się stanu.
Załóżmy, że strzelanka traci aktualizację opisującą oddanie strzału. Przy TCP uporządkowane dostarczanie może opóźnić późniejszy stan do czasu nadejścia brakujących bajtów. Zdarzenie może wtedy opisywać nieaktualną pozycję świata. Protokół datagramowy pozwala odebrać nowszy stan i zastosować własną regułę potwierdzania zdarzeń.
Gra może wysyłać częste aktualizacje i stosować najnowszą prawidłową pozycję. Jeśli jednorazowe zdarzenie wymaga dostarczenia, program może dodać numerację sekwencyjną, potwierdzenia i retransmisję dla tego zdarzenia, pozostawiając zwykłe aktualizacje dopuszczające straty. UDP dostarcza datagramy, a aplikacja definiuje te reguły oraz kontrolę przeciążenia.
Inne protokoły oparte na UDP
UDP jest także używany przez protokoły infrastruktury, które wymieniają krótkie wiadomości albo muszą działać przed pełną konfiguracją adresu hosta. Każdy z tych protokołów definiuje własne zasady ponawiania, integralności i kontroli przeciążenia.
DNS (System Nazw Domenowych)
Gdy przeglądarka szuka adresu dla www.google.com, resolver zwykle wysyła zapytanie do serwera przez port UDP 53 i otrzymuje odpowiedź. W typowym przypadku zapytanie i odpowiedź są dwiema wiadomościami, lecz w innych sytuacjach DNS może używać TCP, DNS over HTTPS albo DNS over TLS. Resolver obsługuje stratę przez limit czasu i ponowienie.
DHCP (Dynamic Host Configuration Protocol)
Podczas konfiguracji adresu klient DHCP może nie znać jeszcze swojego adresu ani adresu serwera. DHCP używa więc wiadomości UDP oraz emisji rozgłoszeniowej albo przekazywania przez relay, aby odnaleźć serwer. Komunikat odkrywania może pytać: „Czy jest tu serwer DHCP, który może przydzielić adres IP?”. Przypisane porty to 67 dla serwerów i 68 dla klientów. Ta wymiana startowa nie wymaga wcześniejszego połączenia TCP.
NTP (Network Time Protocol)
NTP synchronizuje zegary za pomocą krótkich wymian wiadomości UDP zawierających znaczniki czasu. Protokół wykorzystuje je do oszacowania opóźnienia i przesunięcia zegara. UDP dostarcza transport wiadomości, a NTP definiuje własne żądania, odpowiedzi i ponawianie.
TFTP (Trivial File Transfer Protocol)
TFTP to prosty protokół transferu plików działający przez UDP. W porównaniu z FTP nie zapewnia wbudowanej poufności ani uwierzytelniania, a jego transfer blokowy wymaga potwierdzenia każdego bloku i wykorzystuje limity czasu oraz komunikaty błędów. Ten niewielki protokół stosuje się między innymi do uruchamiania stacji roboczych bez dysku i przesyłania oprogramowania układowego w kontrolowanej sieci.
Niezawodność w warstwie aplikacji nad UDP
UDP nie określa, jak aplikacja obsługuje straty. Protokół zbudowany nad UDP może dodać numery sekwencyjne, potwierdzenia, liczniki retransmisji i kontrolę przeciążenia, gdy wiadomości wymagają tych właściwości.
Gra online może potwierdzać jednorazowe zdarzenie, a pozycje graczy wysyłać jako zastępowalne aktualizacje. Każdy typ wiadomości otrzymuje wtedy własną regułę dostarczania, zamiast jednej reguły dla całego strumienia. Aplikacja musi poprawnie zaimplementować te mechanizmy i respektować wymagania kontroli przeciążenia w Internecie.
Przykładem protokołu transportowego zbudowanego na UDP jest QUIC. Nazwa QUIC nie jest akronimem. Protokół zapewnia niezawodne strumienie, odzyskiwanie po stratach, kontrolę przepływu, kontrolę przeciążenia i uzgadnianie oparte na TLS, a HTTP/3 używa go jako transportu. Na przykład gra może retransmitować wiadomości czatu, a pozycje graczy traktować jako zastępowalne aktualizacje. Aplikacja może więc ustalić różne reguły dostarczania dla mediów, komunikatów sterujących i danych masowych w jednym rozwiązaniu.