| UDP | |
|---|---|
| Név | User Datagram Protocol |
| Szint ( az OSI modell szerint ) | Szállítás |
| Család | TCP/IP (néha UDP/IP-nek is nevezik) |
| Létrehozva: | 1980 [1] |
| Port/ID | 17 (IP-ben) |
| Leírás | RFC 768 / STD 6 |
| Főbb megvalósítások (kliensek) | Kernelek Windows, Linux, UNIX |
| Alapvető megvalósítások ( szerverek ) | Kernelek Windows, Linux, UNIX |
| Bővíthetőség | Nem |
| Médiafájlok a Wikimedia Commons oldalon | |
Az UDP ( User Datagram Protocol ) az internet hálózati protokolljainak egyik kulcseleme . Az UDP segítségével a számítógépes alkalmazások üzeneteket (ebben az esetben datagramoknak neveznek ) küldhetnek más gazdagépeknek IP- hálózaton keresztül anélkül, hogy előzetes kommunikációra lenne szükségük speciális átviteli csatornák vagy adatutak beállításához. A protokollt David P. Reed dolgozta ki 1980-ban, és formálisan az RFC 768 -ban határozta meg .
Az UDP egy egyszerű átviteli modellt használ, kifejezett kézfogások nélkül, hogy biztosítsa a megbízhatóságot, a rendezést vagy az adatok integritását. A datagramok rendellenesen, duplikálva, vagy teljesen nyomtalanul el is érkezhetnek, de garantált, hogy ha megérkeznek, akkor konzisztens állapotban. Az UDP azt jelenti, hogy a hibaellenőrzésre és -javításra vagy nincs szükség, vagy el kell végezni az alkalmazásban. Az időérzékeny alkalmazások gyakran használnak UDP-t, mivel jobb a csomagok eldobása, mint a késleltetett csomagok megvárása, ami valós idejű rendszerekben nem biztos, hogy lehetséges . Ha a hálózati interfész rétegben ki kell javítani a hibákat, az alkalmazás használhatja az erre a célra kialakított TCP -t vagy SCTP -t.
Az UDP állapot nélküli protokoll jellege olyan szerverek számára is hasznos, amelyek nagyszámú kliens kis kéréseire válaszolnak, mint például a DNS és a streaming médiaalkalmazások , például az IPTV , a Voice over IP , az IP tunneling protokollok és számos online játék .
Az UDP alkalmazások datagram socketeket használnak a gazdagépek közötti kapcsolat létrehozására. Egy alkalmazás egy socketet köt az adatvégpontjához, amely egy IP-cím és egy szolgáltatási port kombinációja. A port egy szoftverstruktúra, amelyet egy portszám azonosít, amely egy 16 bites egész szám (azaz 0-tól 65535-ig). A 0-s port le van foglalva, bár ez egy érvényes forrásportérték arra az esetre, ha a küldési folyamat nem vár válaszüzenetekre.
Az IANA a portszámokat három csoportra osztotta.
Az UDP egy minimális üzenet-orientált szállítási réteg protokoll, amelyet az RFC 768 dokumentál .
Az UDP nem biztosít üzenetkézbesítési garanciát az upstream protokollhoz, és nem tárolja az elküldött üzenetek állapotát. Emiatt az UDP-t néha Unreliable Datagram Protocolnak is nevezik.
Az UDP többcsatornás átvitelt biztosít (portszámokon keresztül), valamint fejléc- és alapvető adatok integritásának ellenőrzését ( ellenőrző összegeken keresztül ). A megbízható átvitelt, ha szükséges, a felhasználói alkalmazásnak kell megvalósítania.
| bitek | 0-15 | 16-31 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0-31 | Forrás port | Célkikötő | ||||||||||||||||||||||||||||||
| 32-63 | Datagram hossza (Length) | Ellenőrző összeg | ||||||||||||||||||||||||||||||
| 64-... | Adat | |||||||||||||||||||||||||||||||
Az UDP fejléc négy mezőből áll, egyenként 2 bájtos (16 bites). Ezek közül kettő nem kötelező az IPv4-ben (rózsaszín cellák a táblázatban), míg az IPv6-ban csak a forrásport nem kötelező.
Ez a mező a feladó portszámát adja meg. Feltételezzük, hogy ez az érték megadja azt a portot, amelyre szükség esetén a válasz elküldésre kerül. Ellenkező esetben az értéknek 0-nak kell lennie. Ha a forrásgazda egy kliens, akkor a portszám valószínűleg dinamikus. Ha a forrás egy szerver, akkor a portja a „jól ismert” portok közé tartozik.
Ez a mező kötelező, és tartalmazza a célportot. A forrásporthoz hasonlóan, ha a célállomás egy kliens, akkor a portszám dinamikus, ha a cél egy szerver, akkor egy "jól ismert" port lesz.
Egy mező, amely megadja a teljes datagram (fejléc és adat) hosszát bájtokban. A minimális hossz megegyezik a fejléc hosszával - 8 bájt. Elméletileg a maximális mezőméret 65535 bájt egy UDP-datagramnál (8 bájt a fejlécnél és 65527 bájt az adatoknál). Az IPv4 használatakor a tényleges adathossz-korlát 65507 (az UDP-fejlécenkénti 8 bájton kívül IP-fejlécenként további 20 bájt szükséges).
A gyakorlatban azt is figyelembe kell venni, hogy ha egy UDP-vel rendelkező IPv4-csomag hossza meghaladja az MTU -t ( Ethernet esetén az alapértelmezett 1500 bájt), akkor egy ilyen csomag elküldése a csomag töredezettségét okozhatja, ami oda vezethet, hogy hogy egyáltalán nem szállítható, ha a közbenső útválasztók vagy a végállomások nem támogatják a töredezett IP-csomagokat. Az RFC 791 egy 576 bájtos IP-csomag minimális hosszát is meghatározza, amelyet minden IPv4-résztvevőnek támogatnia kell, és csak akkor ajánlott nagyobb IP-csomagokat küldeni, ha biztos abban, hogy a fogadó fél képes ilyen méretű csomagokat fogadni. Ezért az UDP-csomagok töredezettségének (és esetleges elvesztésének) elkerülése érdekében az UDP-ben lévő adatméret nem haladhatja meg: MTU - (Max. IP-fejlécméret) - (UDP-fejléc mérete) = 1500 - 60 - 8 = 1432 bájt. Annak érdekében, hogy a csomagot bármely gazdagép megkapja, az UDP-ben megadott adatméret nem haladhatja meg: (minimális IP-csomaghossz) - (Maximális IP-fejlécméret) - (UDP-fejléc mérete) = 576 - 60 - 8 = 508 bájt [ 2] .
Az IPv6 jumbogramokban az UDP-csomagok nagyobbak lehetnek. A maximális érték 4 294 967 295 bájt (232 - 1), amelyből 8 bájt fejléc, a maradék 4 294 967 287 bájt adat.
Megjegyzendő, hogy a legtöbb modern hálózati eszköz legfeljebb 10000 bájt hosszúságú IPv4-csomagokat küld és fogad anélkül, hogy azokat külön csomagokra bontja. Informálisan az ilyen csomagokat "Jumbo csomagoknak" nevezik, bár a Jumbo fogalma hivatalosan az IPv6-ra utal. Azonban nem minden eszköz támogatja a Jumbo csomagokat, és mielőtt az 1500 bájtot meghaladó hosszúságú UDP / IP IPv4 csomagokkal történő kommunikációt megszervezné, empirikusan ellenőrizni kell az ilyen kommunikáció lehetőségét bizonyos berendezéseken [3] .
Az ellenőrző összeg mező a fejléc és az adatok hibáinak ellenőrzésére szolgál. Ha az összeget nem az adó generálja, akkor a mező nullákkal lesz kitöltve. A mező nem kötelező az IPv4 esetén.
Az ellenőrző összeg kiszámításának módszerét az RFC 1071 [4] határozza meg .
Az ellenőrzőösszeg kiszámítása előtt, ha az UDP üzenet hossza bájtban páratlan, akkor az UDP üzenet végén nulla bájt van kitöltve (az pszeudofejléc és a további nulla bájt nem kerül elküldésre az üzenettel, hanem azokat használja csak az ellenőrző összeg kiszámításakor). Az UDP fejlécben lévő ellenőrző összeg mező nullának számít az ellenőrző összeg kiszámítása során.
Az ellenőrző összeg kiszámításához a pszeudofejlécet és az UDP-üzenetet kétbájtos szavakra osztják. Ezután az összes szó összegét kiszámítja az inverz kód aritmetikája (vagyis az a kód, amelyben a pozitív számból negatív számot kapunk a szám összes bitjének invertálásával, és két nulla van: 0x0000 (jelölése + 0) és 0xffff(-0-val jelölve)). Az eredmény az UDP fejléc megfelelő mezőjébe kerül.
A 0x0000 (+0 a visszatérési kódban ) ellenőrző összeg le van foglalva, és azt jelenti, hogy az ellenőrző összeget nem számították ki a küldéshez. Ha az ellenőrző összeg kiszámítása megtörtént, és kiderült, hogy 0x0000, akkor az érték 0xffff(-0 a fordított kódban ) kerül beírásra az ellenőrző összeg mezőbe.
Az üzenet beérkezése után a vevő újra kiszámítja az ellenőrző összeget (már figyelembe véve az ellenőrző összeg mezőt), és ha az eredmény -0 (vagyis 0xffff), akkor az ellenőrző összeget konvergáltnak tekintjük. Ha az összeg nem konvergál (az adat megsérült az átvitel során, vagy az ellenőrző összeget hibásan számították ki a küldő oldalon), akkor a további intézkedésekről a fogadó oldal dönt. Általános szabály, hogy a legtöbb modern eszközben, amely UDP / IP-csomagokkal működik, vannak olyan beállítások, amelyek lehetővé teszik az ilyen csomagok figyelmen kívül hagyását vagy kihagyását a további feldolgozáshoz, függetlenül a helytelen ellenőrző összegtől.
Például számítsuk ki több 16 bites szó ellenőrző összegét: 0x398a, 0xf802, 0x14b2, 0xc281.
Ehhez először összeadhatja a számokat párban, 16 bites előjel nélküli számoknak tekintve, majd további kódra redukálva, hozzáadva egyet az eredményhez, ha az összeadás során a legmagasabb (17.) bitre történt átvitel. (vagyis de facto ezzel a művelettel egy negatív számot komplementerből inverz kódba alakítunk át ). Illetve úgy tekinthetjük, hogy a hordozást a szám legkisebb jelentőségű számjegyéhez adjuk.
0x398a + 0xf802 = 0x1318c → 0x318d (nagy sorrendű átvitel) 0x318d + 0x14b2 = 0x0463f → 0x463f (pozitív szám) 0x463f + 0xc281 = 0x108c0 → 0x08c1A végén a kapott szám minden bitje megfordul
0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73evagy másként - 0xffff − 0x08c1 = 0xf73e. Ez a kívánt ellenőrző összeg.
Az RFC 1071 [4] más módszereket is biztosít az ellenőrző összeg kiszámítására, különösen 32 bites aritmetika használatával.
Ha az UDP IPv4-en fut, az ellenőrző összeg kiszámítása egy pszeudofejléc segítségével történik, amely az IPv4-fejlécből származó információkat tartalmaz. A pszeudo fejléc nem valódi IPv4 fejléc, amelyet IP-csomag küldésére használnak. A táblázat egy pszeudofejlécet tartalmaz, amelyet csak az ellenőrzőösszeg kiszámításához használnak.
| bitek | 0-7 | 8-15 | 16-23 | 24-31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Forrás címe | |||||||||||||||||||||||||||||||
| 32 | A címzett címe | |||||||||||||||||||||||||||||||
| 64 | Nullák | Jegyzőkönyv | UDP hossza | |||||||||||||||||||||||||||||
| 96 | Forrás port | Célkikötő | ||||||||||||||||||||||||||||||
| 128 | Hossz | Ellenőrző összeg | ||||||||||||||||||||||||||||||
| 160+ | Adat | |||||||||||||||||||||||||||||||
A forrás- és célcímek az IPv4-fejlécből származnak. Az UDP Protokoll mező értéke 17 (0x11). Az "UDP Length" mező a fejléc és az adatok hosszának felel meg.
Az IPv4 ellenőrzőösszegének kiszámítása nem kötelező, ha nem használja, akkor az érték 0.
Ha IPv6 feletti UDP-vel dolgozik, meg kell adni az ellenőrző összeget. A számítási módszert közzétették az RFC 2460 -ban :
Az ellenőrző összeg kiszámításakor ismét egy pszeudo-fejlécet használunk, amely egy valódi IPv6-fejlécet imitál:
| bitek | 0-7 | 8-15 | 16-23 | 24-31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Forrás címe | |||||||||||||||||||||||||||||||
| 32 | ||||||||||||||||||||||||||||||||
| 64 | ||||||||||||||||||||||||||||||||
| 96 | ||||||||||||||||||||||||||||||||
| 128 | A címzett címe | |||||||||||||||||||||||||||||||
| 160 | ||||||||||||||||||||||||||||||||
| 192 | ||||||||||||||||||||||||||||||||
| 224 | ||||||||||||||||||||||||||||||||
| 256 | UDP hossza | |||||||||||||||||||||||||||||||
| 288 | Nullák | Következő cím | ||||||||||||||||||||||||||||||
| 320 | Forrás port | Célkikötő | ||||||||||||||||||||||||||||||
| 352 | Hossz | Ellenőrző összeg | ||||||||||||||||||||||||||||||
| 384+ | Adat | |||||||||||||||||||||||||||||||
A forráscím ugyanaz, mint az IPv6 fejlécében. Címzett címe – végső címzett; ha az IPv6 csomag nem tartalmazza a Routing fejlécet, akkor ez lesz a célcím az IPv6 fejlécből, ellenkező esetben a kezdő csomóponton ez lesz az útválasztási fejléc utolsó elemének címe, a cél csomóponton pedig a cél címét az IPv6-fejlécből. A „Next Header” értéke megegyezik a protokoll értékével – 17 UDP esetén. UDP Length – Az UDP-fejléc és az adatok hossza.
A robusztusság hiánya miatt az UDP-alkalmazásoknak fel kell készülniük bizonyos veszteségekre, hibákra és duplikációkra. Némelyikük (például a TFTP ) szükség esetén elemi mechanizmusokat is hozzáadhat az alkalmazási réteg megbízhatóságának biztosításához.
De gyakrabban az ilyen mechanizmusokat nem használják az UDP-alkalmazások, és még zavarják is őket. A streaming média , a valós idejű többjátékos játékok és a VoIP példák azokra az alkalmazásokra, amelyek gyakran használják az UDP protokollt. Ezekben az alkalmazásokban a csomagvesztés általában nem jelent nagy problémát. Ha az alkalmazásnak magas szintű megbízhatóságra van szüksége, akkor használhat másik protokollt (TCP), vagy használhat zajjavító kódolási módszereket ( Erasure code ).
Súlyosabb lehetséges probléma, hogy a TCP-vel ellentétben az UDP-alapú alkalmazások nem feltétlenül rendelkeznek jó torlódáskezelési és -elkerülési mechanizmusokkal. A torlódásra érzékeny UDP-alkalmazások, amelyek jelentős mennyiségű rendelkezésre álló sávszélességet fogyasztanak, veszélyeztethetik az internet stabilitását.
A hálózati mechanizmusokat úgy tervezték, hogy minimalizálják a torlódások hatását az ellenőrizetlen, nagy sebességű terhelésekre. A hálózati elemek, például a csomagsorolási és -öblítési technikákat használó útválasztók gyakran az egyetlen rendelkezésre álló eszköz a túlzott UDP-forgalom lelassítására. A DCCP (Datagram Congestion Control Protocol) részleges megoldást nyújt erre a lehetséges problémára azáltal, hogy olyan mechanizmusokat ad a végállomáshoz, amelyek nyomon követik a torlódást a nagy sebességű UDP adatfolyamok, például a streaming média esetében.
Számos kulcsfontosságú internetes alkalmazás használja az UDP-t, beleértve a DNS - t (ahol a lekérdezéseknek gyorsaknak kell lenniük, és csak egy lekérdezésből, majd egyetlen válaszcsomagból állhatnak), az egyszerű hálózatkezelési protokollt ( SNMP ), az útválasztási információs protokollt ( RIP ), a dinamikus gazdakonfigurációt ( DHCP ) .
A hang- és videoforgalmat általában UDP-vel továbbítják. A valós idejű video- és audiostreaming protokollokat úgy tervezték, hogy kezeljék a véletlenszerű csomagvesztést, így a minőség csak kis mértékben romlik a hosszú késleltetések helyett, amikor az elveszett csomagokat újraküldik. Mivel a TCP és az UDP is ugyanazon a hálózaton működik, sok vállalat észrevette, hogy a valós idejű alkalmazások miatti UDP-forgalom közelmúltbeli növekedése akadályozza az olyan TCP-alkalmazások teljesítményét, mint az adatbázis-rendszerek vagy a könyvelés . Mivel az üzleti és a valós idejű alkalmazások egyaránt fontosak a vállalatok számára, egyesek kiemelt prioritásnak tekintik a minőségi megoldások kidolgozását a problémákra.
A TCP egy kapcsolatorientált protokoll, ami azt jelenti, hogy "kézfogás" szükséges a kapcsolat létrehozásához két gazdagép között. A kapcsolat létrejötte után a felhasználók mindkét irányba küldhetnek adatokat.
Az UDP egy egyszerűbb, kapcsolat nélküli, üzenetalapú protokoll. Az ilyen típusú protokollok nem hoznak létre dedikált kapcsolatot két gazdagép között. A kommunikáció úgy valósul meg, hogy az információkat egy irányban továbbítják a forrástól a célállomásig anélkül, hogy ellenőriznék a célállomás készenlétét vagy állapotát. A Voice over Internet Protocol (Voice over IP, TCP/IP) alkalmazásokban az UDP előnye van a TCP-vel szemben, amelyben minden "kézfogás" zavarná a jó hangkommunikációt. A VoIP esetében feltételezzük, hogy a végfelhasználók minden szükséges valós idejű visszaigazolást adnak az üzenet megérkezéséről.
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |