Wprowadzenie do protokołu UDP
TCP zapewnia uporządkowany i niezawodny strumień bajtów, natomiast User Datagram Protocol (UDP) przesyła komunikaty jako niezależne datagramy. Nadawca przekazuje datagram do warstwy IP z adresem docelowym i portem. Odbiorca obsługuje każdy datagram jako oddzielną jednostkę, a UDP nie scala kolejnych datagramów w strumień bajtów. Sam UDP nie potwierdza odbioru ani nie retransmituje utraconych datagramów. Nie określa również ich kolejności, więc dwa datagramy wysłane kolejno mogą dotrzeć w innej kolejności, nie dotrzeć albo zostać powielone.
UDP należy do stosu protokołów internetowych i działa w warstwie transportowej, podobnie jak TCP. Zakres jego usług jest mniejszy, ponieważ protokół nie ustanawia połączenia i nie zapewnia niezawodnego, uporządkowanego strumienia. Udostępnia aplikacjom prosty mechanizm przesyłania wiadomości, zwanych , z jednej aplikacji do drugiej.
UDP ogranicza zakres usług transportowych do przesyłania datagramów, kontroli sumy i multipleksacji portów. Nie zapewnia niezawodności, kolejności ani kontroli przepływu znanej z TCP, dzięki czemu nie musi utrzymywać mechanizmów retransmisji i potwierdzeń. Prosty nagłówek i brak ustanawiania połączenia mogą ograniczać narzut oraz opóźnienie przetwarzania. Sam UDP nie gwarantuje szybkości ani niskiego opóźnienia. Aplikacje wrażliwe na opóźnienia, takie jak niektóre usługi transmisji wideo i gry online, mogą preferować brak automatycznej retransmisji i samodzielnie obsługiwać utratę danych w warstwie aplikacji. Taki model jest użyteczny wtedy, gdy aktualność danych ma większe znaczenie niż dostarczenie każdej ich części.
Cechy protokołu UDP
Zakres usług UDP obejmuje dostarczanie datagramów bez gwarancji, kontrolę sumy oraz multipleksację za pomocą numerów portów. Pozostałe funkcje, takie jak niezawodność, kolejność i kontrola przeciążenia, muszą zostać zapewnione przez aplikację lub protokół działający nad UDP, jeżeli są potrzebne.
- Bezpołączeniowy
UDP jest bezpołączeniowym protokołem transportowym. Sam protokół nie ustanawia połączenia przed wysłaniem danych i nie wykonuje trójetapowego uzgadniania charakterystycznego dla TCP. Aplikacja używająca UDP może utworzyć datagram, wskazać adres docelowy i port, a następnie przekazać go do sieci. Pierwszy datagram może zawierać dane aplikacji, ponieważ UDP nie wymaga transportowego uzgadniania połączenia.
Brak fazy ustanawiania połączenia usuwa wymianę komunikatów wymaganą przed przesłaniem danych przez TCP. Może to zmniejszyć opóźnienie początkowe i ograniczyć stan utrzymywany przez punkty końcowe, ale nie gwarantuje określonego czasu dostarczenia.
- Dostarczanie bez gwarancji w modelu best-effort
UDP udostępnia dostarczanie typu best-effort, czyli bez gwarancji powodzenia. Ani UDP, ani bazowa sieć IP nie gwarantują dostarczenia, braku duplikatów ani kolejności datagramów. Sam UDP nie zapewnia następujących mechanizmów:
- Potwierdzeń: UDP nie odsyła nadawcy potwierdzenia odebrania datagramu. Aplikacja może jednak zdefiniować własne komunikaty potwierdzające.
- Retransmisji: Jeśli datagram zaginie w tranzycie, UDP nie retransmituje go automatycznie. Odpowiedzialność za ponowne wysłanie może przejąć aplikacja.
- Porządkowania danych: Datagramy UDP są niezależnymi jednostkami. Jeśli nadawca wyśle datagram A, a potem B, sieć może dostarczyć B przed A, dostarczyć oba, nie dostarczyć żadnego albo dostarczyć duplikat. UDP nie porządkuje ich w miejscu docelowym.
- Niski narzut i proste przetwarzanie
Nagłówek UDP ma stały rozmiar 8 bajtów, podczas gdy podstawowy nagłówek TCP ma co najmniej 20 bajtów i zawiera więcej pól związanych z niezawodnym strumieniem. Przy tym samym ładunku UDP wymaga więc mniej danych sterujących na poziomie transportu, choć całkowita wydajność zależy także od aplikacji i sieci.
UDP nie wymaga od protokołu utrzymywania stanu połączenia, liczników retransmisji, śledzenia potwierdzeń ani mechanizmów okienkowych. Implementacja nadal może utrzymywać bufory i stan gniazd, lecz prostszy zakres usług często ogranicza koszt przetwarzania oraz opóźnienie obsługi datagramu.
- Brak wbudowanej kontroli przepływu i przeciążenia
UDP nie ma wbudowanych mechanizmów kontroli przepływu ani kontroli przeciążenia. Aplikacja może wysyłać datagramy bez mechanizmu, który automatycznie dopasowałby tempo do odbiorcy lub przepustowości ścieżki. Stałe tempo bywa potrzebne w niektórych zastosowaniach, lecz niekontrolowana transmisja może zwiększać przeciążenie i straty także dla innych przepływów. Aplikacje używające UDP powinny więc zaimplementować odpowiednią kontrolę tempa i przeciążenia.
Nagłówek UDP i jego pola
Nagłówek UDP zawiera cztery pola, każde o długości 16 bitów (2 bajty). Ich łączny, stały rozmiar wynosi 8 bajtów, po których umieszczane są dane aplikacji.
Szczegółowy opis pól
1. Port źródłowy (16 bitów)
To pole wskazuje port procesu wysyłającego. W TCP port uczestniczy w identyfikacji połączenia stanowego, natomiast w UDP jest opcjonalne i może mieć wartość zero, gdy nadawca nie potrzebuje odbierać odpowiedzi na ten port. W typowej wymianie jest jednak ustawione, ponieważ odbiorca może użyć go jako portu docelowego odpowiedzi. Gdy klient DNS wysyła zapytanie, serwer zwykle kieruje odpowiedź na port źródłowy z otrzymanego datagramu. Wartość zero nie wskazuje portu, na który można domyślnie wysłać odpowiedź.
2. Port docelowy (16 bitów)
To pole jest obecne w każdym nagłówku UDP, wskazuje port aplikacji odbiorczej i wraz z adresami IP uczestniczy w kierowaniu datagramu do właściwego punktu końcowego. Umożliwia UDP przeprowadzanie . System operacyjny odbiorcy wykorzystuje to pole wraz z kontekstem adresów i gniazd, aby dostarczyć datagram właściwej aplikacji spośród wielu uruchomionych procesów.
3. Długość (16 bitów)
To pole określa całkowitą długość datagramu UDP w bajtach. Długość ta obejmuje 8-bajtowy nagłówek UDP oraz długość danych aplikacji (ładunku). Minimalna możliwa wartość to 8, co odpowiada datagramowi UDP z pustym ładunkiem. W zwykłym datagramie maksymalna wartość pola wynosi 65 535 bajtów. Dla jumbogramu IPv6 RFC 2675 dopuszcza wartość zero w polu Length, a rzeczywistą długość wyznacza się z opcji Jumbo Payload. W obliczeniach sumy kontrolnej używa się wtedy długości rzeczywistej.
4. Suma kontrolna (16 bitów)
To pole zapewnia podstawowy mechanizm wykrywania błędów w nagłówku UDP i danych. Suma jest 16-bitowym dopełnieniem do jedności sumy dopełnieniowej nagłówka UDP, ładunku oraz specjalnego pseudo-nagłówka. Jeżeli liczba oktetów jest nieparzysta, do obliczeń dodaje się na końcu zerowy oktet. Gdy obliczony wynik jest równy zero, wysyła się wartość 0xFFFF, ponieważ zero w polu oznacza brak obliczonej sumy.
Pseudo-nagłówek nie jest przesyłany jako część datagramu. Zawiera źródłowy i docelowy adres IP, numer protokołu 17 oraz długość UDP. Uwzględnienie tych pól chroni przed zaakceptowaniem datagramu skierowanego do innego hosta lub zmienionego podczas przekazywania.
Sposób użycia sumy zależy od wersji IP.
- W IPv4 użycie sumy kontrolnej UDP jest opcjonalne. Jeżeli nadawca jej nie oblicza, pole ma wartość zero. Tryb bez sumy może ograniczyć koszt obliczeń, lecz zmniejsza ochronę przed uszkodzeniem danych. Odbiorca może skonfigurować odrzucanie datagramów bez sumy, a implementacja hosta musi domyślnie obliczać sumę.
- W IPv6 suma kontrolna UDP jest w zwykłym trybie obowiązkowa. IPv6 nie ma własnej sumy kontrolnej nagłówka, więc suma UDP obejmuje także pseudo-nagłówek IPv6. Nadawca musi ją obliczyć, a odbiorca odrzuca datagram z wartością zero. Wyjątek może dotyczyć określonych tuneli UDP, które spełniają wymagania trybu zerowej sumy dla IPv6.
Zastosowania UDP
UDP jest użyteczny w aplikacjach, w których aktualność danych ma większe znaczenie niż dostarczenie każdej wiadomości, albo w których aplikacja sama zarządza niezawodnością.
Aplikacje czasu rzeczywistego i streamingowe
Dla usług takich jak Voice over IP (VoIP), wideokonferencje i streaming wideo na żywo dane otrzymane z dużym opóźnieniem mogą być mniej użyteczne niż dane utracone. Retransmisja utraconego pakietu głosowego przez TCP mogłaby dotrzeć zbyt późno, aby odtworzyć go w rozmowie, i spowodować przerwę. Aplikacja może wtedy pominąć utracony pakiet i odtworzyć następny, akceptując drobne zakłócenie audio. UDP nie gwarantuje niskiego opóźnienia, lecz brak wymaganej przez protokół retransmisji może ułatwić obsługę danych w czasie rzeczywistym.
Gry online
W szybkich grach online często liczy się najnowsza informacja o pozycji lub działaniu gracza. Stary, retransmitowany pakiet zawierający pozycję sprzed pół sekundy może być nieaktualny i zwiększać opóźnienie obrazu. Wiele gier używa UDP i buduje nad nim własną logikę aktualizacji, numerowania oraz synchronizacji danych.
Proste protokoły zapytanie-odpowiedź
Protokoły z małym zapytaniem i małą odpowiedzią mogą korzystać z UDP. Przykładem jest System Nazw Domenowych (DNS). W typowym zapytaniu klient wysyła datagram UDP z nazwą domeny, a serwer odpowiada datagramem zawierającym dane odpowiedzi, na przykład adres IP. Jeżeli datagram zaginie, resolver może odczekać limit czasu i wysłać zapytanie ponownie. Ustanawianie i zamykanie połączenia TCP byłoby dodatkowym kosztem dla takiej wymiany, choć DNS może również korzystać z TCP w sytuacjach określonych przez specyfikację. Innym przykładem jest DHCP.
Usługi multicast i broadcast
UDP jest często używany w usługach multicast i broadcast, w których jeden datagram może trafić do wielu miejsc docelowych. TCP nie zapewnia bezpośrednio transmisji jeden-do-wielu, dlatego nie służy do natywnego IP multicast ani broadcast. Bezpołączeniowy model UDP pozwala nadawcy wysyłać jeden strumień datagramów, a mechanizmy multicast mogą powielać go w sieci na gałęziach prowadzących do odbiorców. Broadcast jest zwykle ograniczony do lokalnej podsieci.
Mechanizmy niezawodności nad UDP
UDP nie zapewnia potwierdzeń, retransmisji ani uporządkowania datagramów. Jeżeli aplikacja wymaga takich funkcji, musi zastosować je w protokole działającym nad UDP albo wybrać transport, który je udostępnia.
Protokół aplikacyjny może wprowadzić numery sekwencyjne, potwierdzenia i retransmisje tylko dla wybranych danych. W grze sieciowej wiadomości tekstowe mogą podlegać retransmisji, podczas gdy nieaktualne pozycje graczy mogą zostać pominięte na rzecz nowszych danych.
Przykładem protokołu transportowego działającego nad UDP jest QUIC. RFC 9000 określa, że nazwa QUIC nie jest akronimem. QUIC ustanawia stanowe połączenie, a jego pakiety są przenoszone w datagramach UDP. Protokół udostępnia uporządkowane, niezawodne strumienie, mechanizmy odzyskiwania po utracie danych i kontrolę przeciążenia, a uzgadnianie zabezpieczeń integruje z TLS 1.3. RFC 9221 definiuje również ramki DATAGRAM dla danych aplikacyjnych bez retransmisji, przy zachowaniu kontroli przeciążenia QUIC. HTTP/3 korzysta z QUIC jako protokołu transportowego.