R08-5, Rozdział 9


Rozdział 8.
Protokół datagramów użytkownika (UDP)

Dogłębnie

Protokół datagramów użytkownika (UDP) jest wymaganym standardem TCP/IP określonym w specyfikacji RFC 768. Jest to --> zawodny protokół, który zapewnia [Author:PO] bezpołączeniową usługę wykorzystującą dostępne możliwości i nie gwarantuje dostarczenia, ani sprawdzenia sekwencji wszystkich datagramów. Może być wykorzystywany do emisji pojedynczej typu jeden do jednego, albo do komunikacji typu jeden do wielu, które używają datagramów IP emisji lub multiemisji. Praca w sieci Microsoft wykorzystuje protokół UDP do logowania, przeglądania i rozpoznawania nazw. Protokół używany jest do szybkiego dostarczania małych komunikatów do jednego lub wielu odbiorców oraz do komunikacji, gdzie szybkość dostarczania jest ważniejsza niż niezawodność (jak ruch multimediów czasu rzeczywistego).

Jako że dostarczanie datagramów UDP nie jest gwarantowane, aplikacje korzystające z UDP muszą zaopatrzyć się we własne mechanizmy zapewniające niezawodność. Jeżeli dana sieć jest przeciążona, pakiety UDP mogą ulegać zagubieniu, przy czym nie ma mechanizmu ich odzyskiwania. W bardzo ruchliwej sieci, która ma wysoki poziom gwarantowanego ruchu protokołu TCP jest więc możliwe, że pakiety UDP będą „wypychane” i że straty w ruchu staną się nie do przyjęcia. Jest to problem szczególny w przypadku aplikacji, które opierają się na ruchu sieciowym w czasie rzeczywistym, gdzie opóźnienia związane z protokołem TCP są niedopuszczalne, ale dopuszczalny jest pewien poziom utraty danych. Musi więc zostać zastosowany mechanizm, który zarówno rezerwuje szerokość pasma, jak i umożliwia współistnienie ruchu czasu rzeczywistego oraz ruchu tradycyjnego w tej samej sieci. Jakość usługi (QoS) zapewnia taki mechanizm przy zastosowaniu usługi kontroli wpływu danych Jakości usługi.

Protokół datagramów użytkownika (UDP)

Podobnie jak protokół TCP, protokół UDP opiera się na protokole IP w kwestii routingu i jest rozpoznawany po wartości równej 17 (dziesiętnej) w polu Protokół nagłówka IP (patrz: specyfikacja RFC 1700). Komunikaty protokołu UDP są kapsułowane i wysyłane wewnątrz datagramów IP. Protokół ten jest protokołem transakcyjnym i bezpołączeniowym i nie ustanawia sesji pomiędzy hostami, ani nie inicjuje żadnych procedur uzgadniania. UDP zapewnia IP następujący zestaw funkcji dodatkowych:

Numery portów — UDP zapewnia 16-bitowe numery portów, aby wiele procesów mogło korzystać z usług UDP na jednym hoście. Adres UDP jest połączeniem adresu IP i 16-bitowego numeru portu.

Sumy kontrolne — UDP wykorzystuje sumy kontrolne dla zapewnienia integralności danych. Algorytm sumy kontrolnej jest taki sam, jak ten, z którego korzysta protokół TCP (patrz: rozdział 7). Jeżeli suma kontrolna jest niewłaściwa, to pakiet jest odrzucany i nie są podejmowane żadne dalsze działania.

Wskazówka: W przeciwieństwie do protokołu TCP stosowanie protokołu UDP nie jest obowiązkowe. Niektóre aplikacje, które zazwyczaj działają tylko w sieciach lokalnych (LAN), wyłączają obliczanie sumy kontrolnej poprzez wysyłanie wartości zero w polu Suma kontrolna. Nie uważa się jednak, aby było to dobrą praktyką. Ogólnie rzecz biorąc brak informacji jest lepszy niż złe informacje.

Protokół UDP wykorzystywany jest tam, gdzie protokół TCP jest zbyt złożony lub zbyt powolny. Nie segmentuje on komunikatu, nie składa go ponownie po drugiej stronie i nie sprawdza, czy segmenty są we właściwej kolejności. Jest on więc nieodpowiedni do dostarczania długich komunikatów. Aplikacje sieciowe wymieniające małe jednostki danych (i w związku z tym mające --> do wykonania niewiele ponownego składania[Author:PO] komunikatów), wykorzystują protokół UDP zamiast TCP. Na przykład protokół transferu plików podstawowych (TFTP) korzysta z UDP przy małych aplikacjach.

Porty UDP

Porty UDP zapewniają lokalizację do wysyłania i odbierania komunikatów UDP. Port UDP funkcjonuje jako pojedyncza kolejka komunikatów, która służy do odbierania wszystkich datagramów dla programu określonego za pomocą numeru portu protokołu. Oznacza to, że programy UDP mogą jednocześnie odbierać kilka komunikatów. Programy po stronie serwera, które wykorzystują porty TCP, nasłuchują komunikatów przychodzących pod dobrze znany numer portu. Wszystkie numery portów serwerów TCP o wartościach mniejszych niż 1024 (oraz niektóre wyższe numery) są zarezerwowane i zarejestrowane przez organizację przydzielania numerów internetowych (IANA).

Tabela 8.1 podaje najczęściej używane dobrze znane numery portów serwerów UDP. Listę wszystkich zarezerwowanych numerów portów UDP można uzyskać pod adresem www.isi.edu/in-notes/iana/assignments/port-numbers.

Rozpoznawanie nazw

Rozwiązywanie nazw NetBIOS odbywa się poprzez port UDP 137 albo za pomocą emisji pojedynczej do serwera nazw NetBIOS, albo też za pomocą emisji podsieci. Kwerendy dotyczące przetłumaczenia nazwy hosta DNS na adres IP wykorzystują port UDP 53. Obie te usługi korzystają ze swoich własnych schematów retransmisji, jeżeli nie otrzymają żadnej odpowiedzi na zapytania. Ponieważ datagramy emisji UDP nie są normalnie przekazywane poprzez routery IP, rozwiązywanie nazw NetBIOS w środowisku routowanym wymaga albo serwera nazw, albo plików statycznej bazy danych.

Tabela 8.1. Numery portów UDP

Numer portu UDP

Opis

53

Zapytania o nazwę systemu nazw domen (DNS)

69

TFTP

137

Obsługa nazw NetBIOS

138

Obsługa datagramów NetBIOS

161

Protokół prostego zarządzania siecią (SNMP)

520

Protokół routingu internetowego (RIP)

Skrzynki mailslot

Skrzyka mailslot to drugorzędny, zawodny mechanizm służący do wysyłania komunikatu z jednego komputera do drugiego przy użyciu protokołu datagramów użytkownika (UDP), gdzie oba komputery są identyfikowane po ich nazwach NetBIOS. Komunikaty mailslot mogą być emitowane w podsieci lub kierowane do hosta zdalnego. Aby skierować komunikat mailslot, musisz mieć jakąś metodę rozpoznawania nazw NetBIOS, taką jak usługa nazw internetowych systemu Windows (WINS).

Łączność międzywarstwowa UDP

Podobnie jak TCP, UDP znajduje się w warstwie transportu czterowarstwowego modelu TCP/IP. Jeżeli otrzyma jakiekolwiek opcje IP (takie jak Trasa źródłowa, Trasa rekordu oraz Znacznik czasu) od protokołu IP w warstwie internetowej, to przekazuje je jawnie do warstwy aplikacji. UDP zazwyczaj nie przyjmuje żadnych założeń dotyczących formatu, albo zawartości opcji, które przekazuje do, albo od aplikacji. Przekazuje również do warstwy aplikacji wszystkie komunikaty o błędach protokołu ICMP.

Po otrzymaniu datagramu UDP jego adres określonego miejsca docelowego zostaje przekazany w górę do warstwy aplikacji. Program użytkowy albo określa źródłowy adres IP, który ma zostać użyty do wysłania datagramu UDP, albo pozostawia ten adres nieokreślony; w tym wypadku oprogramowanie do pracy sieciowej wybiera odpowiedni adres źródłowy. Kiedy dany host wysyła datagram UDP, to adres źródłowy jest adresem źródłowym hosta (albo jednym z adresów, jeżeli host ma wiele podłączeń).

Struktura pakietów UDP

Rysunek 8.1, uzyskany z pliku przechwytywania login.cap na CD-ROM, przedstawia datagram UDP. Struktura pakietu jest następująca: