Protokol UDP

V předchozích dílech našeho seriálu jsme se začali zabývat transportní vrstvou síťového modelu TCP/IP. Přitom jsme si naznačili, že pro tuto vrstvu připadají v úvahu dva alternativní protokoly - TCP a UDP. Dnes se podrobněji zastavíme u jednoho z nich: protokolu UDP.

Nejprve si ale znovu připomeňme některé obecnější souvislosti, o kterých jsme zmínili již v 53. dílu našeho seriálu. Zde jsme si řekli, že na rozdíl od referenčního modelu ISO/OSI považuje síťový model TCP/IP otázku zabezpečení spolehlivosti přenosů za věc koncových účastníků komunikace, a z tohoto důvodu zařazuje příslušné mechanismy pro zajištění spolehlivosti až do transportní vrstvy, zatímco na úrovni síťové vrstvy předpokládá pouze nespolehlivou službu nespojovaného charakteru (realizovanou protokolem IP). Řekli jsme si však také, že síťový model TCP/IP pamatuje i na to, že pro některé druhy aplikací nemusí být spolehlivé transportní služby výhodné. Proto jim nabízí jako alternativní možnost využívat i na úrovni transportní vrstvy služby stejné povahy a kvality, jakou mají přenosové služby na úrovni síťové vrstvy, zajišťované protokolem IP - tedy nespolehlivé přenosové služby nespojovaného charakteru.

UDP jako jednoduchá "obálka" protokolu IP

Mechanismem, který entitám (procesům, úlohám, programům) aplikační vrstvy zpřístupňuje nespolehlivé a nespojované, zato ale rychlé a efektivní přenosové služby síťové vrstvy (protokolu IP), je právě protokol UDP (User Datagram Protocol). Můžeme si jej představit jako jednoduchou "obálku" nad protokolem IP, která nijak nemění povahu ani kvalitu jeho přenosových služeb, ale pouze je zprostředkovává své bezprostředně vyšší vrstvě. V podstatě jediné, co UDP zajišťuje navíc, je multiplexování a demultiplexování datagramů (viz minulý díl seriálu), tedy rozlišování různých příjemců, resp. odesilatelů v rámci téhož hostitelského počítače - podle čísla portu.

Odpovědnost přebírá aplikace

Každý aplikační program, který se rozhodne používat transportní služby protokolu UDP, tak na sebe přebírá odpovědnost za zajištění takové úrovně spolehlivosti přenosů, jakou sám potřebuje. Sám se také musí vyrovnávat i s dalšími důsledky, které vyplývají z nespolehlivého a nespojovaného charakteru přenosových služeb protokolu UDP - jako je např. zajišťování správného pořadí doručovaných datagramů, eliminace duplicitních datagramů apod.

Obr. 56.1.: UDP datagramy vs. IP datagramy

Jak jsme si již uvedli v předchozích dílech, je volba nespolehlivých transportních služeb protokolu UDP determinována především charakterem aplikace a jeho požadavky na efektivitu přenosových služeb. Svou roli při rozhodování mezi nespolehlivými ale rychlejšími službami protokolu UDP a spolehlivými, zato ale pomalejšími transportními službami protokolu TCP však sehrává i prostředí, ve kterém jsou tyto transportní služby zajišťovány. Například v lokálních sítích, které jsou velmi rychlé a především relativně spolehlivé, může být protokol UDP pro mnohé aplikace velmi výhodný. Při přechodu do prostředí rozlehlých sítí, které jsou ve své podstatě mnohem méně spolehlivé, však může natolik narůst režie konkrétního aplikačního programu na zajištění potřebné spolehlivosti, že se pro ni stane protokol UDP méně výhodný, než "spolehlivý" protokol TCP, nebo se použití protokolu UDP stane dokonce zcela neúnosné.

Formát UDP datagramu

Jak jsme si již také uvedli v 53. dílu, protokol UDP dostává od své bezprostředně vyšší vrstvy bloky dat, které se snaží vkládat celé do jednotlivých datagramů síťové vrstvy (IP datagramů), viz obr. 56.1. Proto se také těmto blokům na úrovni transportní vrstvy říká uživatelské datagramy (user datagrams), nebo též UDP datagramy (UDP datagrams). Jejich formát je uveden na obrázku 56.2.

Obr. 56.2.: Formát UDP datagramu

Hlavičku (anglicky: header) UDP datagramu tvoří 4 položky v rozsahu 16 bitů, které po řadě vyjadřují číslo portu odesilatele a příjemce, délku UDP datagramu, a kontrolní součet - viz obr. 56.2.

Číslo portu příjemce (položka UDP DESTINATION PORT) je základní informací, podle které se protokol UDP na straně příjemce rozhoduje, komu má přijatý datagram doručit - přesněji: přes který port má přijatý datagram předat entitě aplikační vrstvy. Číslo portu odesilatele (v položce UDP SOURCE PORT) je nepovinné; vyplňuje se v případě, kdy je požadována odpověď (v opačném případě se tato položka zaplňuje nulami).

Položka LENGTH vyjadřuje délku UDP datagramu, měřenou v oktetech (tj. osmicích bitů) - včetně vlastní hlavičky. Minimální délka UDP datagramu je proto 8, což je právě velikost hlavičky, s prázdnou datovou částí.

Kontrolní součet

Kontrolní součet (položka CHECKSUM) je počítán v rozsahu 16 bitů v aritmetice, která pro vyjádřená čísel se znaménkem využívá tzv. jedničkový doplněk (one's complement). Jednou ze zajímavých vlastností této nepříliš používané aritmetiky je skutečnost, že má dva možné způsoby znázornění nuly: tzv. kladnou nulu, tvořenou dvojkově samými nulami, a tzv. zápornou nulu, která má naopak všechny bity nastaveny na jedničku. V případě, že kontrolní součet vychází nulový, je použita právě tato druhá možnost, tedy tzv. záporná nula. Použití kontrolního součtu však není povinné. Jestliže se kontrolní součet nepoužije, je položka CHECKSUM vynulována - ovšem tzv. kladnou nulou, což je díky vlastnostem jedničkového doplňku možné odlišit od nulové hodnoty kontrolního součtu.

Obr. 56.3.: UDP datagram a pseudohlavička

Zvláštností protokolu UDP je skutečnost, že zmíněný kontrolní součet - je-li použit - není počítán z UDP datagramu (který je na obrázku 56.2.), ale z větší datové struktury (viz obr. 56.3.), která vznikne pomyslným připojením další hlavičky - tzv. pseudohlavičky (pseudo header) k vlastnímu datagramu. Pomyslným připojením v tom smyslu, že tato pseudohlavička není ve skutečnosti přenášena od odesilatele k příjemci, ale je brána v úvahu pouze pro výpočet kontrolního součtu.

Jak vyplývá z obrázku 56.3., je v pseudohlavičce obsažena mj. IP adresa příjemce a odesilatele (která naopak ve vlastním UDP datagramu, resp. jeho hlavičce obsažena není). Protokol UDP na straně příjemce kontroluje bezchybovost všech přijatých datagramů novým výpočtem kontrolního součtu a jeho porovnáním s obsahem položky CHECKSUM. Uživatelský datagram sice přijme bez jeho pseudohlavičky, ale pro potřeby kontrolního součtu si ji protokol UDP znovu vytvoří a zahrne ji do nového výpočtu kontrolního součtu. Vzhledem k tomu, že pseudohlavička UDP datagramu obsahuje mj. i IP adresu příjemce, jde o mechanismus, který kromě poškozených datagramů umožňuje rozpoznat také datagramy, doručené na chybnou IP adresu (což z pouhého čísla portu, které je ve vlastním datagramu, nelze poznat), a následně je eliminovat.

Zastavme se však ještě u právě naznačeného výpočtu kontrolního součtu. Podle něj musí protokol UDP u odesilatele již při sestavování UDP datagramu znát nejen IP adresu příjemce, ale i IP adresu odesilatele, neboť obě tyto adresy musí zahrnout do kontrolního součtu. IP adresu příjemce se protokol UDP dozví od aplikace, neboť právě ona určuje, komu jsou příslušná data určena. Pokud však jde o IP adresu odesilatele, nemusí být v silách protokolu UDP ji stanovit. Jde-li totiž o hostitelský počítač, který má více než jedno síťové rozhraní (tj. jde-li o tzv. multi-homed host, který je současně zapojen do více dílčích sítí, viz 46. díl seriálu), má odesilatel více různých IP adres (po jedné na každé síťové rozhraní, resp. pro každou dílčí síť). Rozhodnout, kudy bude příslušný datagram skutečně odeslán (tj. kterým síťovým rozhraním, resp. s jakou IP adresou odesilatele), je pak až v silách síťové vrstvy, resp. protokolu IP, který zajišťuje směrování. Protokol UDP si proto musí při sestavování uživatelského datagramu vyžádat pomoc protokolu IP, což ale poněkud narušuje standardní způsob interakce jednotlivých vrstev ve vrstevnatém modelu.

---