Jak se protokol tcp liší od udp. Jaký je zjednodušeně řečeno rozdíl mezi TCP a UDP. protokol ARP. Aplikace

UDP (User Datagram Protocol) je transportní protokol pro přenos dat přes IP sítě bez navazování spojení. Je jedním z nejvíce jednoduché protokoly transportní vrstva modelu OSI. Jeho IP ID je 0x11.

UDP se běžně používá v aplikacích, jako je streamování videa a počítačové hry, kde je přijatelná ztráta paketů a opakování požadavku je obtížné nebo neodůvodněné, nebo v aplikacích typu výzva-odpověď (jako jsou dotazy DNS), kde vytvoření připojení vyžaduje více prostředků než opětovné odeslání. Vlastně Funkce UDP zredukovat na operace multiplexování a demultiplexování a také na jednoduchou kontrolu chyb v datech. Při použití U DP tedy aplikace komunikuje téměř přímo s protokolem síťové vrstvy IP.

UDP přijímá zprávy z aplikační vrstvy, přidává pole zdrojového a cílového portu pro demultiplexování přijímačem a také dvě další speciální pole a předává výsledný segment síťové vrstvě. Síťová vrstva zabalí segment do datagramu a předá jej „pokud je to možné“ cílovému hostiteli. Pokud tento segment úspěšně přijme, UDP předá data segmentu pomocí pole čísla cílového portu správný proces. Proto se říká, že UDP přenáší přenos dat bez připojení.

Příkladem protokolu aplikační vrstvy, který používá služby protokolu UDP, je DNS. Když aplikace DNS vygeneruje dotaz, vytvoří zprávu DNS a předá ji protokolu UDP.

Porovnání protokolů UDP a TCP.

Pokud aplikace vyžaduje potvrzení o doručení zprávy, použije protokol TCP. TCP rozdělí zprávu na fragmenty menší velikost, nazývané segmenty. Tyto segmenty jsou postupně očíslovány a předány protokolu IP, který pakety sestavuje. TCP sleduje počet segmentů odeslaných konkrétnímu hostiteli konkrétní aplikací. Pokud odesílatel neobdrží potvrzení do určité období TCP považuje tyto segmenty za ztracené a odešle je znovu. Znovu se odešle pouze ztracená část zprávy, nikoli celá zpráva.

Protokol TCP v přijímacím uzlu je zodpovědný za opětovné sestavení segmentů zprávy a jejich přenos do příslušné aplikace.

FTP a HTTP jsou příklady aplikací, které používají TCP k doručování dat.

Protokol UDP provádí nezaručené doručení dat a nepožaduje potvrzení od příjemce. Pro přenos je vhodnější protokol UDP streamování zvuku, video a hlasová komunikace založená na internetovém protokolu (VoIP). Potvrzení doručení pouze zpomalí proces přenosu dat a opětovné doručení se nedoporučuje. Příkladem použití protokolu UDP je internetové rádio.

protokol ARP. Aplikace.

ARP(Angličtina) Protokol pro rozlišení adres- protokol určení adresy) - používá se v počítačové sítě protokol nízká úroveň navržený k určení adresy spojové vrstvy ze známé adresy síťové vrstvy. Tento protokol se nejvíce rozšířil díky všudypřítomnosti IP sítí postavených na Ethernetu, protože v téměř 100 % případů se s touto kombinací používá ARP. Popis protokolu byl publikován v listopadu 1982 v RFC 826. ARP byl navržen pro případ přenosu IP paketů přes ethernetový segment. Obecný princip navržený pro ARP mohl být zároveň použit pro jiné typy sítí.

Existují následující typy zpráv ARP: požadavek ARP a odpověď ARP. Odesílající systém používá k vyžádání požadavek ARP fyzická adresa systém příjemců. Odpověď (fyzická adresa cílového hostitele) přichází ve formě odpovědi ARP.

Před přenosem paketu síťové vrstvy přes segment Ethernet síťový zásobník zkontroluje mezipaměť ARP, zda v ní již není zaregistrován potřebné informace o přijímacím uzlu. Pokud v mezipaměti ARP není žádná taková položka, je proveden požadavek na vysílání ARP. Tento dotaz na zařízení v síti má následující význam: "Ví někdo fyzickou adresu zařízení, které má následující IP adresu?" Když příjemce s touto IP adresou obdrží tento paket, bude muset odpovědět: „Ano, toto je moje IP adresa. Moje fyzická adresa je: …“ Odesílatel poté aktualizuje svou mezipaměť ARP a bude moci předávat informace příjemci.

Záznamy mezipaměti ARP mohou být statické nebo dynamické. Výše uvedený příklad popisuje záznam dynamické mezipaměti. Můžete také vytvořit statické položky v tabulce ARP.

ARP byl původně vyvinut nejen pro protokol IP, ale nyní se primárně používá k mapování IP a MAC adres.

Princip fungování

Uzel, na který je potřeba namapovat IP adresu místní adresa, vygeneruje požadavek ARP, vloží jej do rámce protokolu linkové vrstvy s uvedením známé IP adresy v něm a odešle požadavek.

Všichni hostitelé v místní síti obdrží požadavek ARP a porovnají tam uvedenou IP adresu se svou vlastní.

Pokud se shodují, uzel vygeneruje odpověď ARP, ve které uvede svou IP adresu a svou lokální adresu a odešle ji již směrovanou, protože v požadavku ARP uvede odesílatel svou lokální adresu.

Moc se mi líbí celá série článků a navíc jsem se vždycky chtěla vyzkoušet jako překladatelka. Možná, zkušení vývojářiČlánek se bude zdát příliš samozřejmý, ale zdá se mi, že v každém případě bude užitečný.

Dobrý den, jmenuji se Glenn Fiedler a vítám vás u prvního článku v mé online knize Network Programming for Game Developers.

V tomto článku začneme tím nejvíce základní aspekty síťové programování- příjem a přenos dat po síti. Příjem a přenos dat je hlavní a nejdůležitější jednoduchá část z celé škály úkolů, kterými se síťoví programátoři zabývají, ale často je obtížné určit, kterou cestou je nejlepší se vydat. Této části věnujte dostatečnou pozornost – pokud zůstanete s nedorozuměním, může to mít později pro vaši hru pro více hráčů hrozné následky!

S největší pravděpodobností jste již něco o soketech slyšeli a možná víte, že existují ve dvou hlavních typech – TCP a UDP. První věc, kterou se musíte při vývoji hry pro více hráčů rozhodnout, je, jaký typ socketů použít – TCP, UDP nebo oba?

Výběr typu zásuvky zcela závisí na žánru hry, kterou vyvíjíte. V tento cyklusčlánky, budu předpokládat, že píšete akční hru - jako Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress atd.

Nyní se blíže podíváme na vlastnosti jednotlivých typů socketů (s přihlédnutím k faktu, že vyvíjíme hru v akčním stylu), a půjdeme trochu hlouběji do detailů fungování internetu. Po podrobném přezkoumání správná možnost bude zřejmé!

TCP znamená „protokol řízení přenosu“ a IP znamená „internetový protokol“. Společně podporují téměř vše, co děláte online, od procházení webu po IRC a e-mailovou komunikaci – vše běží na TCP/IP.

Pokud jste někdy používali TCP sockety, pak byste měli vědět, že TCP je protokol, který využívá principu spolehlivého spojení. To znamená, že navážete spojení mezi dvěma počítači a poté mezi nimi posíláte data, stejně jako kdybyste zapisovali informace do souboru na jednom počítači a na jiném je ze stejného souboru četli.

V tomto případě je připojení považováno za spolehlivé a konzistentní – to znamená, že všechny informace, které odešlete, se zaručeně dostanou k příjemci ve stejném pořadí, v jakém byly odeslány. Také TCP spojení lze považovat za nepřetržitý proud dat – samotný protokol se stará o rozdělování dat do paketů a jejich odesílání po síti.

Ještě jednou - vše je tak jednoduché jako normální zápis nebo čtení ze souboru. Základní, Watsone!

Tato snadnost použití je však zcela odlišná od toho, co se ve skutečnosti děje „pod kapotou“, na nižší úrovni – na úrovni protokolu IP.

Na této úrovni neexistuje žádný koncept spojení – místo toho jednotlivé balíčky přenášeny z jednoho počítače do druhého. Tento proces si můžete představit jako předávání poznámky od jedné osoby druhé v místnosti plné lidí: nakonec se poznámka dostane ke správné osobě, ale zároveň projde mnoha rukama.

Neexistuje však žádná záruka, že se poznámka dostane k adresátovi. Odesílatel jednoduše pošle poznámku v naději, že dorazí, ale ani neví, zda zpráva dorazila nebo ne – dokud se příjemce nerozhodne odepsat.
Ve skutečnosti je samozřejmě vše trochu složitější, protože odesílající počítač nezná přesné pořadí počítačů v síti, přes které musí být paket přenesen, aby dorazil co nejrychleji. Někdy IP přenáší více kopií stejného paketu, které mohou mít různé cesty k dosažení cíle - a s největší pravděpodobností dorazí v různých časech.

Co když chceme přenášet informace mezi počítači ne stylem čtení/zápis souboru, ale přímým odesíláním a přijímáním jednotlivých paketů?

No, můžeme to udělat pomocí UDP. UDP je zkratka pro „protokol uživatelských datagramů“ a běží nad IP (jako TCP), ale místo přidávání tuny funkcí je to jen malý doplněk k IP.

Pomocí protokolu UDP můžeme odeslat paket na konkrétní IP adresu (například 112.140.20.10) a port (například 52423) a bude přenášen z počítače na počítač, dokud nedosáhne svého cíle (nebo se ztratí na cesta).

Zároveň na straně přijímače jen sedíme a čekáme a posloucháme konkrétní port(v našem případě 52423), a když od někoho dorazí paket (nezapomeňte, že připojení se nepoužívají), obdržíme o tom upozornění s adresou a portem odesílajícího počítače, velikostí paketu a poté můžeme číst data z tohoto balíčku.

Protokol UDP nezaručuje doručení dat. V praxi většina paketů samozřejmě dorazí, ale vždy dochází ke ztrátě cca 1-5% a někdy jsou časová období, kdy pakety nedorazí vůbec (nezapomeňte, že mezi odesílatelem a příjemcem může dojít k být tisíce počítačů, na kterémkoli z nich může selhat nebo se porouchat).

UDP také nezaručuje pořadí, ve kterém jsou pakety doručeny. Můžete odeslat pět paketů v pořadí - 1, 2, 3, 4, 5 - ale mohou dorazit ve zcela jiném pořadí - například 3, 1, 2, 5, 4. Opět v praxi budou s největší pravděpodobností přijet V ve správném pořadí ve většině případů, ale nelze se na to spolehnout!

A konečně, i když UDP IP moc nepřidává, jednu věc zaručuje. Pokud paket přepošlete, dorazí buď celý, nebo vůbec. Pokud tedy odešlete 256 bajtový paket do jiného počítače, pak nemůže přijmout pouze prvních 100 bajtů z paketu – musí přijmout všech 256 bajtů. To je skutečně jediné, co protokol UDP zaručuje – vše ostatní padá na vaše bedra.

Musíme se tedy rozhodnout, zda použít TCP resp UDP sokety? Pojďme se podívat na jejich vlastnosti:

• Využívá principu připojení
• Garantuje dodání a obrat
• Automaticky rozděluje informace do paketů
• Zajišťuje, aby data nebyla odesílána příliš intenzivně (řízení toku dat)
• Snadné použití – jako zápis/čtení ze souboru

UDP:

• Nevyužívá princip připojení - budete jej muset implementovat ručně
• Nezaručuje doručení a pořadí doručení balíků - mohou dorazit ve špatném pořadí, s duplikáty nebo nedorazí vůbec!
• Musíte ručně rozdělit data do paketů a odeslat je
• Je třeba dávat pozor, abyste data neposílali příliš intenzivně
• Pokud dojde ke ztrátě paketu, musíte jej nějak sledovat a v případě potřeby znovu odeslat

S takovým seznamem se řešení zdá nasnadě – TCP implementuje veškerou funkcionalitu, kterou potřebujeme, a je snadněji použitelný, zatímco použití UDP slibuje hemeroidy s ručním psaním všeho od nuly. Takže používáme TCP, že?

Ale ne.

Použití TCP je pravděpodobně nejhorší chyba, kterou můžete při vývoji hry pro více hráčů udělat. Abychom pochopili proč, podívejme se na to, proč je použití TCP tak snadné!

Jak funguje TCP

TCP i UDP fungují nad IP, ale ve skutečnosti jsou úplně jiné. UDP se chová velmi podobně jako IP, zatímco TCP abstrahuje uživatele od všech problémů s pakety, takže interakce je podobná čtení/zápisu do souboru.

Jak to tedy dělá?

Za prvé, TCP používá abstrakci datového toku – do tohoto toku můžete jednoduše zapisovat bajty dat a TCP se postará, aby se dostaly na místo určení. Protože IP přenáší data v paketech a TCP běží nad IP, musí TCP rozdělit vstupní proud uživatele na jednotlivé pakety. Takže uvnitř TCP nějaká logika sbírá data do fronty, a když je jich dostatek, vytvoří paket a odešle je na místo určení.

Toto chování by mohlo být problémem pro naši hru pro více hráčů, pokud potřebujeme přenášet velmi malé pakety. Může se stát, že se TCP rozhodne nepřenášet naše data, dokud se jich nenashromáždí dost na vytvoření paketu určité velikosti (řekněme více než sto bajtů). A to je velký problém, protože je potřeba co nejrychleji přenést data z klienta (stisknutí kláves hráče) na server a pokud dojde ke zpoždění kvůli ukládání dat do vyrovnávací paměti protokolem, tak pro hráče na straně klienta hra nebude nejpříjemnější. V tomto případě dojde k aktualizaci herních objektů se zpožděním a zřídka - zatímco my potřebujeme aktualizovat objekty včas a často.

TCP má možnost to opravit - "TCP_NODELAY". Sděluje protokolu, aby nečekal, až se data nashromáždí ve frontě odesílání, ale aby je okamžitě odeslal.

Bohužel, i když je tato možnost nainstalována, má TCP při použití mnoho problémů síťové hry.

Kořen všech problémů spočívá ve způsobu, jakým TCP zpracovává ztracené nebo neuspořádané pakety, čímž vytváří iluzi spolehlivého a konzistentního připojení.

Jak TCP zajišťuje spolehlivost připojení

Na TCP přenos rozděluje datový tok na jednotlivé pakety, odesílá je po síti pomocí nespolehlivého protokolu IP a poté je rekonstruuje z přijímajícího počítače přijaté pakety původní tok.

Co se ale stane, když jeden z paketů nedorazí? Nebo když balíčky dorazí nefunkční nebo s duplikáty?

Aniž bychom se příliš hluboce zabývali podrobnostmi o tom, jak TCP funguje (a to je opravdu velmi složité téma – můžete si to přečíst v TCP/IP Illustrated), proces vypadá takto: TCP odešle paket, zjistí, že paket nedorazil a znovu odešle stejný paket příjemci. Na straně příjemce jsou eliminovány duplicitní pakety a pakety, které dorazí mimo pořadí, jsou přeřazeny tak, aby bylo vše tak, jak má být – spolehlivě a v pořádku.

Problém je v tom, že když TCP „synchronizuje“ datový tok tímto způsobem, dojde v případě ztráty paketu k zastavení přenosu, dokud není ztracený paket znovu odeslán (a přijat cílem). Pokud nová data dorazí během čekání, budou zařazena do fronty a nebudete je moci číst, dokud nedorazí stejný ztracený paket. Jak dlouho trvá opětovné odeslání balíčku? Zabere to alespoň dobu oběhu paketu (když TCP určí, který paket je třeba znovu odeslat), plus dobu, kterou zabere opětovné doručení ztraceného paketu. Takže pokud je ping mezi počítači 125 ms, retransmisi paket bude trvat asi jednu pětinu sekundy a v nejhorším případě až půl sekundy (představte si, že se náhle ztratí i nově odeslaný paket). Veselukha!

Proč byste nikdy neměli používat TCP pro hry pro více hráčů

Problém s používáním TCP v online hrách je ten, že na rozdíl od prohlížečů e-mail a další aplikace spoléhají hry na interakci v reálném čase. Pro mnoho aspektů hry, jako jsou klávesy stisknuté uživatelem a pozice hráčů ve hře, nezáleží na tom, co se stalo před sekundou, důležitý je pouze nejaktuálnější stav herní svět.

Podívejme se na jednoduchý příklad hry pro více hráčů, jako je 3D střílečka. Síťová část Hra je strukturována velmi jednoduše: při každé iteraci herního cyklu klient odešle na server popis všech akcí hráče (stisknutí kláves, pozice myši atd.) a při každé iteraci server tato data zpracuje, aktualizuje model herního světa a odešle zpět aktuální pozice objektů do klientského světa, aby pro hráče nakreslil nový rámec.

Takže v naší hře, pokud dojde ke ztrátě paketu při přenosu po síti, hra se zastaví a čeká, dokud nebude paket znovu doručen. Na straně klienta zamrznou herní objekty a na serveru se hráči také nemohou pohybovat nebo střílet, protože server nemůže přijímat nové pakety. Když ztracený paket konečně dorazí, obsahuje zastaralé informace, které již nejsou relevantní. Navíc poté dorazí také všechny pakety, které se nashromáždily ve frontě během čekací doby, a všechny je třeba zpracovat v jedné iteraci smyčky. Úplný zmatek!

Bohužel neexistuje způsob, jak toto chování TCP změnit a není to ani potřeba, protože to je význam TCP. To je nutnost, aby přenos dat přes internet byl spolehlivý a konzistentní datový tok.
Ale nepotřebujeme spolehlivý a konzistentní datový tok.

Potřebujeme, aby se data dostala od klienta na server co nejrychleji, a nechceme čekat na opětovné odeslání dat.
To je důvod, proč byste nikdy neměli používat TCP pro hry pro více hráčů.

Ale počkej! Proč nemohu používat UDP i TCP společně?

Pro herní data v reálném čase, jako jsou kliknutí uživatelů a stav herního světa, jsou důležitá pouze nejaktuálnější data, ale pro jiné typy dat, jako jsou sady příkazů zasílané z jednoho počítače do druhého, spolehlivost a konzistence kanálu. může být velmi důležité.

Samozřejmě je lákavé používat UDP pro vstup uživatele a data o světovém stavu a TCP pro data, jejichž doručení musí být zaručeno. Možná si dokonce říkáte, že byste mohli vytvořit několik „vláknů“ příkazů – například jeden pro načítání úrovní, další pro příkazy AI. Říkáte si: „Nepotřebuji týmy AI čekat ve frontě, pokud se datový paket k načtení úrovně ztratí, protože spolu vůbec nesouvisejí!“ V tomto případě máte pravdu a můžete se rozhodnout vytvořit TCP soket pro každý příkazový proud.

Na první pohled tohle skvělý nápad. Problém je ale v tom, že protože TCP i UDP běží nad IP, pakety obou protokolů se budou vzájemně ovlivňovat - již na úrovni IP. Jak přesně se tento efekt projeví, je velmi složitá otázka a souvisí s mechanismy spolehlivosti v TCP. V každém případě si však uvědomte, že použití TCP obvykle vede ke zvýšené ztrátě paketů UDP. Pokud se o tom chcete dozvědět více, můžete si přečíst

protokol UDP

User Datagram Protocol (UDP) je jednoduchý protokol bez připojení, orientovaný na datagram, který poskytuje rychlou, ale ne nutně spolehlivou přepravní službu. Podporuje interakce typu one-to-many, a proto se často používá pro vysílání a multicast přenos datagramů.

Internetový protokol (IP) je hlavním protokolem Internetu. Transmission Control Protocol (TCP) a UDP jsou protokoly transportní vrstvy postavené na základním protokolu.

TCP/IP je sada protokolů, nazývaná také Internet Protocol Suite, sestávající ze čtyř vrstev. Pamatujte, že TCP/IP není jen jeden protokol, ale rodina nebo sada protokolů, která se skládá z dalších protokolů nižší úrovně, jako jsou IP, TCP a UDP. UDP je umístěn v transportní vrstvě nad IP (protokol síťové vrstvy). Transportní vrstva zajišťuje komunikaci mezi sítěmi prostřednictvím bran. Využívá IP adresy k odesílání datových paketů přes internet nebo jinou síť pomocí různých ovladačů zařízení.

Než se začneme učit, jak UDP funguje, podívejme se na základní terminologii, kterou musíte dobře znát. Níže stručně definujeme hlavní pojmy spojené s UDP:

Balíčky

V datové komunikaci je paket posloupnost binárních číslic představujících data a řídicí signály, které jsou přenášeny a přepínány prostřednictvím hostitele. Uvnitř balení jsou tyto informace umístěny v souladu se speciálním formátem.

Datagramy

Datagram je jediný, nezávislý paket dat, který nese dostatek informací pro cestu od zdroje k cíli, takže není vyžadován žádný další provoz mezi zdrojem, cílem a transportní sítí.

MTU (max Přenosová jednotka)

MTU charakterizuje odkazová vrstva a odpovídá maximálnímu počtu bajtů, které lze přenést v jednom paketu. Jinými slovy, MTU je největší paket, který může dané síťové prostředí přenášet. Například Ethernet má pevnou MTU 1500 bajtů. Pokud je v UDP velikost datagramu větší než MTU, protokol IP provede fragmentaci rozdělením datagramu na menší části (fragmenty), takže každý fragment je menší než MTU.

Porty

Aby bylo možné přiřadit příchozí data ke konkrétnímu procesu běžícímu na počítači, používá UDP porty. UDP předá paket na příslušné místo pomocí čísla portu uvedeného v hlavičce UDP datagramu. Porty jsou reprezentovány 16bitovými čísly, a proto nabývají hodnot od 0 do 65 535 Porty, které se také nazývají koncové body logického připojení, jsou rozděleny do tří kategorií:

Dobře známé porty - od 0 do 1023

Registrované porty - od 1024 do 49151

Dynamické/soukromé porty – 49152 až 65535

Všimněte si, že porty UDP mohou přijímat více než jednu zprávu v danou chvíli. V některých případech mohou služby TCP a UDP používat stejná čísla portů, například 7 (Echo) nebo 23 (Telnet).

UDP používá následující známé porty:

Seznam portů UDP a TCP spravuje IANA (Internet Assigned Numbers Authority).

IP adresy

IP datagram se skládá z 32bitových zdrojových a cílových IP adres. Cílová IP adresa určuje koncový bod pro UDP datagram a zdrojová IP adresa se používá k získání informací o tom, kdo zprávu odeslal. V cíli jsou pakety filtrovány a ty, jejichž zdrojové adresy nejsou zahrnuty v platné sadě adres, jsou bez upozornění odesílateli zahozeny.

Unicast IP adresa jednoznačně identifikuje hostitele v síti, zatímco multicast IP adresa identifikuje konkrétní skupina adresy v síti. Broadcastové IP adresy jsou přijímány a zpracovávány všemi hostiteli v místní síti nebo určité podsíti.

TTL

Hodnota time-to-live neboli TTL (time-to-live) umožňuje nastavit horní hranici počtu routerů, kterými může datagram projít. Hodnota TTL zabraňuje dosažení paketů nekonečné smyčky. Inicializuje jej odesílatel a každý směrovač, který zpracovává datagram, sníží o jednu. Když se hodnota TTL stane nulovou, datagram se zahodí.

Skupinová pošta

Multicast je otevřená metoda založená na standardech pro distribuci identických informací více uživatelům současně. Multicast je hlavní vlastností protokolu UDP, protokol TCP není možný. Multicast umožňuje interakci jednoho k mnoha, například umožňuje použití, jako je odesílání zpráv a pošty více příjemcům, internetové rádio nebo demo programy v reálném čase. Skupinové odesílání nezatěžuje síť tolik jako přenos, protože data jsou odesílána několika uživatelům najednou:

Jak funguje UDP

Když aplikace založená na UDP odešle data jinému hostiteli v síti, UDP k nim připojí osmibitovou hlavičku obsahující čísla cílového a zdrojového portu, celkovou délku dat a kontrolní součet. IP přidá svou hlavičku na datagram UDP a vytvoří datagram IP:

Předchozí obrázek ukazuje, že celková délka hlavičky UDP je osm bajtů. Teoreticky maximální velikost IP datagram má 65 535 bajtů. S 20 bajty hlavičky IP a 8 bajty hlavičky UDP může být délka uživatelských dat až 65 507 bajtů. Většina programů však pracuje s menší velikostí dat. Pro většinu aplikací je tedy výchozí délka přibližně 8192 bajtů, protože toto je množství dat, které síť čte a zapisuje. souborový systém(NFS). Můžete nastavit velikosti vstupní a výstupní vyrovnávací paměti.

Kontrolní součet je nutný ke kontrole, zda byla data doručena na místo určení správně nebo byla poškozena. Pokrývá jak hlavičku UDP, tak data. Výplňový bajt se použije, pokud je celkový počet oktetů v datagramu lichý. Pokud je přijatý kontrolní součet nula, příjemce hlásí chybu kontrolní součet a zahodí datagram. Přestože je kontrolní součet volitelnou funkcí, vždy se doporučuje jej zahrnout.

V dalším kroku vrstva IP přidá 20 bajtů záhlaví, které obsahuje TTL, zdrojové a cílové IP adresy a další informace. Tato akce se nazývá zapouzdření IP.

Jak již bylo zmíněno, maximální velikost paketu je 65 507 bajtů. Pokud je balíček větší než výchozí Velikost MTU, pak vrstva IP rozdělí paket na segmenty. Tyto segmenty se nazývají fragmenty a proces rozdělení dat na segmenty se nazývá fragmentace. Záhlaví IP obsahuje všechny informace o fragmentu.

Když odesílající aplikace „hodí“ datagram do sítě, je směrován na cílovou IP adresu uvedenou v IP hlavičce. Při průchodu routerem se hodnota doby trvání (TTL) v hlavičce IP zkrátí o jednu.

Když datagram dorazí na daný cíl a port, vrstva IP zkontroluje jeho hlavičku, aby zjistila, zda je datagram fragmentovaný. Pokud ano, datagram se sestaví podle informací v záhlaví. Nakonec aplikační vrstva načte filtrovaná data odstraněním záhlaví.

Nevýhody UDP

Ve srovnání s TCP má UDP následující nevýhody:

Žádné potvrzovací signály. Před odesláním paketu UDP si odesílající strana nevyměňuje signály handshake s přijímající stranou. Odesílatel tedy nemá žádný způsob, jak zjistit, zda datagram dosáhl cílového systému. V důsledku toho UDP nemůže zaručit, že data budou skutečně doručena na místo určení (například pokud dojde k výpadku koncového systému nebo sítě).

Naproti tomu TCP je orientován na spojení a umožňuje komunikaci mezi hostiteli připojenými k síti pomocí paketů. TCP používá signály handshaking k ověření, že data byla úspěšně přenesena.

Pomocí relací. Povaha TCP orientovaná na připojení je podporována relacemi mezi hostiteli. TCP používá identifikátor relace ke sledování spojení mezi dvěma hostiteli. UDP nemá podporu relací kvůli své nespojenosti.

Spolehlivost. UDP nezaručuje, že příjemci bude doručena pouze jedna kopie dat. K odeslání konečný systém velké množství dat, UDP je rozděluje na malé části. UDP nezaručuje, že tyto díly budou doručeny na místo určení ve stejném pořadí, v jakém byly vytvořeny u zdroje. Naopak TCP používá čísla portů spolu s sériová čísla a pravidelně zasílaná potvrzení, aby bylo zajištěno řádné doručení dat.

Bezpečnost. TCP je bezpečnější než UDP. V mnoha organizacích firewally a směrovače neumožňují průchod UDP paketům. Je to proto, že hackeři mohou využívat porty UDP, aniž by navazovali explicitní připojení.

Řízení toku. UDP nemá řízení toku a v důsledku toho může špatně navržená aplikace UDP spotřebovat významnou část šířky pásma sítě.

Výhody UDP

Ve srovnání s TCP má UDP následující výhody:

Nebylo navázáno žádné spojení. UDP je protokol bez připojení, takže eliminuje režii spojenou s navazováním připojení. Vzhledem k tomu, že protokol UDP nepoužívá handshake, je také zabráněno zpoždění připojení. To je důvod, proč DNS upřednostňuje UDP před TCP - DNS by bylo mnohem pomalejší, kdyby běželo přes TCP.

Rychlost. UDP je rychlejší než TCP. Z tohoto důvodu mnoho aplikací preferuje UDP před TCP. Stejné věci, které činí TCP robustnějším (jako jsou signály handshake), jej také zpomalují.

Topologická diverzita. UDP podporuje komunikaci one-to-one a one-to-many, zatímco TCP podporuje pouze komunikaci one-to-one.

Režijní náklady. Práce s TCP znamená zvýšenou režii, režie vyvolaná UDP je výrazně nižší. TCP využívá výrazně více zdrojů ve srovnání s UDP operační systém a v důsledku toho se v prostředích, kde servery obsluhují mnoho klientů současně, široce používá UDP.

Velikost záhlaví. Pro každý paket je hlavička UDP dlouhá pouze osm bajtů, zatímco TCP má 20bajtová hlavička, a proto UDP spotřebovává menší šířku pásma sítě.

User Datagram Protocol (UDP)(User Datagram Protocol) je standardní protokol 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. Host, který potřebuje spolehlivá komunikace musí použít buď protokol TCP, nebo program, který bude sám sledovat sled datagramů a potvrzovat příjem 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 více snímků při přenosu video dat přes UDP není tak kritická jako při přenosu binární soubory, 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 klientem cílový hostitel, pak je číslo portu efemérní, v opačném případě (server je cíl) 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 používáním síťový analyzátor Wireshark:

UDP porty

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

Čí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. označený číslem protokolový port. 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ý UDP port identifikovaný rezervovaný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.

používá UDP jednoduchý model přenosy bez implicitního handshake, aby byla zajištěna spolehlivost, uspořádání 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é. V případě potřeby opravte chyby na úroveň sítě rozhraní, může aplikace používat TCP nebo SCTP určené pro tento účel.

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 pro protokol žádné záruky doručení zpráv nejvyšší úroveň 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.

Při příjmu zprávy příjemce znovu vypočítá kontrolní součet (s přihlédnutím k poli kontrolního součtu), a pokud je výsledek binární číslo z šestnácti jednotek (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								8 – 15								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 směrovací hlavičku, pak to bude cílová adresa z hlavičky IPv6, jinak na počátečním uzlu to bude adresa poslední prvek směrovací hlavička a na přijímajícím hostiteli - adresa příjemce 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í aplikace Ztráta paketů obvykle není velký problém. Pokud aplikace potřebuje vysoká úroveň spolehlivost, pak můžete použít jiný protokol (TCP) nebo vymazat kódy.

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é přístupný nástroj 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 kvůli těmto aplikacím v reálném čase brání výkonu 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íhá řada pokusů o doručení zprávy. Pokud se cestou ztratí, server si ztracenou část vyžádá znovu. S TCP nechybí žádná data nebo (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 kusy 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í pro hranice zpráv nebo segmenty.

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. U VoIP se tomu věří koncoví uživatelé poskytne potřebné potvrzení o přijetí zprávy v reálném čase.

• 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 odeslá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í