9.9. UDP – küldj egy csomagot, remélj a legjobbat¶
A UDP, vagyis a User Datagram Protocol, az egyszerűbb a két szolgáltatás közül, amelyet a szállítási réteg kínál. Minden UDP-küldés egy datagram – egy önálló bájtcsomag, amely egy IP-hez és egy porthoz van címezve, és önállóan dobódik a hálózatba. A protokoll kézbesíti, ha tudja; ha nem tudja, akkor nem próbálkozik újra, nem figyelmezteti a küldőt, és nem őrzi meg a datagramok közötti sorrendet.
9.9.1. Mit ad a UDP az IP-hez¶
A UDP egy vékony réteg az IP tetején. Három dolgot ad hozzá a nyers IP-kézbesítéshez:
Portszámokat mindkét végen, hogy egy datagram a célállomáson a megfelelő programhoz kézbesíthető legyen, ne csak az állomáshoz (lásd Portok).
Egy hosszmezőt, hogy a fogadó pontosan tudja, hány bájtnyi hasznos adatot kell olvasnia.
Egy kis ellenőrzőösszeget a fejlécen és a hasznos adaton, hogy a fogadó észlelhesse a sérült datagramot és eldobhassa azt.
Ennyi. Minden mást, amit az IP tett vagy nem tett, a UDP megtart. A datagramokat nem próbálják újra. Rossz sorrendben érkezhetnek meg. Az alapul szolgáló hálózat sajátosságai miatt megkettőződhetnek. Csendben eldobódhatnak, ha a hálózat torlódott, a célállomáson lévő puffer megtelt, vagy az egyik közbenső útválasztó úgy dönt.
Minden UDP-datagramot függetlenül küldenek el. Ha egy elveszik útközben, semmi nem jelzi a küldőnek vagy a fogadónak – a hiányzás csendben marad.¶
9.9.2. Miért használná bárki¶
Ha a UDP ennyire megbízhatatlan, miért van egyáltalán? Három okból.
Sebesség és többletköltség. Egy UDP-küldés egyetlen kimenő csomag; nincs kézfogás, nincsenek nyugtázások, nincs fenntartandó kapcsolatállapot. A késleltetési és sávszélességi költség minimális.
Független üzenetek. Egyes forgalmak állapotfrissítések folyamai, ahol minden üzenet egy friss pillanatkép, és egy régi értéktelen. Egy kamera, amely másodpercenként közli, hogy „még élek, itt van az aktuális mérésem”, arra törődik, hogy minden új mérést kézbesítsen, nem azzal, hogy újrajátssza az elveszett méréseket.
Multicast. Egyetlen UDP-datagram egyszerre sok fogadónak küldhető el. (A TCP ezt nem tudja megtenni; minden TCP-kapcsolat pontosan két végpont között van.) Hasznos szolgáltatásfelderítéshez, sok hallgatónak küldött telemetriához, videostreameléshez.
Ahol a hálózat jó és a küldő tűrőképessége a veszteséggel szemben magas, ott a UDP a helyes válasz. Ahol a kézbesítést és a sorrendet garantálni kell, ott a UDP-nek vagy egy újabb megbízhatósági rétegre van szüksége a tetején, vagy az alkalmazásnak inkább a TCP-t kellene használnia.
9.9.3. Mikor ne használjuk¶
Az ellenkezőjét is érdemes kifejezetten megemlíteni. A UDP rossz választás, amikor:
Minden bájt számít. Konfigurációs adatok, kódfrissítések, aláírt tranzakciók – minden olyan eset, ahol egy hiányzó bájt rosszá teszi az eredményt.
A sorrend számít. A 2-es UDP-datagram megérkezhet az 1-es datagram előtt.
Az üzenet nagy. A nagy hasznos adatokat az alkalmazásnak kisebb datagramokra kell bontania; a szállítási réteg nem teszi meg. Ha bármelyik darab elveszik, az egész üzenet hiányos.
Ha ezek bármelyike fennáll, nyúlj inkább a TCP-hez.
9.9.4. Konkrét példák egy kamerán¶
Kameraoldali példák a UDP-forgalomra a gyakorlatban:
Felderítés. Egy kamera indításkor egy „ki van itt” datagramot sugároz a helyi hálózatra; más eszközök válaszolnak.
Telemetria. Másodpercenként egyszer a kamera egy kis datagramot küld az aktuális érzékelőméréseivel egy gyűjtőnek. Az alkalmankénti minta elvesztése nem számít, mert a következő amúgy is egy másodperc múlva megérkezik.
Időszinkronizálás. Az NTP, a hálózati időprotokoll, UDP-n keresztül fut. A kliens küld egy kis kérést, a szerver az aktuális idővel válaszol; ha a válasz elveszik, a kliens egyszerűen később újra kérdez.
DNS-lekérdezések. Annak megkérdezése a hálózattól, hogy „milyen IP-re képeződik le ez a név?”, UDP-n keresztül fut. (Lásd a Nevek és DNS oldalon.)
A datagramok küldésére és fogadására szolgáló Python API a UDP socketek oldalon található, miután a szállítási réteg történetének többi része a helyén van.