Domov › Telefon › Kde se používá udp? protokol UDP. Princip fungování. Aplikace

Kde se používá udp? protokol UDP. Princip fungování. Aplikace

UDP je jednoduchý protokol a má specifický rozsah. V první řadě jsou to interakce klient-server a multimédia. Většina internetových aplikací však vyžaduje spolehlivý a konzistentní přenos. UDP tyto požadavky nesplňuje, takže je vyžadován jiný protokol. Tento protokol se nazývá TCP a je tahounem internetu.

Základy TCP

Protokol TCP (Transmission Control Protocol) byl speciálně navržen tak, aby poskytoval spolehlivý datový tok mezi koncovými bajty přes nespolehlivou internetovou síť. Propojená síť se liší od samostatné sítě v tom, že její různé části mohou mít velmi odlišné topologie, šířky pásma, hodnoty latence, velikosti paketů a další parametry. Vývoj TCP se zaměřil na schopnost protokolu přizpůsobit se vlastnostem sítě a být odolný vůči různým problémům.

Protokol TCP je popsán v RFC 793. Postupem času byly objeveny různé chyby a nepřesnosti a v některých ohledech byly požadavky změněny. Podrobný popis těchto objasnění a oprav je uveden v RFC 1122. Rozšíření protokolu jsou uvedena v RFC 1323.

Každý stroj, který podporuje protokol TCP, má transportní entitu TCP, což je buď procedura knihovny, uživatelský proces nebo část jádra systému. V obou případech transportní entita spravuje toky TCP a rozhraní k vrstvě IP. Entita TCP přijímá toky uživatelských dat z lokálních procesů, rozděluje je na části o velikosti ne větší než 64 KB (v praxi je toto číslo obvykle 460 bajtů dat, což umožňuje jejich umístění do jednoho ethernetového rámce s IP a TCP hlavičkami), a odesílá je jako samostatné IP datagramy. Když datagramy IP obsahující data TCP dorazí na stroj, jsou předány entitě TCP, která rekonstruuje původní tok bajtů. Pro jednoduchost budeme někdy používat „TCP“ k označení transportní entity TCP (část softwaru) nebo protokolu TCP (soubor pravidel). Z kontextu bude jasné, co je myšleno. Například ve výrazu „Uživatel přenáší data TCP“ je přirozeně implikována transportní entita TCP.

Vrstva IP nezaručuje správné doručení datagramů, takže TCP musí sledovat vypršené časové limity a v případě potřeby pakety znovu vysílat. Někdy datagramy dorazí ve špatném pořadí. TCP je také zodpovědný za obnovu zpráv z takových datagramů. Proto je TCP navržen tak, aby poskytoval spolehlivost, kterou si mnoho uživatelů přeje, a kterou IP neposkytuje.

Servisní model TCP

Služba TCP je založena na tzv. soketech (socketech nebo koncových bodech), které vytváří odesílatel i příjemce. Diskutovalo se o nich v sekci Berkeley Sockets. Každý soket má číslo (adresu) skládající se z IP adresy hostitele a 16bitového čísla místního hostitele zvaného port. Port v TCP se nazývá adresa TSAP. Pro přístup ke službě TCP musí být výslovně vytvořeno spojení mezi soketem na odesílajícím počítači a soketem na počítači příjemce.

Jedna zásuvka může být použita pro více připojení současně. Jinými slovy, dvě nebo více připojení mohou končit na stejném soketu. Připojení se odlišují ID zásuvek na obou koncích - (zásuvka1, zásuvka2). Čísla virtuálních kanálů ani jiné identifikátory se nepoužívají.

Čísla portů pod 1024, nazývaná populární porty, jsou rezervována standardními službami. Například jakýkoli proces, který se chce připojit k hostiteli za účelem přenosu souboru pomocí FTP, může kontaktovat port 21 cílového hostitele a kontaktovat tak svého FTP démona. Seznam oblíbených portů je uveden na webových stránkách www.iana.org.

Mohli bychom samozřejmě svázat FTP démona s portem 21 při bootování, pak svázat telnetového démona s portem 23 atd. Pokud bychom to však udělali, pouze bychom plýtvali pamětí informacemi o démonech, které ve skutečnosti , jsou většinu času nečinné. Místo toho je běžné používat jediného démona, v UNIXu nazývaného inetd, který komunikuje s více porty a čeká na první příchozí spojení. Když k tomu dojde, inetd vytvoří nový proces a vyvolá příslušného démona pro zpracování požadavku. Neustále je tedy aktivní pouze inetd, ostatní se volají, až když je pro ně práce. Inetd má speciální konfigurační soubor, ze kterého se může dozvědět o přiřazení portů. To znamená, že správce systému může nakonfigurovat systém tak, aby trvalí démoni byli přidruženi k nejvytíženějším portům (například 80) a inetd byl přidružen ke zbytku.

Některé vyhrazené porty
	Protokol	Používání
21	FTP	Přenos souborů
23	Telnet	Vzdálené přihlášení
25	SMTP	E-mail
69	TFTP	Nejjednodušší protokol pro přenos souborů
79	Prst	Vyhledávání informací o uživateli
80	HTTP	World Wide Web
110	POP-3	Vzdálený přístup k e-mailu
119	NNTP	diskusní skupiny

Všechna připojení TCP jsou plně duplexní a point-to-point. Full duplex znamená, že provoz může proudit v opačných směrech současně. Spojení typu point-to-point znamená, že má dva koncové body. Vysílání a vícesměrové vysílání TCP nepodporuje.

TCP spojení je byte stream, nikoli tok zpráv. Hranice mezi zprávami nejsou zachovány. Pokud například odesílající proces zapíše čtyři 512bajtové bloky dat do toku TCP, tato data mohou být doručena přijímajícímu procesu jako čtyři 512bajtové bloky, dva 1024bajtové bloky, jeden 2048bajtový blok nebo něco podobného. jiný. Příjemce nemůže žádným způsobem určit, jak byla data zapsána.

Soubory v systému UNIX mají také tuto vlastnost. Program, který čte kolejnici, nemůže určit, jak byl tento soubor zapsán: blok po bloku, byte po byte nebo celý najednou. Stejně jako u systémových souborů UNIX nemají programy TCP žádnou představu o významu bajtů a ani se o něj nezajímají. Bajt je pro ně jen byte.

Jakmile TCP přijme data z aplikace, může je odeslat všechna najednou nebo je uložit do vyrovnávací paměti a odeslat tak větší část dat najednou, jak si vybere. Někdy však aplikace potřebuje data odeslat okamžitě. Řekněme například, že se uživatel přihlásí ke vzdálenému počítači. Poté, co zadá příkaz a stiskne klávesu Enter, je důležité, aby řádek, který zadá, byl doručen na vzdálený počítač okamžitě, místo aby byl ukládán do vyrovnávací paměti až do zadání dalšího řádku. Pro vynucení přenosu dat bez prodlení může aplikace nastavit příznak PUSH.

Některé starší aplikace používaly příznak PUSH jako oddělovač zpráv. Ačkoli tento trik někdy funguje, ne všechny implementace TCP předávají příznak PUSH přijímající aplikaci. Pokud navíc entita TCP přijme několik dalších takových paketů před odesláním prvního PUSH paketu na lince (to znamená, že výstupní linka je obsazená), entita TCP bude mít právo odeslat všechna tato data jako jeden datagram, nerozdělovat je na samostatné části.

Poslední funkcí služby TCP, kterou stojí za zmínku, jsou urgentní data. Když uživatel interagující s programem interaktivně stiskne Delete nebo Ctrl-C k přerušení vzdáleného procesu, který právě probíhá, odesílající aplikace umístí řídicí informace do výstupního datového toku a předá je službě TCP spolu s příznakem URGENT. Tento příznak způsobí, že entita TCP přestane shromažďovat data a okamžitě uvolní vše, co má pro připojení k síti.

Když urgentní data dorazí na místo určení, přijímající aplikace je přerušena (tedy v terminologii UNIX „signalizována“), načež může číst data ze vstupního toku a hledat mezi nimi urgentní data. Konec urgentních dat je označen, aby aplikace poznala, kde končí. Začátek urgentních dat není označen. Aplikace by na to měla přijít sama. Tento obvod poskytuje hrubý signalizační mechanismus a vše ostatní ponechává na aplikaci.

TCP protokol

Tato část se bude zabývat protokolem TCP obecně. V další části probereme záhlaví protokolu, pole po poli.

Klíčovou vlastností TCP, která definuje celou strukturu protokolu, je to, že v TCP spojení má každý bajt své vlastní 32bitové pořadové číslo. V prvních letech internetu byla základní rychlost přenosu dat mezi routery přes pronajaté linky 56 Kbps. U hostitele, který neustále odčerpává data nejvyšší rychlostí, by trvalo více než týden, než by se sekvenční čísla uzavřela do kruhu. Při současných rychlostech mohou sekvenční čísla vyčerpat velmi rychle, více o tom později. Samostatná 32bitová sekvenční čísla se používají pro potvrzení a pro mechanismus posuvného okna, o kterém bude také pojednáno později.

Odesílající a přijímající TCP entity si vyměňují data ve formě segmentů. Segment se skládá z pevného 20bajtového záhlaví (plus volitelná část), po kterém mohou následovat datové bajty. Velikost segmentů je určena softwarem TCP. Dokáže sloučit data získaná jako výsledek několika operací zápisu do jednoho segmentu, nebo naopak rozložit výsledek jednoho zápisu do více segmentů. Velikost segmentů je omezena dvěma limity. Nejprve se každý segment, včetně hlavičky TCP, musí vejít do pole užitečného zatížení 65 515 bajtů paketu IP. Za druhé, každá síť má maximální přenosovou jednotku (MTU) a každý segment se musí vejít do MTU. V praxi je velikost maximální přenosové jednotky obvykle 1500 bajtů (což odpovídá velikosti pole užitečného zatížení Ethernetu), a tím definuje horní hranici velikosti segmentu.

Hlavním protokolem používaným entitami TCP je protokol posuvného okna. Při přenosu segmentu odesílatel spustí časovač. Když segment dorazí na místo určení, přijímající entita TCP odešle zpět segment (s daty, pokud je něco k odeslání, nebo bez dat) s číslem

potvrzení rovnající se pořadovému číslu dalšího očekávaného segmentu. Pokud vyprší časový limit pro potvrzení, odesílatel odešle segment znovu.

Ačkoli se tento protokol zdá jednoduchý, existuje několik detailů, které je třeba prozkoumat podrobněji. Segmenty mohou dorazit ve špatném pořadí. Je tedy například možné, že bajty 3072 až 4095 již dorazily, ale nelze pro ně odeslat potvrzení, protože bajty 2048 až 3071 ještě nebyly přijaty. Kromě toho mohou segmenty v síti setrvat tak dlouho, že odesilatel vyprší a odešle je znovu. Opakovaně vysílaný segment může obsahovat různé rozsahy fragmentů, takže bude vyžadována velmi pečlivá správa, aby se správně určila čísla bajtů, která již byla přijata. Protože je však každý bajt v proudu jednoznačně identifikován svým offsetem, je tento úkol proveditelný.

TCP musí být schopen se s těmito problémy vypořádat a efektivně je řešit. Hodně úsilí bylo vynaloženo na optimalizaci výkonu toků TCP. V další části probereme několik algoritmů používaných v různých implementacích protokolu TCP.

Hlavička TCP segmentu

Každý segment začíná 20bajtovým záhlavím pevného formátu. Po něm mohou následovat další pole. Po dalších polích může být až 65 535 - 20 - 20 = 65 495 bajtů dat, kde prvních 20 bajtů je hlavička IP a druhých je hlavička TCP. Segmenty nesmí obsahovat data. Takové segmenty se často používají k přenosu potvrzení a řídicích zpráv.

Podívejme se na záhlaví TCP pole po poli. Pole Port přijímače a Zdrojový port jsou identifikátory koncových bodů místního připojení. Číslo portu spolu s IP adresou hostitele tvoří jedinečný 48bitový identifikátor koncového bodu. Pár takových identifikátorů zdroje a cíle jednoznačně identifikuje připojení.

Pole pořadové číslo a číslo potvrzení plní své obvyklé funkce. Všimněte si, že pole Číslo potvrzení odkazuje na další očekávaný bajt, nikoli na poslední přijatý bajt. Oba jsou 32bitové, protože každý bajt dat v toku TCP je očíslován.

Pole Délka hlavičky TCP obsahuje velikost hlavičky TCP vyjádřenou 32bitovými slovy. Tyto informace jsou nezbytné, protože pole Volitelná pole a s ním i celé záhlaví mohou mít proměnnou délku. Toto pole v podstatě udává posun od začátku segmentu k datovému poli, měřený ve 32bitových slovech. To je stejné jako délka názvu.

Následuje nevyužité 6bitové pole. O tom, jak promyšlený je návrh TCP, svědčí fakt, že tento obor přežil čtvrt století.

Následuje šest 1bitových příznaků. Bit URG je nastaven na 1 při použití pole Urgent Data Ukazatel, které obsahuje bajtový posun od aktuálního pořadového čísla bajtů k umístění urgentních dat. Takto TCP implementuje zprávy o přerušení. Jak již bylo zmíněno, protokol TCP zajišťuje pouze doručení uživatelského signálu příjemci, aniž by se zajímal o příčinu přerušení.

Pokud je bit ACK nastaven na 1, pole Acknowledgement Number obsahuje smysluplná data. Jinak tento segment neobsahuje potvrzení a pole Číslo potvrzení je jednoduše ignorováno.

Bit PSH je v podstatě příznak PUSH, který říká odesílateli, aby řekl příjemci, aby doručil data aplikaci, jakmile paket přijme, místo aby je ukládal do vyrovnávací paměti, dokud se nezaplní. (Příjemce může vyrovnat, aby dosáhl větší efektivity.)

Bit RST se používá k resetování stavu připojení, které v důsledku selhání hostitele nebo z jiného důvodu uvázlo. Používá se také k odmítnutí neplatného segmentu nebo pokusu o vytvoření spojení. Pokud přijmete segment s nastaveným bitem RST, došlo k nějakému problému.

Bit SYN se používá k navázání spojení. Požadavek na připojení má bit SYN = 1 a bit ACK = 0, což znamená, že pole pro potvrzení není použito. Odpověď na tento požadavek obsahuje potvrzení, takže hodnoty těchto bitů jsou: SYN= 1, ACK-1. Bit SYN se tedy používá k označení segmentů CONNECTION REQUEST a CONNECTION ACCEPTED a bit ACK aby je od sebe odlišili.

Bit FIN se používá k ukončení spojení. Označuje, že odesílatel již nemá žádná data k přenosu. I po ukončení připojení však může proces přijímat data neomezeně dlouho. Segmenty s bity FIN a SYN mají pořadová čísla, aby bylo zajištěno, že budou provedeny ve správném pořadí.

Řízení toku v protokolu TCP se provádí pomocí posuvného okna proměnné velikosti. Pole Velikost okna říká, kolik bajtů lze odeslat po potvrzovacím bajtu. Hodnota pole Velikost okna může být nula, což znamená, že byly přijaty všechny bajty do čísla potvrzení-1, ale příjemce má momentálně nějaké problémy a zbývající bajty zatím nemůže přijmout. Povolení pro další přenos lze získat odesláním segmentu se stejnou hodnotou pole Číslo potvrzení a nenulovou hodnotou pole Velikost okna.

V některých protokolech jsou potvrzení rámců spojena s oprávněním pokračovat v přenosu. Tento vztah je důsledkem pevně fixované velikosti posuvného okna v těchto protokolech. V TCP jsou potvrzení oddělena od oprávnění k přenosu dat. Přijímač by v podstatě mohl říci: "Dostal jsem bajtů až do k-ro, ale v současné době nechci pokračovat v přijímání dat." Toto rozdělení (vyjádřené jako posuvné okno proměnné velikosti) poskytuje protokolu další flexibilitu. Tento aspekt probereme podrobněji níže.

Pole Kontrolní součet se používá ke zvýšení spolehlivosti. Obsahuje kontrolní součet záhlaví, dat a pseudozáhlaví. Při provádění výpočtů je pole Kontrolní součet nastaveno na nulu a datové pole je doplněno nulovým bajtem, pokud je jeho délka liché číslo. Algoritmus kontrolního součtu jednoduše sečte všechna 16bitová slova ve dvojkovém doplňku a poté vypočítá doplněk celého součtu. V důsledku toho, když příjemce zkontroluje celý segment, včetně pole Kontrolní součet, výsledek musí být 0.

Pseudohlavička obsahuje 32bitovou zdrojovou a cílovou IP adresu, číslo protokolu pro TCP (6) a počet bajtů pro segment TCP (včetně hlavičky). Zahrnutí pseudozáhlaví do kontrolního součtu TCP pomáhá odhalit nesprávně doručené pakety, i když to narušuje hierarchii protokolu, protože adresy IP v něm patří do vrstvy IP, nikoli do vrstvy TCP. UDP používá stejné pseudozáhlaví pro kontrolní součet.

Pole Volitelná pole poskytuje další možnosti, které nepokrývá standardní záhlaví. Pomocí jednoho z těchto polí může každý hostitel určit maximální velikost pole užitečného zatížení, které může přijmout. Čím větší je velikost použitých segmentů, tím větší je efektivita, protože to snižuje režii 20bajtových hlaviček, ale ne všichni hostitelé mohou přijímat velmi velké segmenty. Hostitelé mohou mezi sebou komunikovat maximální velikost pole užitečného zatížení během nastavování připojení. Ve výchozím nastavení je tato velikost 536 bajtů. Všichni hostitelé musí přijímat segmenty TCP o velikosti 536 + 20 = 556 bajtů. Každý směr může mít svou vlastní maximální velikost pole užitečného zatížení.

Pro linky s vysokou přenosovou rychlostí a/nebo vysokou latencí je 64 KB okno příliš malé. U linky TZ (44,736 Mbit/s) lze tedy celé okno přenést na linku za pouhých 12 ms. Pokud je doba zpáteční cesty 50 ms (typické pro transkontinentální optický kabel), stráví odesílatel čekáním na potvrzení 3/4 času. Při komunikaci přes satelit bude situace ještě horší. Větší velikost okna by zlepšila efektivitu, ale pole 16bitová velikost okna to neumožňuje. RFC 1323 navrhl nový parametr Window Scale, na jehož hodnotě se dva hostitelé mohli dohodnout při navazování spojení. Toto číslo umožňuje posunout pole Velikost okna až o 14 bitů doleva, což umožňuje rozšíření velikosti okna na 230 bajtů (1 GB). V současnosti tuto funkci podporuje většina implementací protokolu TCP.

Další možností, navrženou v RFC 1106 a nyní široce používanou, je použití protokolu selektivního opakování namísto zpětného sledování. Pokud cíl obdrží jeden špatný segment následovaný velkým počtem dobrých, normální protokol TCP nakonec vyprší znovu odeslat všechny nepotvrzené segmenty, včetně těch, které byly přijaty správně. RFC 1106 navrhlo použití negativních potvrzení (NAK), aby příjemce mohl požádat o jeden segment nebo více segmentů. Po přijetí může přijímající strana potvrdit všechna data uložená ve vyrovnávací paměti, čímž se sníží množství znovu přenášených dat.

Protokoly TCP a UDP

TCP-Transmission Control Protocol

Komunikace orientovaná na spojení může využívat spolehlivou komunikaci, přičemž protokol Layer 4 posílá potvrzení, když byla data přijata, a požaduje opětovné odeslání, pokud data nejsou přijata nebo poškozena. Protokol TCP využívá právě takovou spolehlivou komunikaci. TCP se používá v aplikačních protokolech jako HTTP, FTP, SMTP a Telnet.

Protokol TCP vyžaduje, aby bylo před odesláním zprávy navázáno spojení. Serverová aplikace musí dělat to, co se nazývá pasivně otevřený vytvořit spojení se známým číslem portu a místo odeslání hovoru do sítě čeká server na příchozí požadavky. Klientská aplikace to musí udělat aktivní otevřené odesláním serverové aplikace sekvenčního čísla synchronizace (SYN) identifikující připojení. Klientská aplikace může jako lokální port používat dynamické číslo portu.

Server musí odeslat klientovi potvrzení (ACK) spolu s pořadovým číslem serveru (SYN). Klient zase odpoví ACK a spojení je navázáno.

Poté může začít proces odesílání a přijímání zpráv. Když je zpráva přijata, je vždy jako odpověď odeslána zpráva ACK. Pokud vyprší časový limit dříve, než odesílatel obdrží potvrzení, je zpráva zařazena do fronty pro opětovné odeslání.

Pole záhlaví TCP jsou uvedena v následující tabulce:

TCP hlavička

Pole	Délka	Popis
Zdrojový port	2 bajty	Číslo zdrojového portu
Cílový přístav	2 bajty	Číslo cílového portu
Sériové číslo	4 bajty	Pořadové číslo generuje zdroj a používá jej cíl k přeuspořádání paketů k vytvoření původní zprávy a odeslání potvrzení zdroji.
Číslo potvrzení	4 bajty	Pokud je nastaven bit ACK pole Control, toto pole obsahuje další očekávané pořadové číslo.
Posun dat	4 bity	Informace o začátku datového paketu.
Rezervovat	6 bitů	Rezervováno pro budoucí použití.
Řízení	6 bitů	Řídicí bity obsahují příznaky indikující, zda jsou platná pole potvrzení (ACK), urgence (URG), zda má být spojení resetováno (RST), zda bylo odesláno sériové číslo synchronizace (SYN) atd.
Velikost okna	2 bajty	Toto pole určuje velikost přijímací vyrovnávací paměti. Pomocí potvrzovacích zpráv může příjemce informovat odesílatele o maximálním množství dat, které může odeslat.
Kontrolní součet	2 bajty	Kontrolní součet záhlaví a dat; určuje, zda byl paket poškozen.
Indikátor naléhavosti	2 bajty	V tomto poli obdrží cílové zařízení informaci o naléhavosti dat.
Možnosti	variabilní	Volitelné hodnoty, které jsou specifikovány v případě potřeby.
Přidání	variabilní	Do pole výplně se přidá dostatek nul, takže záhlaví končí na 32bitové hranici.

TCP je složitý, časově náročný protokol díky mechanismu navazování spojení, ale stará se o garantované doručení paketů, aniž bychom tuto funkcionalitu museli zahrnout do aplikačního protokolu.

Protokol TCP má zabudované spolehlivé doručovací schopnosti. Pokud zpráva není odeslána správně, obdržíme chybovou zprávu. Protokol TCP je definován v RFC 793.

UDP - User Datagram Protocol

Na rozdíl od TCP je UDP velmi rychlý protokol, protože definuje nezbytné minimum mechanismu pro přenos dat. Samozřejmě to má nějaké nevýhody. Zprávy přicházejí v libovolném pořadí a ta, která byla odeslána jako první, může být přijata jako poslední. Doručení UDP zpráv není vůbec zaručeno, zpráva může být ztracena a mohou být přijaty dvě kopie stejné zprávy. Poslední případ nastane, pokud jsou k odesílání zpráv na jednu adresu použity dvě různé cesty.

UDP nevyžaduje otevření připojení a data lze odeslat, jakmile jsou připravena. UDP neposílá potvrzovací zprávy, takže může dojít k přijetí nebo ztrátě dat. Pokud je při použití protokolu UDP vyžadován spolehlivý přenos dat, měl by být implementován v protokolu vyšší úrovně.

Jaké jsou tedy výhody UDP, proč by mohl být takový nespolehlivý protokol potřeba? Abyste pochopili důvod použití UDP, musíte rozlišovat mezi jednosměrným přenosem, přenosem všesměrového vysílání a přenosem vícesměrového vysílání.

Unicast zpráva odesláno z jednoho uzlu pouze do jednoho dalšího uzlu. Tomu se také říká komunikace z bodu do bodu. Protokol TCP podporuje pouze jednosměrnou komunikaci. Pokud server potřebuje komunikovat s více klienty pomocí TCP, každý klient musí navázat spojení, protože zprávy lze posílat pouze jednomu hostiteli.

Přenos znamená, že zpráva je odeslána všem uzlům v síti. Skupinová distribuce (multicast) je zprostředkující mechanismus: zprávy jsou odesílány vybraným skupinám uzlů.

UDP lze použít pro jednosměrnou komunikaci, když je vyžadován rychlý přenos, například pro doručování multimediálních dat, ale hlavní výhody UDP se týkají vysílání a multicastingu.

User Datagram Protocol (UDP)(User Datagram Protocol) je protokol standardu TCP/IP, definovaný v RFC 768, "User Datagram Protocol (UDP)". UDP se používá místo TCP k rychlému a nespolehlivému přenosu dat mezi hostiteli TCP/IP.

protokol UDP poskytuje službu bez připojení, takže UDP nezaručuje doručení nebo kontrolu sekvence pro jakýkoli datagram. Hostitel, který potřebuje spolehlivou komunikaci, musí používat buď protokol TCP, nebo program, který bude sám sledovat sled datagramů a potvrzovat přijetí každého paketu.

Aplikace citlivé na čas často používají UDP (video data), protože je vhodnější zahazovat pakety, než čekat na zpožděné pakety, což v systémech pracujících v reálném čase nemusí být možné. Také ztráta jednoho nebo několika snímků při přenosu video dat přes UDP není tak kritická, na rozdíl od přenosu binárních souborů, kde ztráta jednoho paketu může vést k poškození celého souboru. Další výhodou protokolu UDP je, že délka hlavičky UDP je 4 bajty, zatímco protokol TCP má 20 bajtů.

Zprávy UDP jsou zapouzdřeny a přenášeny v IP datagramech.

UDP hlavička

Obrázek ukazuje pole přítomná v hlavičce UDP.

Port odesílatele – Toto pole určuje číslo portu odesílatele. Tato hodnota má specifikovat port, na který bude v případě potřeby odeslána odpověď. V opačném případě by hodnota měla být 0. Pokud je zdrojovým hostitelem klient, bude číslo portu s největší pravděpodobností pomíjivé. Pokud je zdrojem server, pak jeho port bude jeden z „dobře známých“.
Port příjemce – Toto pole je povinné a obsahuje port příjemce. Podobně jako u zdrojového portu, pokud je klient cílovým hostitelem, pak je číslo portu efemérní, jinak (server je příjemce) je to „dobře známý port“.
Délka datagramu je pole, které udává délku celého datagramu (záhlaví a dat) v bajtech. Minimální délka je rovna délce záhlaví – 8 bajtů. Teoreticky je maximální velikost pole 65535 bajtů pro datagram UDP (8 bajtů pro záhlaví a 65527 pro data). Skutečný limit pro délku dat při použití IPv4 je 65507 (kromě 8 bajtů na hlavičku UDP je vyžadováno dalších 20 bajtů na hlavičku IP).
Kontrolní součet – Pole kontrolního součtu se používá ke kontrole chyb v záhlaví a datech. Pokud množství není generováno vysílačem, pak je pole vyplněno nulami.

Podívejme se na strukturu záhlaví UDP pomocí síťového analyzátoru Wireshark:

UDP porty

Vzhledem k tomu, že na stejném počítači může být spuštěno několik programů, je k doručení paketu UDP do konkrétního programu použit jedinečný identifikátor nebo číslo portu každého programu.

Číslo portu je podmíněné 16bitové číslo od 1 do 65535 udávající, pro který program je balíček určen.

Porty UDP poskytují možnost odesílat a přijímat zprávy UDP. Port UDP funguje jako jediná fronta zpráv pro příjem všech datagramů určených pro program určený číslem portu protokolu. To znamená, že programy UDP mohou přijímat více než jednu zprávu najednou.

Všechna čísla portů UDP, která jsou menší než 1024, jsou rezervována a registrována u úřadu IANA (Internet Assigned Numbers Authority).
Čísla portů UDP a TCP se nepřekrývají.

Každý port UDP je identifikován vyhrazeným nebo známým číslem portu. Následující tabulka ukazuje částečný seznam známých čísel portů UDP, které používají standardní programy UDP.

UDP používá jednoduchý přenosový model bez implicitního handshake, aby byla zajištěna spolehlivost, řazení nebo integrita dat. Proto UDP poskytuje nespolehlivou službu a datagramy mohou přijít mimo provoz, být duplikovány nebo zmizet beze stopy. UDP znamená, že kontrola chyb a opravy buď nejsou nutné, nebo je musí provádět aplikace. Aplikace citlivé na čas často používají UDP, protože je vhodnější zahazovat pakety, než čekat na zpožděné pakety, což v systémech pracujících v reálném čase nemusí být možné. Pokud je potřeba opravit chyby na vrstvě síťového rozhraní, může aplikace použít TCP nebo SCTP k tomu určené.

Povaha UDP jako bezstavového protokolu je také užitečná pro servery reagující na malé požadavky od velkého počtu klientů, jako jsou DNS a aplikace pro streamování médií, jako je IPTV, Voice over IP, protokoly tunelování IP a mnoho online her.

Servisní porty

UDP neposkytuje žádné záruky doručení zpráv protokolu vyšší vrstvy a neukládá stav odeslaných zpráv. Z tohoto důvodu se UDP někdy nazývá Unreliable Datagram Protocol.

Před vypočítáním kontrolního součtu je UDP zpráva na konci doplněna nulovými bity na délku, která je násobkem 16 bitů (se zprávou se neposílají pseudozáhlaví a další nulové bity). Pole kontrolního součtu v hlavičce UDP během výpočtu kontrolního součtu odesláno zprávy jsou přijímány jako null.

Pro výpočet kontrolního součtu se pseudozáhlaví a zpráva UDP rozdělí na slova (1 slovo = 2 byty (oktety) = 16 bitů). Poté se vypočítá bitový doplněk součtu všech slov s bitovým doplňkem. Výsledek se zapíše do odpovídajícího pole v hlavičce UDP.

Hodnota kontrolního součtu nula je rezervována a znamená, že datagram nemá kontrolní součet. Pokud je vypočtený kontrolní součet roven nule, pole je vyplněno binárními jednotkami.

Když je zpráva přijata, příjemce vypočítá kontrolní součet znovu (s přihlédnutím k poli kontrolního součtu), a pokud je výsledkem binární číslo šestnáct jedniček (tj. 0xffff), pak se kontrolní součet považuje za konvergovaný. Pokud se součet nesčítá (data byla poškozena během přenosu), datagram je zničen.

Příklad výpočtu kontrolního součtu

Vypočítejme například kontrolní součet několika 16bitových slov: 0x398a, 0xf802, 0x14b2, 0xc281. Najděte jejich součet s bitovým doplňkem.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
Nyní najdeme bitový doplněk výsledného výsledku:

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e nebo, jinak - 0xffff − 0x08c1 = 0xf73e . Toto je požadovaný kontrolní součet.

Při výpočtu kontrolního součtu se opět používá pseudo-hlavička simulující skutečnou IPv6 hlavičku:

Bity	0 – 7	16 – 23	24 – 31
0	Adresa zdroje
32
64
96
128	Adresa příjemce
160
192
224
256	Délka UDP
288	Nuly		Další titul
320	Zdrojový port	Cílový přístav
352	Délka	Kontrolní součet
384+	Data

Zdrojová adresa je stejná jako v hlavičce IPv6. Adresa příjemce - konečný příjemce; pokud paket IPv6 neobsahuje hlavičku směrování, pak to bude cílová adresa z hlavičky IPv6, jinak to bude na počátečním uzlu adresa posledního prvku směrovací hlavičky a na přijímacím uzlu, cílovou adresu z hlavičky IPv6. Hodnota Next Header je rovna hodnotě protokolu - 17 pro UDP. Délka UDP - délka UDP hlavičky a dat.

Spolehlivost a řešení problémů s přetížením

Kvůli nedostatečné spolehlivosti musí být UDP aplikace připraveny na určité ztráty, chyby a duplikace. Některé z nich (například TFTP) mohou volitelně přidat elementární mechanismy spolehlivosti na aplikační úrovni.

Častěji však takové mechanismy aplikace UDP nepoužívají a dokonce do nich zasahují. Streamování médií, hry pro více hráčů v reálném čase a VoIP jsou příklady aplikací, které často používají protokol UDP. V těchto konkrétních aplikacích ztráta paketů obvykle nepředstavuje velký problém. Pokud aplikace vyžaduje vysokou úroveň spolehlivosti, lze použít jiný protokol (TCP) nebo kódy výmazu.

Větším potenciálním problémem je, že na rozdíl od TCP nemají aplikace založené na UDP nutně dobré mechanismy řízení zahlcení a zamezení. Aplikace UDP citlivé na přetížení, které spotřebovávají významnou část dostupné šířky pásma, mohou ohrozit stabilitu internetu.

Síťové mechanismy byly navrženy tak, aby minimalizovaly potenciální účinky přetížení během nekontrolovaného vysokorychlostního zatížení. Síťové prvky, jako jsou směrovače, které používají fronty paketů a techniky zahazování, jsou často jedinými dostupnými nástroji ke zpomalení nadměrného provozu UDP. DCCP (Datagram Congestion Control Protocol) je navržen jako částečné řešení tohoto potenciálního problému přidáním mechanismů ke koncovému hostiteli pro monitorování přetížení vysokorychlostních UDP toků, jako jsou streamovaná média.

Aplikace

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

Hlasový a video provoz je obvykle přenášen pomocí UDP. Protokoly pro streamování živého videa a zvuku jsou navrženy tak, aby zvládaly náhodné ztráty paketů, takže kvalita je pouze mírně snížena namísto způsobení velkých zpoždění při opětovném přenosu ztracených paketů. Protože TCP i UDP fungují ve stejné síti, mnoho společností si všimlo, že nedávný nárůst provozu UDP z těchto aplikací v reálném čase omezuje výkon aplikací TCP, jako jsou databáze nebo účetní systémy. Protože jsou pro společnosti důležité jak obchodní aplikace, tak aplikace v reálném čase, někteří považují vývoj kvalitních řešení problémů za nejvyšší prioritu.

Srovnání UDP a TCP

TCP je protokol orientovaný na spojení, což znamená, že k navázání spojení mezi dvěma hostiteli je vyžadováno „podání ruky“. Po navázání spojení mohou uživatelé odesílat data oběma směry.

Spolehlivost- TCP spravuje potvrzování zpráv, opakované vysílání a časový limit. Probíhají četné pokusy o doručení zprávy. Pokud se cestou ztratí, server si ztracenou část vyžádá znovu. S TCP nechybí žádná data ani (v případě více timeoutů) přerušená spojení.

Uspořádanost- Pokud jsou za sebou odesílány dvě zprávy, první zpráva dorazí do aplikace příjemce jako první. Pokud části dat dorazí ve špatném pořadí, TCP odešle data mimo pořadí do vyrovnávací paměti, dokud nebude možné všechna data objednat a odeslat do aplikace.

Těžkost- TCP vyžaduje tři pakety k vytvoření soketového spojení před odesláním dat. TCP monitoruje spolehlivost a přetížení.

Řezání závitů- data jsou čtena jako proud bajtů, nejsou přenášena žádná speciální označení hranic zpráv nebo segmentů.

UDP je jednodušší protokol bez připojení založený na zprávách. Tyto typy protokolů nenavazují vyhrazené spojení mezi dvěma hostiteli. Komunikace se dosahuje předáváním informací jedním směrem od zdroje k příjemci bez kontroly připravenosti nebo stavu příjemce. Hlavní výhoda UDP oproti TCP je však v aplikacích Voice over Internet Protocol (VoIP), kde by jakékoli podání ruky bránilo dobré hlasové komunikaci. Ve VoIP se od koncových uživatelů očekává, že v reálném čase poskytnou veškeré potřebné potvrzení o přijetí zprávy.

Nespolehlivý- při odeslání zprávy se neví, zda dorazí do cíle - může se cestou ztratit. Neexistují žádné takové pojmy jako potvrzení, opětovné odeslání, časový limit.

Porucha- pokud jsou dvě zprávy zaslány stejnému příjemci, nelze předvídat pořadí, ve kterém dosáhnou cíle.

Lehkost- žádné řazení zpráv, žádné sledování spojení atd. Je to malá transportní vrstva navržená v IP.

Datagramy- pakety jsou odesílány jednotlivě a jejich integrita je kontrolována pouze v případě, že dorazí. Pakety mají určité hranice, které jsou po přijetí respektovány, což znamená, že operace čtení na přijímajícím soketu vytvoří zprávu tak, jak byla původně odeslána.

Žádná kontrola přetížení- UDP se sám o sobě nevyhne přetížení. Je možné, že aplikace s velkou šířkou pásma způsobí kolaps zahlcení, pokud neimplementují ovládací prvky na úrovni aplikace.

Odkazy RFC

RFC 768 – User Datagram Protocol
RFC 2460 – specifikace internetového protokolu verze 6 (IPv6)
RFC 2675 – Jumbogramy IPv6
RFC 4113 – Management Information Base pro UDP
RFC 5405 – Pokyny pro jednosměrové použití UDP pro návrháře aplikací

Viz také

Odkazy

Kurose, J. F.; Ross, K. W. (2010). Počítačové sítě: přístup shora dolů (5. vydání). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
Forouzan, B.A. (2000). TCP/IP: Sada protokolů, 1. vydání. Nové Dillí, Indie: Tata McGraw-Hill Publishing Company Limited.
[e-mail chráněný]. "Přehled protokolu UDP". IPv6.com. Staženo 17. srpna 2011.
Clark, M.P. (2003). Datové sítě IP a Internet, 1. vyd. Západní Sussex, Anglie: John Wiley & Sons Ltd.
Postel, J. (srpen 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Převzato z http://tools.ietf.org/html/rfc768
Deering S. & Hinden R. (prosinec 1998). RFC 2460: Internetový protokol, specifikace verze 6 (IPv6). Internet Engineering Task Force. Převzato z http://tools.ietf.org/html/rfc2460
„Vliv UDP na datové aplikace“ . networkperformancedaily.com. Staženo 17. srpna 2011.
D. Comer. Práce s internetem pomocí TCP/IP. Kapitola 11. Protokol UDP.

Základní protokoly TCP/IP podle úrovní modelu OSI (Seznam portů TCP a UDP)
Fyzikální
Potrubí

Ahoj všichni, dnes vám řeknu, jak se protokol TCP liší od UDP. Protokoly transportní vrstvy, další v hierarchii po IP, se používají k přenosu dat mezi aplikačními procesy běžícími na síťových uzlech. Datový paket přijatý z jednoho počítače do druhého přes internet musí být přenesen do zpracovatelského procesu, a to přesně pro konkrétní účel. Odpovědnost za to přebírá transportní vrstva. Na této úrovni existují dva hlavní protokoly – TCP a UDP.

Co znamenají TCP a UDP?

TCP– transportní protokol pro přenos dat v sítích TCP/IP, který předběžně naváže spojení se sítí.

UDP– transportní protokol, který přenáší datagramové zprávy bez nutnosti navazování spojení v IP síti.

Dovolte mi připomenout, že oba protokoly fungují na transportní vrstvě modelu OSI nebo TCP/IP a je velmi důležité pochopit, jak se liší.

Rozdíl mezi protokoly TCP a UDP

Rozdíl mezi protokoly TCP a UDP je tzv. „garance doručení“. TCP vyžaduje odpověď od klienta, kterému je datový paket doručen, potvrzení doručení a k tomu potřebuje předem vytvořené spojení. Také protokol TCP je považován za spolehlivý, zatímco UDP dokonce obdržel název „nespolehlivý datagramový protokol“. TCP eliminuje ztrátu dat, duplikaci a míchání paketů a zpoždění. UDP toto vše umožňuje a ke své práci nevyžaduje připojení. Procesy, které přijímají data prostřednictvím UDP, si musí vystačit s tím, co přijímají, a to i se ztrátami. TCP řídí zahlcení spojení, UDP neřídí nic jiného než integritu přijímaných datagramů.

Na druhou stranu, kvůli takové neselektivitě a nedostatku kontroly, UDP doručuje datové pakety (datagramy) mnohem rychleji, proto pro aplikace, které jsou určeny pro širokou šířku pásma a rychlou výměnu, lze UDP považovat za optimální protokol. Patří mezi ně síťové a prohlížečové hry, stejně jako programy pro sledování streamovaného videa a aplikace pro video komunikaci (nebo hlas): úplná nebo částečná ztráta balíčku nic nemění, není nutné opakovat požadavek, ale stahování je mnohem rychlejší. Protokol TCP, který je spolehlivější, se úspěšně používá i v e-mailových programech, což vám umožňuje řídit nejen provoz, ale také délku zprávy a rychlost výměny provozu.

Podívejme se na hlavní rozdíly mezi tcp a udp.

TCP garantuje doručení datových paketů v nezměněné podobě, sekvenci a beze ztrát, UDP negarantuje nic.
TCP čísluje pakety tak, jak jsou přenášeny, ale UDP ne.
TCP pracuje v plně duplexním režimu, v jednom paketu můžete odeslat informaci a potvrdit příjem předchozího paketu.
TCP vyžaduje předem vytvořené spojení, UDP spojení nevyžaduje, je to jen datový tok.
UDP poskytuje vyšší rychlost přenosu dat.
TCP je spolehlivější a řídí proces výměny dat.
UDP je vhodnější pro programy, které přehrávají streamované video, videotelefonii a telefonování a síťové hry.
UPD neobsahuje funkce pro obnovu dat

Mezi příklady aplikací UDP patří například přenos DNS zón do Active Directory, kde není vyžadována spolehlivost. Lidé velmi často rádi kladou takové otázky během rozhovorů, takže je velmi důležité znát rozdíly mezi tcp a udp.

TCP a UDP hlavičky

Podívejme se, jak vypadají hlavičky obou transportních protokolů, protože i zde jsou rozdíly zásadní.

UDP hlavička

16bitový zdrojový port > Zadání zdrojového portu pro UDP je volitelné. Pokud je toto pole použito, může příjemce odeslat odpověď na tento port.
16bitový cílový port > Číslo cílového portu
16bitová délka UDP > Délka zprávy včetně hlavičky a dat.
16bitový kontrolní součet > Kontrolní součet záhlaví a dat pro ověření

TCP hlavička

16bitový zdrojový port > Číslo zdrojového portu
16bitový cílový port > Číslo cílového portu
32bitové pořadové číslo > Pořadové číslo je generováno zdrojem a používáno v cíli k přeuspořádání paketů za účelem vytvoření původní zprávy a odeslání potvrzení zdroji.
32bitové potvrzovací číslo > Pokud je nastaven bit ACK v poli Control, toto pole obsahuje další očekávané pořadové číslo.
4 bitová délka hlavičky > Informace o začátku datového paketu.
rezerva > Rezervováno pro budoucí použití.
16bitový kontrolní součet > Kontrolní součet záhlaví a dat; určuje, zda byl paket poškozen.
16bitový indikátor naléhavosti > Toto pole poskytuje cílovému zařízení informace o naléhavosti dat.
Možnosti > Volitelné hodnoty, které lze zadat podle potřeby.

Velikost okna umožňuje šetřit provoz, uvažujme, když je jeho hodnota 1, pak u každé odeslané odpovědi odesílatel čeká na potvrzení, ne zcela racionální.