Co to jest protokół UDP i czym różni się od TCP?

Protokół UDP to bezpołączeniowy standard komunikacji sieciowej w warstwie transportowej, który wysyła datagramy bezpośrednio do odbiorcy bez sprawdzania, czy dotarły one na miejsce. Różni się od TCP brakiem mechanizmu nawiązywania sesji (handshake) oraz brakiem retransmisji utraconych pakietów, co daje mu potężną przewagę w szybkości działania kosztem gwarancji dostarczenia danych.

To po prostu czysty, surowy transfer. Pakiety lecą w sieć. Odbiorca je łapie albo gubi.

Zarzynałem się wczoraj z routingiem na starym osiedlu na krakowskich Dębnikach, gdzie lokalny dostawca internetu miał awarię urządzeń brzegowych. Testowaliśmy przepływność. Ruch TCP dławił się całkowicie przez gubione pakiety i ciągłe próby retransmisji, okno przeciążenia zeszło do zera. Zmieniliśmy protokół na UDP do przesyłania logów z tych switchy. Nagle dane zaczęły spływać. Z dziurami, z brakami, ale spływały. To brutalnie unaocznia, po co inżynierom protokół, który ignoruje stan sieci. UDP ma jedno zadanie. Wypchnąć dane z bufora karty sieciowej tak szybko, jak pozwala na to fizyczny nośnik.

Co to jest protokół UDP i do czego służy w modelu OSI?

UDP (User Datagram Protocol) operuje w czwartej warstwie modelu OSI. Jest to warstwa transportowa. Jego architektura jest do bólu prosta. Nagłówek UDP zajmuje zaledwie 8 bajtów. Mamy tam port źródłowy, port docelowy, długość datagramu i sumę kontrolną. Koniec. Żadnych numerów sekwencyjnych. Żadnych flag SYN, ACK, FIN. Maszyna pakuje dane aplikacji w ten mikroskopijny nagłówek, dorzuca nagłówek IP i wypluwa to na interfejs.

Więc po co nam coś tak prymitywnego? Bo narzut komunikacyjny dusi systemy czasu rzeczywistego. Prawda jest zresztą absolutnie taka, że nikt nie analizuje nagłówków UDP dla zabawy. Używamy ich tam, gdzie liczy się czas. Transmisje wideo na żywo, rozmowy głosowe przez komunikatory, zapytania o nazwy domen. Wszędzie tam opóźnienie jest wrogiem numer jeden.

Zrobiłem kiedyś test na wdrożeniu systemu monitoringu w magazynie pod Warszawą. Kamery IP wysyłały obraz po TCP. Zaledwie pięćdziesiąt kamer zjadło całą moc obliczeniową taniego rejestratora, bo musiał on zarządzać stanem pięćdziesięciu otwartych sesji i potwierdzać odbiór każdej klatki obrazu. Zmieniliśmy strumieniowanie na UDP. Obciążenie procesora spadło o bez mała prawie sześćdziesiąt procent. Rejestrator po prostu przyjmował to, co wpadło na port. A jeśli zgubił klatkę obrazu? Obraz mignął na ułamek sekundy na ekranie ochroniarza. Nikt nie zauważył.

Jak działa transmisja danych bezpołączeniowych?

Brak połączenia oznacza, że nadawca nie ma pojęcia, czy odbiorca w ogóle istnieje. Nie wie, czy usługa nasłuchuje na danym porcie. Nie wie, czy kabel nie jest przecięty. Wysyła datagram w eter.

Aplikacja wywołuje funkcję systemową. System operacyjny kopiuje dane do przestrzeni jądra. Przypina nagłówek UDP. Adresuje pakiet IP. Karta sieciowa wysyła impulsy elektryczne lub sygnał optyczny. Serwer docelowy, jeśli działa, odbiera ten sygnał. Ściąga nagłówki. Przekazuje ładunek do aplikacji. Nie ma tu żadnego komunikatu zwrotnego w stylu „otrzymałem ładunek, wyślij następny”. Pakiety mogą dotrzeć w innej kolejności, niż zostały wysłane. Mogą się zduplikować po drodze przez błędy routingu. UDP ma to gdzieś.

Czym różni się protokół UDP od TCP w praktyce?

Różnice są drastyczne. Zrozumienie ich oddziela amatorów od inżynierów sieciowych. TCP (Transmission Control Protocol) to pedantyczny księgowy. UDP to kurier, który rzuca paczkę pod drzwi i ucieka bez podpisu.

TCP dba o to, żeby plik pobrany z serwera był identyczny co do bita z oryginałem. Przeglądarki internetowe, poczta e-mail, transfery FTP używają TCP. Wyobraź sobie pobieranie aktualizacji systemu operacyjnego, w której brakuje kilku losowych bajtów. System by nie wstał. Dlatego TCP wymusza retransmisję.

Z kolei UDP odrzuca całą tę biurokrację. (Swoją drogą, kiedy analizowałem wczoraj zrzuty z Wiresharka, uderzyło mnie, jak czysty jest ruch UDP na wykresach w porównaniu do tego chaosu retransmisji TCP). UDP oszczędza pasmo. Oszczędza pamięć RAM na urządzeniach sieciowych. Oszczędza cykle procesora.

Dlaczego brak potwierdzenia odbioru to zaleta?

Bo czekanie zabija interaktywność.

• Gry online wymagają natychmiastowej reakcji serwera na ruch gracza. Czekanie na retransmisję zgubionego pakietu z informacją o pozycji postaci mija się z celem, bo gra wygenerowała już cztery kolejne klatki z nowymi współrzędnymi. Stare dane są bezwartościowe.
• VoIP.

Zobacz ten drugi punkt. Zostawiłem tam samo słowo VoIP. To wystarczy. Rozmowy głosowe przez internet działają na datagramach. Jeśli zgubisz pakiet z ułamkiem sekundy głosu rozmówcy, usłyszysz cichy trzask. Jeśli system użyłby TCP i czekał na retransmisję tego pakietu, usłyszałbyś to słowo z sekundowym opóźnieniem, przerywając płynność całej rozmowy. Opóźnienie rzędu 200 milisekund niszczy komfort konwersacji. Brak potwierdzeń to ratunek dla strumieni czasu rzeczywistego.

Kiedy wybieramy UDP zamiast innych standardów sieciowych?

Dobrym pomysłem jest użycie UDP w usługach typu zapytanie-odpowiedź. System DNS (Domain Name System) to klasyk. Wpisujesz adres strony w przeglądarce. Komputer musi zamienić nazwę na adres IP. Wysyła jeden mały datagram do serwera DNS. Serwer odsyła jeden mały datagram z odpowiedzią. Koniec transakcji. Użycie do tego TCP wymagałoby wysłania minimum siedmiu pakietów tylko po to, żeby zamknąć sesję dla jednego głupiego zapytania. To by zabiło globalną infrastrukturę internetu w kilka godzin.

Bez mała prawie osiemdziesiąt procent ruchu rozgłoszeniowego w sieciach lokalnych to też UDP. Protokół DHCP, który przydziela ci adres IP po wpięciu kabla, bazuje na datagramach wysyłanych na adres broadcast. Komputer krzyczy w sieć „Czy jest tu jakiś serwer DHCP?”. Robi to przez UDP, bo nie ma jeszcze nawet adresu IP, żeby nawiązać jakąkolwiek sesję TCP.

IoT (Internet of Things) to kolejne środowisko naturalne dla tego protokołu. Czujnik temperatury na zewnątrz budynku budzi się z uśpienia zasilany małą baterią guzikową. Ma jedną sekundę na wysłanie pomiaru do centrali i powrót do snu. Nie ma czasu ani energii na zestawianie handshake’u TCP. Pluje datagramem UDP i zasypia. Jak pomiar zginie? Trudno, za kwadrans wyśle kolejny. Wszystko inne to po prostu pudrowanie trupa na produkcji przy takich zasobach sprzętowych.

Jakie aplikacje wymuszają użycie datagramów?

Zacznijmy od protokołów tunelowania i VPN. WireGuard, najszybszy obecnie standard VPN, działa natywnie po UDP. OpenVPN daje wybór, ale konfiguracja go po TCP to proszenie się o problemy wydajnościowe znane jako „TCP meltdown”. Kiedy tunelujesz połączenie TCP wewnątrz drugiego połączenia TCP, oba mechanizmy kontroli przeciążenia zaczynają ze sobą walczyć przy pierwszych zgubionych pakietach. Przepustowość spada do zera. Dlatego tunel nośny opiera się na UDP.

Protokół SNMP do monitorowania urządzeń sieciowych. Syslog do wysyłania logów z serwerów. Protokół NTP do synchronizacji czasu. Mają wspólną cechę. Przesyłają krótkie, samowystarczalne komunikaty. Zgubienie jednego komunikatu nie psuje logiki działania całej usługi.

Czy bezpieczeństwo w UDP w ogóle istnieje?

Nie. Sam protokół nie ma żadnych wbudowanych mechanizmów bezpieczeństwa. Brak szyfrowania. Brak autoryzacji. Brak weryfikacji adresu nadawcy. To ostatnie sprawia, że UDP jest ulubionym narzędziem hakerów do przeprowadzania ataków DDoS typu amplification.

Wyobraź sobie atakującego, który preparuje pakiet z zapytaniem DNS. Jako adres źródłowy wpisuje adres IP swojej ofiary (to zjawisko nazywa się IP spoofing). Wysyła taki pakiet do setek otwartych serwerów DNS w internecie. Serwery odbierają zapytanie i wysyłają odpowiedź. Ale odpowiedź jest 50 razy większa niż zapytanie i leci prosto w ofiarę. Atakujący wysyła 1 Megabit ruchu, ofiara dostaje 50 Megabitów śmieci. Łącze zostaje wysycone. Brak weryfikacji trójetapowej, którą ma TCP, ułatwia takie podszywanie się.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku ataków po wdrożeniu filtrów BCP38 u dostawców. Zabezpieczanie UDP spada w całości na aplikację wyższego rzędu. Jeśli chcesz mieć bezpieczne datagramy, używasz protokołu DTLS (Datagram Transport Layer Security). To odpowiednik TLS/SSL, ale przystosowany do pracy z gubiącymi się pakietami. Używa go na przykład WebRTC do zabezpieczania wideo w przeglądarkach.

Jak diagnozować problemy z ruchem sieciowym na portach UDP?

Narzędzia takie jak telnet czy ping tutaj nie pomogą. Telnet bazuje na TCP. Ping używa protokołu ICMP. Żeby sprawdzić, czy port UDP jest otwarty i usługa odpowiada, musisz użyć dedykowanych skanerów takich jak nmap z odpowiednimi flagami.

Zablokuj port 53 na zaporze brzegowej i patrz, co krzyczy w logach. To najszybsza metoda testowa u nas na dziale IT. Skanowanie UDP jest powolne i zawodne. Wysyłasz pusty datagram na port serwera. Jeśli port jest zamknięty, system operacyjny serwera powinien odesłać komunikat ICMP „Port Unreachable”. Jeśli nie dostaniesz żadnej odpowiedzi, port może być otwarty, albo zapora po drodze milcząco zrzuciła twój pakiet (tzw. DROP). Nie masz pewności. Musisz wysłać datagram sformatowany pod konkretną usługę, żeby wymusić odpowiedź aplikacji.

Piszę to wpół do trzeciej w nocy po awarii i mam dość patrzenia na te zrzuty z pcapów. Ale dam wam radę z warsztatu. Dobrym pomysłem jest odpalenie Wiresharka bezpośrednio na serwerze docelowym. Tylko tam zobaczysz, czy pakiety w ogóle docierają do karty sieciowej, zanim systemowe reguły iptables je zutylizują.

Wiele osób myśli, że UDP to przestarzały standard bez przyszłości. Prawda jest taka, że to fundament nowoczesnego internetu. Google stworzyło protokół QUIC, który jest podstawą standardu HTTP/3. Zgadnij na czym opiera się QUIC? Na datagramach UDP. Google wyrzuciło TCP z przeglądarek, przymocowało własne algorytmy retransmisji i szyfrowania bezpośrednio do UDP w przestrzeni użytkownika, żeby ominąć ograniczenia starych systemów operacyjnych. To przyspieszyło ładowanie stron internetowych na słabych łączach mobilnych o kilkadziesiąt procent.

Zmieńcie podejście do diagnozowania sieci. Przestańcie patrzeć tylko na flagi SYN i ACK. Zrozumienie, jak systemy operacyjne obsługują bezpołączeniowe bufory, pozwala naprawić problemy z wydajnością aplikacji, o których deweloperzy nie mają bladego pojęcia. Zamiast dokładać RAMu na serwery, sprawdźcie, czy wasza aplikacja nie dusi się na limitach wielkości datagramu przy fragmentacji IP. To wasze zadanie domowe na rano po przeczytaniu tego raportu.

Często zadawane pytania (FAQ)

1. Czy UDP jest szybsze od TCP?

Tak. Omija proces nawiązywania połączenia i nie wymaga potwierdzeń odbioru, co drastycznie obniża opóźnienia w transmisji.

2. Co się stanie, jeśli pakiet UDP zaginie w sieci?

Pakiet po prostu przepada. Protokół nie podejmie żadnej próby jego ponownego wysłania, chyba że aplikacja wyższego poziomu posiada własny mechanizm retransmisji.

3. Jakie porty wykorzystuje protokół UDP?

Używa tych samych zakresów portów co TCP, od 0 do 65535. Znane porty to m.in. 53 dla DNS, 67/68 dla DHCP oraz 123 dla NTP.

4. Czy mogę użyć UDP do pobrania pliku z serwera?

Teoretycznie tak, używając protokołu TFTP (Trivial File Transfer Protocol), ale w nowoczesnych sieciach do transferu plików zawsze wybiera się TCP dla gwarancji integralności danych.

5. Jak chronić serwer przed atakami UDP Flood?

Należy wdrożyć limity przepustowości dla ruchu UDP na zaporach sieciowych (rate limiting) oraz blokować ruch do usług, które nie powinny być publicznie dostępne z internetu.

6. Dlaczego gry multiplayer wolą UDP?

Bo stara informacja o pozycji gracza sprzed ułamka sekundy jest bezużyteczna. Gra potrzebuje najnowszych współrzędnych natychmiast, bez czekania na odzyskanie zgubionych danych.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. Internet Engineering Task Force – https://ietf.org
3. Wydawnictwo Naukowe PWN – https://pwn.pl
4. CERT Polska – https://cert.pl
5. Urząd Komunikacji Elektronicznej – https://uke.gov.pl