2

Protokół UDP – charakterystyka i nagłówek

Protokół UDP ulokowany w warstwie transportowej jest protokołem bezpołączeniowym. Oznacza to iż przygotowuje dane do wysłania i po prostu je wysyła. Nie zestawia sesji z hostem docelowym przed wysłaniem danych. Nie wie nawet czy urządzenie docelowe jest dostępne w sieci. Po prostu wysyła dane i nie troszczy się o żadne potwierdzenia, ani śledzenie transmisji. Takie zubożenie funkcji w porównaniu do protokołu TCP sprawia iż nagłówek UDP został zmniejszony do minimum. Jego rozmiar wynosi 8B i został przedstawiony poniżej. Ze względu na wymienione cechy, idealnie nadaje się do aplikacji podatnych na opóźnienia czy z wymaganiami na szerokość pasma. Segmenty przesyłane przy użyciu protokołu UDP są często nazywane datagramami.

protokół udp nagłówek

Nagłówek protokołu UDP składa się z czterech dwu bajtowych pól, są to:

  • Pole port źródłowy oraz port docelowy, które mówią z jakiej aplikacji dane pochodzą i do jakiej aplikacji / usługi dane są przeznaczone
  • Pole długość, które oznacza długość datagramu. Jest to nagłówek UDP + dane warstwy aplikacji, jego minimalna długość to 8B, czyli sam nagłówek.
  • Pole suma kontrolna, pozwalające określić czy dane nie zostały przekłamane.

Dodatkowo datagramy wysyłane od hosta źródłowego nie muszą docierać we właściwej kolejności jak ma to miejsce w protokole TCP. Brak numerów sekwencyjnych w nagłówku także nie pozwala zestawić ich odpowiednio po odebraniu. W związku z czym datagramy są przekazywane do warstwy aplikacji w kolejności w jakiej nadeszły. Jeżeli ich kolejność jest kluczowa dla aplikacji to mechanizmy pozwalające poprawnie je ustawić i przetworzyć muszą być implementowane w warstwie aplikacji. Aplikacje klient-serwer oparte na protokole UDP są inicjowane przez klienta, który żąda danych z procesu na serwerze. Jako port źródłowy proces klienta wybiera losowy numer z zakresu portów prywatnych.

Aplikacje wykorzystujące protokół UDP

aplikacje udp

Każda z przedstawionych powyżej aplikacji wymaga pewnych cech od protokołu transportowego. W przypadku transmisji strumieniowej wideo nie jest wymagane, aby dane dostarczone były niezawodnie. Bywają sytuacje że utraconych zostanie pare segmentów. Efektem może być niezauważalne przez użytkownika zniekształcenie obrazu. Aplikacja wymaga jednak szybkości i dostarczania danych na bieżąco. W związku z czym protokół UDP jest tutaj idealny. Podobna sytuacja jest w telefonii IP, gdzie utrata kilku segmentów dla użytkownika może objawić się pod postacią niewyraźnego słowa dla słuchacza. W takim przypadku użytkownik sam może domagać się retransmisji od rozmówcy. Będzie to implementacja retransmisji na poziomie warstwy aplikacji. Protokół DNS wymaga szybkości, jeśli żądanie do serwera nie zostanie dostarczone to nie otrzymamy odpowiedzi. W efekcie jeśli żądanie było potrzebne dla protokołu HTTP to nie mając odpowiedzi jeszcze raz ją poprosimy, aby móc pobrać i wyświetlić jakąś stronę.

NetFreak

2 Comments

  1. Mam kłopot z komunikatorem wykorzystującym protokół UDP. Mogę liczyć na jakąś pomoc w rozwiązaniu problemu?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *