zpět do archivu článků |
rejstřík |
předchozí díl |
následující díl
Jiří Peterka: Co je čím ... v počítačových sítích (56):
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.
zpět do archivu článků | rejstřík |
předchozí díl |
následující díl
Tento článek může být volně šířen, pokud se tak děje pro studijní účely, na nevýdělečném základě a se zachováním tohoto dovětku. Podrobnosti hledejte zde, resp. na adrese
http://ksi.ms.mff.cuni.cz/~peterka/archiv/copyleft.htm