Protokol uživatele Datagram - User Datagram Protocol

Sada internetových protokolů
Aplikační vrstva
Transportní vrstva
Internetová vrstva
Odkazová vrstva

V počítačových sítích je User Datagram Protocol ( UDP ) jedním z hlavních členů sady internetových protokolů . S UDP mohou počítačové aplikace odesílat zprávy, v tomto případě označované jako datagramy , jiným hostitelům v síti IP ( Internet Protocol ). K nastavení komunikačních kanálů nebo datových cest není nutná předchozí komunikace .

UDP používá jednoduchý komunikační model bez připojení s minimem mechanismů protokolu. UDP poskytuje kontrolní součty pro integritu dat a čísla portů pro adresování různých funkcí u zdroje a cíle datagramu. Nemá žádné dialogy o podání ruky , a vystavuje tak program uživatele jakékoli nespolehlivosti základní sítě; neexistuje žádná záruka dodání, objednání nebo duplicitní ochrany. Pokud jsou na úrovni síťového rozhraní zapotřebí prostředky pro opravu chyb, může aplikace používat protokol Transmission Control Protocol (TCP) nebo Stream Control Transmission Protocol (SCTP), které jsou k tomuto účelu navrženy.

UDP je vhodný pro účely, kde kontrola chyb a opravy buď nejsou nutné, nebo jsou prováděny v aplikaci; UDP se vyhýbá režii takového zpracování v zásobníku protokolů . Časově citlivé aplikace často používají UDP, protože upouštění paketů je vhodnější než čekání na pakety se zpožděním v důsledku opakovaného přenosu , což v systému v reálném čase nemusí být možné .

Protokol byl navržen Davidem P. Reedem v roce 1980 a formálně definován v RFC  768 .

Atributy

UDP je jednoduchý protokol transportní vrstvy orientovaný na zprávy, který je dokumentován v RFC  768 . Ačkoli UDP poskytuje ověření integrity (prostřednictvím kontrolního součtu ) záhlaví a užitečného zatížení, neposkytuje žádné záruky pro protokol horní vrstvy pro doručování zpráv a vrstva UDP po odeslání nezachovává žádný stav zpráv UDP. Z tohoto důvodu je UDP někdy označován jako Unreliable Datagram Protocol . Pokud je požadována spolehlivost přenosu, musí být implementována v uživatelské aplikaci.

Díky řadě atributů UDP je zvláště vhodný pro určité aplikace.

Porty

Aplikace mohou používat sokety datagramu k navázání komunikace mezi hostitelem. Aplikace váže soket ke svému koncovému bodu přenosu dat, což je kombinace IP adresy a portu . Tímto způsobem UDP poskytuje multiplexování aplikací . Port je softwarová struktura, která je identifikována číslem portu , 16bitovou celočíselnou hodnotou, což umožňuje čísla portů mezi 0 a 65535. Port 0 je rezervován, ale je přípustnou hodnotou zdrojového portu, pokud proces odesílání neočekává zprávy v Odezva.

Tyto IANA (IANA) rozdělil čísla portů do tří řad. Čísla portů 0 až 1023 se používají pro běžné známé služby. V operačních systémech podobných Unixu vyžaduje použití jednoho z těchto portů provozní oprávnění superuživatele . Čísla portů 1024 až 49151 jsou registrované porty používané pro služby registrované IANA. Porty 49152 až 65535 jsou dynamické porty, které nejsou oficiálně určeny pro žádnou konkrétní službu a mohou být použity pro jakýkoli účel. Ty mohou být také použity jako pomíjivé porty , které software běžící na hostiteli může použít k dynamickému vytváření koncových bodů komunikace podle potřeby.

Struktura datagramu UDP

Záhlaví datagramu UDP
Ofsety Oktet 0 1 2 3
Oktet Bit  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0  0 Zdrojový port Cílový port
4 32 Délka Kontrolní součet

Datagram UDP se skládá z hlavičky datagramu a datové sekce. Hlavička datagramu UDP se skládá ze 4 polí, z nichž každé má 2 bajty (16 bitů). Datová část následuje za záhlavím a jsou daty užitečného zatížení přenášenými pro aplikaci.

Použití polí kontrolního součtu a zdrojového portu je v IPv4 volitelné (růžové pozadí v tabulce). V IPv6 je pole zdrojového portu volitelné.

Číslo zdrojového portu
Toto pole identifikuje port odesílatele, je -li použit, a mělo by se předpokládat, že je to port, na který lze v případě potřeby odpovědět. Pokud se nepoužívá, měla by být nulová. Pokud je zdrojovým hostitelem klient, číslo portu bude pravděpodobně pomíjivé číslo portu. Pokud je zdrojovým hostitelem server, bude pravděpodobně číslo portu dobře známým číslem portu .
Číslo cílového portu
Toto pole identifikuje port příjemce a je povinné. Podobně jako číslo zdrojového portu platí, že pokud je klient cílovým hostitelem, pak číslo portu bude pravděpodobně pomíjivé číslo portu a pokud je cílovým hostitelem server, pak bude číslo portu pravděpodobně známým číslem portu.
Délka
Toto pole určuje délku v bajtech hlavičky UDP a dat UDP. Minimální délka je 8 bajtů, délka záhlaví. Velikost pole určuje teoretický limit 65 535 bajtů (záhlaví 8 bajtů + 65 527 bajtů dat) pro datagram UDP. Skutečný limit pro délku dat, který je uložen základním protokolem IPv4 , je 65 507 bytů (65 535 bytů-8bajtová hlavička UDP-20bajtová IP hlavička ).
Pomocí jumbogramů IPv6 je možné mít datagramy UDP o velikosti větší než 65 535 bajtů. RFC  2675 určuje, že pole délky je nastaveno na nulu, pokud je délka hlavičky UDP plus dat UDP větší než 65 535.
Kontrolní součet
Pole kontrolního součtu lze použít pro kontrolu chyb záhlaví a dat. Toto pole je v IPv4 volitelné a v IPv6 povinné. Pokud pole není použito, nese všechny nuly.

Výpočet kontrolního součtu

Metoda použitá k výpočtu kontrolního součtu je definována v RFC  768 a efektivní výpočet je popsán v RFC  1071 :

Kontrolní součet je 16-bit něčí doplněk na něčí doplňková suma hlavičky pseudo informací z IP záhlaví, záhlaví UDP a data, polstrovaný s nulovými oktety na konci (v případě potřeby), aby násobek dva oktety .

Jinými slovy, všechna 16bitová slova jsou sečtena pomocí vlastní aritmetiky. Přidejte 16bitové hodnoty. Při každém přidání, pokud je vytvořen přenos (17. bit), otočte tento 17. nosný bit a přidejte jej k nejméně významnému bitu z celkového počtu. Nakonec je součet potom doplněn o hodnotu pole kontrolního součtu UDP.

Pokud má výpočet kontrolního součtu hodnotu nula (všech 16 bitů 0), měl by být odeslán jako doplněk (všechny 1 s), protože kontrolní součet s nulovou hodnotou naznačuje, že nebyl vypočítán žádný kontrolní součet. V tomto případě není v přijímači vyžadováno žádné specifické zpracování, protože všechny 0 a všechny 1 jsou rovny nule v aritmetice 1 komplementu.

Rozdíl mezi IPv4 a IPv6 je v pseudo záhlaví používaném pro výpočet kontrolního součtu a kontrolní součet není v IPv6 volitelný.

Pseudo hlavička IPv4

Když UDP běží přes IPv4, kontrolní součet se vypočítá pomocí „pseudo hlavičky“, která obsahuje některé stejné informace ze skutečné hlavičky IPv4 . Pseudo záhlaví není skutečnou hlavičkou IPv4 používanou k odesílání IP paketu, používá se pouze pro výpočet kontrolního součtu.

Formát pseudo hlavičky IPv4
Ofsety Oktet 0 1 2 3
Oktet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Zdrojová adresa IPv4
4 32 Cílová adresa IPv4
8 64 Nuly Protokol Délka UDP
12 96 Zdrojový port Cílový přístav
16 128 Délka Kontrolní součet
20 160+ Data

Zdrojová a cílová adresa jsou adresy v záhlaví IPv4. Protokol je pro UDP (viz Seznam čísel IP protokolů ): 17 (0x11). Pole délky UDP je délka hlavičky UDP a dat. Data pole znamenají přenesená data.

Výpočet kontrolního součtu UDP je pro IPv4 volitelný. Pokud kontrolní součet není použit, měl by být nastaven na hodnotu nula.

Pseudo hlavička IPv6

Když UDP běží přes IPv6, kontrolní součet je povinný. Metoda použitá k jeho výpočtu se změní, jak je dokumentováno v RFC  2460 :

Jakýkoli transportní nebo jiný protokol vyšší vrstvy, který obsahuje adresy z hlavičky IP ve svém výpočtu kontrolního součtu, musí být upraven pro použití přes IPv6 tak, aby zahrnoval 128bitové adresy IPv6.

Při výpočtu kontrolního součtu se opět používá pseudo záhlaví, které napodobuje skutečné záhlaví IPv6 :

Formát pseudo hlavičky IPv6
Ofsety Oktet 0 1 2 3
Oktet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Zdrojová adresa IPv6
4 32
8 64
12 96
16 128 Cílová adresa IPv6
20 160
24 192
28 224
32 256 Délka UDP
36 288 Nuly Další záhlaví = protokol
40 320 Zdrojový port Cílový přístav
44 352 Délka Kontrolní součet
48 384+ Data

Zdrojová adresa je adresa v záhlaví IPv6. Cílová adresa je konečným cílem; pokud paket IPv6 neobsahuje směrovací záhlaví, bude to cílová adresa v záhlaví IPv6; jinak v počátečním uzlu to bude adresa v posledním prvku směrovací hlavičky a v přijímacím uzlu to bude cílová adresa v záhlaví IPv6. Hodnota pole Další záhlaví je hodnotou protokolu pro UDP: 17. Pole délky UDP je délka záhlaví UDP a dat.

Spolehlivost a kontrola přetížení

Chybějící spolehlivost, aplikace UDP musí být ochotné akceptovat ztrátu paketů, změnu pořadí, chyby nebo duplikace. Používají -li UDP, musí aplikace koncového uživatele poskytovat veškeré potřebné potřesení rukou, jako je potvrzení přijetí zprávy v reálném čase. Aplikace, jako je TFTP , mohou podle potřeby do aplikační vrstvy přidat základní mechanismy spolehlivosti. Pokud aplikace vyžaduje vysoký stupeň spolehlivosti, může být místo ní použit protokol, jako je Transmission Control Protocol .

Aplikace UDP nejčastěji nepoužívají mechanismy spolehlivosti a mohou jim být dokonce bráněny. Streamovací média , hry pro více hráčů v reálném čase a Voice over IP (VoIP) jsou příklady aplikací, které často používají UDP. V těchto konkrétních aplikacích není ztráta paketů obvykle fatální problém. Například u VoIP je hlavním problémem latence a jitter. Použití TCP by způsobilo chvění, pokud by došlo ke ztrátě jakýchkoli paketů, protože TCP neposkytuje následující data aplikaci, zatímco požaduje opětovné odeslání chybějících dat.

Aplikace

Mnoho klíčových internetových aplikací používá UDP, včetně: Domain Name System (DNS), kde dotazy musí být rychlé a musí sestávat pouze z jednoho požadavku následovaného jedním paketem odpovědi, SNMP ( Simple Network Management Protocol ), Routing Information Protocol ( RIP) a Dynamic Host Configuration Protocol (DHCP).

Hlasový a obrazový provoz se obvykle přenáší pomocí UDP. Protokoly streamování videa a zvuku v reálném čase jsou navrženy tak, aby zvládaly příležitostně ztracené pakety, takže dochází pouze k mírnému zhoršení kvality, nikoli k velkým zpožděním, pokud byly ztracené pakety znovu vysílány. Protože TCP i UDP běží přes stejnou síť, mnoho podniků zjišťuje, že nedávný nárůst provozu UDP z těchto aplikací v reálném čase brání výkonu aplikací využívajících TCP, jako jsou prodejní místa , účetnictví a databázové systémy. Když TCP detekuje ztrátu paketů, sníží využití datové rychlosti. Jelikož pro podniky jsou důležité jak aplikace v reálném čase, tak obchodní aplikace, považují někteří za klíčovou vysokou kvalitu služeb .

Některé systémy VPN, jako je OpenVPN, mohou při implementaci spolehlivých připojení používat UDP a provádět kontrolu chyb na úrovni aplikace.

QUIC je přenosový protokol postavený na UDP. QUIC poskytuje spolehlivé a zabezpečené připojení. Protokol HTTP/3 používá QUIC oproti předchozím verzím HTTPS, které používají kombinaci TCP a TLS k zajištění spolehlivosti a zabezpečení. To znamená, že HTTP/3 používá k navázání připojení jediné handshake, místo aby měl dva samostatné handshake pro TCP a TLS, což znamená, že se zkrátí celkový čas na navázání připojení.

Porovnání UDP a TCP

Viz také: Transportní vrstva

Transmission Control Protocol je protokol orientovaný na připojení a k nastavení komunikace typu end-to-end vyžaduje handshaking. Jakmile je připojení nastaveno, mohou být uživatelská data odesílána obousměrně přes připojení.

  • Spolehlivý - TCP spravuje potvrzení zprávy, opakovaný přenos a časové limity. Provede se několik pokusů o doručení zprávy. Pokud se cestou data ztratí, budou data znovu odeslána. V TCP buď chybí žádná data, nebo v případě více časových limitů se připojení přeruší.
  • Ordered - Pokud jsou dvě zprávy odesílány přes připojení postupně, první zpráva se nejprve dostane k přijímající aplikaci. Když datové segmenty dorazí ve špatném pořadí, TCP ukládá data mimo pořadí, dokud všechna data nelze správně znovu objednat a dodat do aplikace.
  • Těžká váha - TCP vyžaduje k nastavení soketového připojení tři pakety, než lze odeslat jakákoli uživatelská data. TCP zvládá spolehlivost a řízení přetížení .
  • Streaming - Data se čtou jako bajtový proud, na hranice signální zprávy (segmentu) se nepřenášejí žádné rozlišující údaje.

User Datagram Protocol je jednodušší protokol bez připojení založený na zprávách . Protokoly bez připojení nenastavují vyhrazené připojení typu end-to-end. Komunikace je dosažena přenosem informací jedním směrem od zdroje k cíli bez ověření připravenosti nebo stavu přijímače.

  • Nespolehlivý - Když je odeslána zpráva UDP, nelze zjistit, zda dosáhne svého cíle; mohlo se to ztratit po cestě. Neexistuje žádný koncept potvrzení, opakovaného přenosu nebo časového limitu.
  • Neobjednáno - Pokud jsou stejnému příjemci odeslány dvě zprávy, nelze zaručit pořadí, v jakém dorazily.
  • Lehký - neexistuje žádné uspořádání zpráv, žádné sledovací připojení atd. Je to velmi jednoduchá transportní vrstva navržená nad IP.
  • Datagramy - pakety jsou odesílány jednotlivě a při příjezdu se kontroluje jejich neporušenost. Pakety mají určité hranice, které jsou dodržovány při přijetí; operace čtení v zásuvce přijímače přinese celou zprávu tak, jak byla původně odeslána.
  • Žádná kontrola přetížení - UDP se nevyhýbá přetížení. Opatření ke kontrole přetížení musí být implementována na úrovni aplikace nebo v síti.
  • Vysílání - jelikož je UDP bez připojení, může vysílat - odeslané pakety lze adresovat tak, aby je mohla přijímat všechna zařízení v podsíti.
  • Vícesměrové vysílání - je podporován režim vícesměrového vysílání, přičemž jeden datagramový paket lze automaticky směrovat bez duplikace do skupiny předplatitelů.

Standardy

  • RFC  768 - protokol uživatelského datagramu
  • RFC  2460 - Specifikace internetového protokolu, verze 6 (IPv6)
  • RFC  2675 - Jumbogramy IPv6
  • RFC  4113 - Informační základna pro správu UDP
  • RFC  8085 - Pokyny k používání UDP

Viz také

Reference

externí odkazy