Sieci komputerowe | 04. Protokoły warstwy transportowej

Protokół UDP

Damian Stelmach

Innym protokołem realizującym niektóre funkcje warstwy transportowej jest protokół UDP. W jego przypadku, jest jednak zdecydowanie łatwiej, dlatego, że w tym protokole nie zaimplementowano mechanizmów gwarantujących niezawodność w dostarczeniu danych czy też kontroli przepływu.

Protokół UDP jest prostym, bezpołączeniowym protokołem, którego największą zaletą jest niewielki narzut danych sterujących, dodawanych w procesie enkapsulacji. UDP w datagramie dodaje tylko 8 bajtów danych sterujących. Nagłówek datagramu UDP wygląda tak:

• Port źródłowy – określa port aplikacji, z której wysłano dane.
• Port docelowy – określa port aplikacji, do której wysłano dane.
• Długość – 16 – bitowe pole określające długość całego datagramu UDP
• Suma kontrolna – 16 – bitowe pole służące do sprawdzania poprawności przesłanych danych.

Bezpołączeniowość protokołu UDP polega na tym, iż przed rozpoczęciem procesu komunikacji host źródłowy nie wysyła do hosta docelowego żadnych informacji zestawiających to połączenie. Zasada jest taka, jeśli urządzenie źródłowe chce rozpocząć transmisję, chce wysłać dane po prostu to robi, bez wcześniejszego ustalenia.

Jeśli porównalibyśmy to do komunikacji ludzkiej to w przypadku protokołu TCP było by tak: Hej, Tomek, skup się, bo zaraz będę do Ciebie coś mówił, i dopiero po tym komunikacie rozpocząłbym właściwą rozmowę, oczywiście tylko wtedy kiedy Tomek odpowiedziałby mi komunikatem: ok, zaczynam słuchać. W przypadku UDP nie informuje Tomka, że zaraz zacznę przekazywać mu coś ważnego, po prostu zaczynam konwersację.

Aplikacje czy też usługi korzystające z tego protokołu transportowego to DNS, DHCP, telefonia VoIP, czy streaming video.

Dlaczego akurat te? No odpowiedź jest dość prosta, są to aplikacje, które nad niezawodność komunikacji, a właściwie powinienem powiedzieć nad konieczność odebrania całości danych, tak jak zostały one wysłane cenią sobie szybkość. Wyobraźmy sobie sytuację, kiedy oglądamy transmisje wideo czy gramy z kumplem, powiedzmy w CS’a. Trudno byłoby rywalizować w grze czy coś oglądać, kiedy to pakiety przychodziłyby z dużym opóźnieniem.

Ktoś zapyta: no ale skąd to opóźnienie miałoby się brać? No stąd chociażby, że segmenty TCP są sporo większe niż datagramy UDP, no i TCP wymaga potwierdzenia dostarczanych danych, dlatego też ich ilość przesyłana przez sieć jest spora, większa niż w UDP.

W przypadku aplikacji wykorzystujących ten właśnie protokół toleruje się to, że czasem jakiś pakiet może zostać utracony, bądź uszkodzony. W przypadku usługi DNS, jeśli datagram się zgubi to po prostu zostaje jeszcze raz wysłane zapytanie do serwera DNS, jeśli podczas telekonferencji jakiś datagram nie dotrze to też nie będzie tragedii, bo zawsze komunikat można powtórzyć. W przypadku aplikacji korzystających z TCP utrata czy zagubienie akceptowalne już nie jest. Datagramy odbierane są w takiej kolejności w jakiej zostały odebrane, a jeśli jest ich dużo, to za ich odpowiednie poskładanie odpowiada już konkretna aplikacja.