UDP

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 19. lokakuuta 2018 tarkistetusta versiosta . vahvistus vaatii 21 muokkausta .
UDP
Nimi User Datagram Protocol
Taso ( OSI-mallin mukaan ) Kuljetus
Perhe TCP/IP (kutsutaan joskus UDP/IP:ksi)
Luotu vuonna 1980 [1]
Portti/ID 17 (IP:ssä)
Erittely RFC 768 / STD 6
Tärkeimmät toteutukset (asiakkaat) Ytimet Windows, Linux, UNIX
Ydintoteutukset ( palvelimet ) Ytimet Windows, Linux, UNIX
Laajennettavuus Ei
 Mediatiedostot Wikimedia Commonsissa

UDP (  User Datagram Protocol ) on yksi Internetin verkkoprotokollien joukon avainelementeistä .  UDP:n avulla tietokonesovellukset voivat lähettää viestejä (tässä tapauksessa datagrammeiksi kutsuttuja viestejä ) muille isäntäkoneille IP- verkon kautta ilman, että tarvitaan aiempaa viestintää erityisten siirtokanavien tai datapolkujen määrittämiseksi. Protokollan kehitti David P. Reed vuonna 1980, ja se määriteltiin virallisesti RFC 768 :ssa .

UDP käyttää yksinkertaista lähetysmallia ilman erityisiä kättelyjä luotettavuuden, järjestyksen tai tietojen eheyden varmistamiseksi. Datagrammit voivat saapua epäkunnossa, kopioida tai kadota kokonaan ilman jälkiä, mutta on taattu, että jos ne saapuvat, niin johdonmukaisessa tilassa. UDP tarkoittaa, että virheiden tarkistusta ja korjausta ei tarvita tai ne on suoritettava sovelluksessa. Aikaherkät sovellukset käyttävät usein UDP:tä, koska on parempi pudottaa paketit mieluummin kuin odottaa viivästyneitä paketteja, mikä ei ehkä ole mahdollista reaaliaikaisissa järjestelmissä . Jos verkkoliitäntäkerroksen virheitä on tarpeen korjata, sovellus voi käyttää tähän tarkoitukseen suunniteltuja TCP :tä tai SCTP :tä.

UDP:n luonne tilattomana protokollana on hyödyllinen myös palvelimille, jotka vastaavat pieniin pyyntöihin suurelta määrältä asiakkaita, kuten DNS- ja suoratoistomediasovellukset, kuten IPTV , Voice over IP , IP- tunnelointiprotokollat ​​ja monet verkkopelit .

Palveluportit

UDP-sovellukset käyttävät datagrammivastakkeita yhteyden muodostamiseen isäntien välille. Sovellus sitoo socketin datapäätepisteeseensä, joka on IP-osoitteen ja palveluportin yhdistelmä. Portti on ohjelmistorakenne, joka tunnistetaan portin numerolla, joka on 16- bittinen kokonaisluku (eli 0-65535). Portti 0 on varattu, vaikka se on kelvollinen lähdeportin arvo siltä varalta, että lähetysprosessi ei odota vastausviestejä.

IANA on jakanut porttinumerot kolmeen ryhmään.

Paketin rakenne

UDP on RFC 768 :ssa dokumentoitu minimaalinen viestisuuntautunut kuljetuskerroksen protokolla .

UDP ei takaa viestin toimitustakuita ylävirran protokollalle eikä tallenna lähetettyjen viestien tilaa. Tästä syystä UDP:tä kutsutaan joskus epäluotettavaksi datagrammiprotokollaksi.

UDP tarjoaa monikanavaisen lähetyksen (porttinumeroiden kautta) ja otsikko- ja olennaisten tietojen eheystarkistuksia ( tarkistussummien kautta ). Luotettava lähetys on tarvittaessa toteutettava käyttäjäsovelluksella.

bittiä 0-15 16-31
0-31 Lähdeportti Kohdeportti
32-63 Datagrammin pituus (pituus) Tarkistussumma
64-... Data

UDP-otsikko koostuu neljästä kentästä, kukin 2 tavua (16 bittiä). Kaksi niistä on valinnaisia ​​IPv4:ssä (vaaleanpunaiset solut taulukossa), kun taas IPv6:ssa vain lähdeportti on valinnainen.

Lähettäjäportti

Tämä kenttä määrittää lähettäjän portin numeron. Oletetaan, että tämä arvo määrittää portin, johon vastaus lähetetään tarvittaessa. Muussa tapauksessa arvon tulee olla 0. Jos lähdeisäntä on asiakas, portin numero on todennäköisesti dynaaminen. Jos lähde on palvelin, sen portti on yksi "tunnetuista".

Kohdeportti

Tämä kenttä on pakollinen ja sisältää kohdeportin. Samoin kuin lähdeportti, jos kohdeisäntä on asiakas, portin numero on dynaaminen, jos kohde on palvelin, se on "tuttu" portti.

Datagrammin pituus

Kenttä, joka määrittää koko datagrammin pituuden (otsikko ja tiedot) tavuina. Vähimmäispituus on yhtä suuri kuin otsikon pituus - 8 tavua. Teoreettisesti kentän maksimikoko on 65535 tavua UDP-datagrammille (8 tavua otsikolle ja 65527 tavulle datalle). Todellinen datan pituusrajoitus IPv4:ää käytettäessä on 65507 (8 tavun UDP-otsikkoa kohden lisäksi tarvitaan vielä 20 tavua IP-otsikkoa kohti).

Käytännössä tulee myös ottaa huomioon, että jos UDP:llä olevan IPv4-paketin pituus ylittää MTU :n ( Ethernetille oletusarvo on 1500 tavua), niin tällaisen paketin lähettäminen voi aiheuttaa sen pirstoutumista, mikä voi johtaa siihen, että että sitä ei voida toimittaa ollenkaan, jos välireitittimet tai pääteisäntä eivät tue pirstoutuneita IP-paketteja. RFC 791 määrittelee myös IP-paketin vähimmäispituuden 576 tavua, jota kaikkien IPv4-osallistujien on tuettava, ja on suositeltavaa lähettää suurempia IP-paketteja vain, jos olet varma, että vastaanottava osapuoli voi hyväksyä tämän kokoisia paketteja. Siksi UDP-pakettien pirstoutumisen (ja niiden mahdollisen häviämisen) välttämiseksi UDP:n datakoko ei saa ylittää: MTU - (Max IP Header Size) - (UDP Header Size) = 1500 - 60 - 8 = 1432 tavua. Jotta varmistetaan, että mikä tahansa isäntä vastaanottaa paketin, datakoko UDP:ssä ei saa ylittää: (IP-paketin vähimmäispituus) - (IP-otsikon enimmäiskoko) - (UDP-otsikon koko) = 576 - 60 - 8 = 508 tavua [2] .

IPv6-jumbogrammeissa UDP-paketit voivat olla suurempia. Suurin arvo on 4 294 967 295 tavua (232 -  1), josta 8 tavua on otsikkoa ja loput 4 294 967 287 tavua dataa.

On huomattava, että useimmat nykyaikaiset verkkolaitteet lähettävät ja vastaanottavat jopa 10 000 tavun pituisia IPv4-paketteja erottamatta niitä yksittäisiksi paketeiksi. Epävirallisesti tällaisia ​​paketteja kutsutaan "Jumbo-paketteiksi", vaikka Jumbon käsite viittaa virallisesti IPv6:een. Kaikki laitteet eivät kuitenkaan tue Jumbo-paketteja, ja ennen viestinnän järjestämistä käyttämällä UDP / IP IPv4 -paketteja, joiden pituus on yli 1500 tavua, on tarpeen tarkistaa tällaisen viestinnän mahdollisuus empiirisesti tietyillä laitteilla [3] .

Tarkistussumma

Tarkistussummakenttää käytetään tarkistamaan otsikko ja tiedot virheiden varalta. Jos lähetin ei luo summaa, kenttä täytetään nolilla. Kenttä on valinnainen IPv4:lle.

Tarkistussummalaskenta

Tarkistussumman laskentamenetelmä on määritelty standardissa RFC 1071 [4] .

Ennen tarkistussumman laskemista, jos UDP-viestin pituus tavuina on pariton, niin UDP-sanoma täytetään loppuun nollatavulla (pseudootsikkoa ja ylimääräistä nollatavua ei lähetetä viestin mukana, niitä käytetään vain tarkistussummaa laskettaessa). UDP-otsikon tarkistussummakentän oletetaan olevan nolla tarkistussumman laskennan aikana.

Tarkistussumman laskemiseksi pseudootsikko ja UDP-sanoma jaetaan kaksitavuisiksi sanoiksi. Sitten kaikkien sanojen summa lasketaan käänteiskoodin aritmetiikassa (eli koodi, jossa negatiivinen luku saadaan positiivisesta luvusta kääntämällä kaikki luvun bitit ja siinä on kaksi nollaa: 0x0000 (merkitty + 0) ja 0xffff(merkitty -0)). Tulos kirjoitetaan vastaavaan kenttään UDP-otsikossa.

Tarkistussumman arvo, joka on yhtä suuri kuin 0x0000 (+0 paluukoodissa ), on varattu ja tarkoittaa, että tarkistussummaa ei ole laskettu lähetykselle. Jos tarkistussumma laskettiin ja se osoittautui yhtä suureksi kuin 0x0000, arvo 0xffff(-0 käänteisessä koodissa ) syötetään tarkistussummakenttään.

Vastaanotettuaan viestin vastaanottaja laskee tarkistussumman uudelleen (ottaen jo huomioon tarkistussummakentän), ja jos tulos on -0 (eli 0xffff), niin tarkistussumman katsotaan konvergoivan. Jos summa ei konvergoi (tiedot vioittuivat lähetyksen aikana tai tarkistussumma on laskettu väärin lähettävällä puolella), niin päätöksen jatkotoimenpiteistä tekee vastaanottava puoli. Yleensä useimmissa nykyaikaisissa laitteissa, jotka toimivat UDP / IP-pakettien kanssa, on asetuksia, joiden avulla voit joko sivuuttaa tällaiset paketit tai ohittaa ne jatkokäsittelyä varten virheellisestä tarkistussummasta riippumatta.

Esimerkki tarkistussumman laskemisesta

Lasketaan esimerkiksi useiden 16-bittisten sanojen tarkistussumma: 0x398a, 0xf802, 0x14b2, 0xc281.

Tätä varten voit ensin lisätä luvut pareittain, pitäen niitä 16-bittisinä etumerkittöminä lukuina, minkä jälkeen vähennetään lisäkoodiksi lisäämällä tulokseen yksi, jos summauksen aikana tapahtui siirto korkeimpaan (17.) bittiin (toisin sanoen tällä operaatiolla muunnamme negatiivisen luvun komplementista käänteiskoodiksi ) . Tai vastaavasti voimme ajatella, että siirto lisätään luvun vähiten merkitsevään numeroon.

0x398a + 0xf802 = 0x1318c → 0x318d (korkean tilauksen siirto) 0x318d + 0x14b2 = 0x0463f → 0x463f (positiivinen luku) 0x463f + 0xc281 = 0x108c0 → 0x08c1

Lopussa kaikki saadun luvun bitit käännetään

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73etai muuten - 0xffff − 0x08c1 = 0xf73e. Tämä on haluttu tarkistussumma.

RFC 1071 [4] tarjoaa muita tapoja laskea tarkistussumma, erityisesti käyttämällä 32-bittistä aritmetiikkaa.

Pseudo-otsikot

Pseudo-otsikko IPv4:lle

Jos UDP on käynnissä IPv4:n yli, tarkistussumma lasketaan käyttämällä pseudootsaketta, joka sisältää tietoja IPv4-otsikosta. Pseudo-otsikko ei ole todellinen IPv4-otsikko, jota käytetään IP-paketin lähettämiseen. Taulukko sisältää pseudootsikon, jota käytetään vain tarkistussumman laskemiseen.

bittiä 0-7 8-15 16-23 24-31
0 Lähteen osoite
32 Vastaanottajan osoite
64 Nollat pöytäkirja UDP pituus
96 Lähdeportti Kohdeportti
128 Pituus Tarkista summa
160+
Data

Lähde- ja kohdeosoitteet otetaan IPv4-otsikosta. UDP:n Protokolla-kentän arvo on 17 (0x11). "UDP Length" -kenttä vastaa otsikon ja tietojen pituutta.

Tarkistussumman laskeminen IPv4:lle on valinnainen, jos sitä ei käytetä, arvo on 0.

Pseudo-otsikko IPv6:lle

Kun työskentelet UDP:n kanssa IPv6:n yli, tarkistussumma vaaditaan. Menetelmä sen laskemiseksi on julkaistu RFC 2460 :ssa :

Tarkistussummaa laskettaessa käytetään taas pseudootsikkoa, joka jäljittelee todellista IPv6-otsikkoa:

bittiä 0-7 8-15 16-23 24-31
0 Lähteen osoite
32
64
96
128 Vastaanottajan osoite
160
192
224
256 UDP pituus
288 Nollat Seuraava otsikko
320 Lähdeportti Kohdeportti
352 Pituus Tarkista summa
384+
Data

Lähdeosoite on sama kuin IPv6-otsikossa. Vastaanottajan osoite - lopullinen vastaanottaja; jos IPv6-paketti ei sisällä Routing-otsikkoa, tämä on IPv6-otsikon kohdeosoite, muuten aloitussolmussa tämä on reititysotsikon viimeisen elementin osoite ja kohdesolmussa, kohdeosoite IPv6-otsikosta. "Seuraava otsikko" -arvo on yhtä suuri kuin protokollan arvo - 17 UDP:lle. UDP Length – UDP-otsikon ja datan pituus.

Luotettavuus ja ruuhkaratkaisut

Toimivuuden puutteen vuoksi UDP-sovellusten on varauduttava joihinkin menetyksiin, virheisiin ja päällekkäisyyksiin. Jotkut niistä (esim. TFTP ) voivat tarvittaessa lisätä perusmekanismeja luotettavuuden varmistamiseksi sovellustasolla.

Mutta useammin UDP-sovellukset eivät käytä tällaisia ​​mekanismeja ja jopa häiritsevät niitä. Suoratoistomedia , reaaliaikaiset moninpelit ja VoIP ovat esimerkkejä sovelluksista, jotka käyttävät usein UDP-protokollaa. Näissä sovelluksissa pakettien häviäminen ei yleensä ole suuri ongelma. Jos sovellus tarvitsee korkeaa luotettavuutta, voit käyttää toista protokollaa (TCP) tai käyttää kohinaa korjaavia koodausmenetelmiä ( Erasure code ).

Vakavampi mahdollinen ongelma on, että toisin kuin TCP:ssä, UDP-pohjaisissa sovelluksissa ei välttämättä ole hyviä ruuhkanhallinta- ja välttämismekanismeja. Ruuhkaherkät UDP-sovellukset, jotka kuluttavat huomattavan määrän käytettävissä olevaa kaistanleveyttä, voivat vaarantaa Internetin vakauden.

Verkkomekanismit on suunniteltu minimoimaan ruuhkautumisen vaikutukset hallitsemattomiin, nopeisiin kuormiin. Verkkoelementit, kuten pakettijono- ja huuhtelutekniikoita käyttävät reitittimet, ovat usein ainoa käytettävissä oleva työkalu ylimääräisen UDP-liikenteen hidastamiseen. DCCP (Datagram Congestion Control Protocol) on suunniteltu osittaiseksi ratkaisuksi tähän mahdolliseen ongelmaan lisäämällä mekanismeja loppupäähän nopeiden UDP-virtojen, kuten suoratoistomedian, ruuhkautumisen seuraamiseksi.

Sovellukset

Useat keskeiset Internet-sovellukset käyttävät UDP:tä, mukaan lukien DNS (jossa kyselyiden on oltava nopeita ja koostuvat vain yhdestä kyselystä, jota seuraa yksi vastauspaketti), Simple Network Management Protocol ( SNMP ), Routing Information Protocol ( RIP ), dynaaminen isäntämääritys ( DHCP ) .

Ääni- ja videoliikenne välitetään yleensä UDP:tä käyttäen. Reaaliaikaiset videon ja äänen suoratoistoprotokollat ​​on suunniteltu käsittelemään satunnaisia ​​pakettien menetyksiä niin, että laatu heikkenee vain vähän pitkien viiveiden sijaan, kun kadonneet paketit lähetetään uudelleen. Koska sekä TCP että UDP toimivat samassa verkossa, monet yritykset ovat huomanneet, että näiden reaaliaikaisten sovellusten aiheuttama UDP-liikenteen viimeaikainen kasvu haittaa TCP-sovellusten, kuten tietokantajärjestelmien tai kirjanpidon , suorituskykyä . Koska sekä liiketoiminnalliset että reaaliaikaiset sovellukset ovat yrityksille tärkeitä, laadukkaiden ratkaisujen kehittäminen ongelmaan on joidenkin mielestä etusijalla.

UDP:n ja TCP:n vertailu

TCP  on yhteyssuuntautunut protokolla, mikä tarkoittaa, että "kättely" vaaditaan yhteyden muodostamiseen kahden isännän välille. Kun yhteys on muodostettu, käyttäjät voivat lähettää tietoja molempiin suuntiin.

UDP on yksinkertaisempi, yhteydetön, viestipohjainen protokolla. Tämäntyyppiset protokollat ​​eivät muodosta omistettua yhteyttä kahden isännän välille. Viestintä saavutetaan välittämällä tietoa yhteen suuntaan lähteestä määränpäähän tarkistamatta kohteen valmiutta tai tilaa. Voice over Internet Protocol (Voice over IP, TCP/IP) -sovelluksissa UDP:llä on etu TCP:hen verrattuna, jolloin mikä tahansa "kättely" häiritsee hyvää puheviestintää. VoIP:ssä oletetaan, että loppukäyttäjät antavat tarvittavan reaaliaikaisen kuittauksen, että viesti on vastaanotettu.

Linkkejä RFC:hen

Katso myös

Muistiinpanot

  1. ↑ https://tools.ietf.org/html/rfc768
  2. ↑ Valentin Plenk. Angewandte Netzwerktechnik kompakt: Dateiformate, Übertragungsprotokolle ja ihre Nutzung in Java-Aplikationen . — 1te Aufl. - Springer Vieweg, 2017. - S. 130. - XIV, 194 S. - (IT kompakt). — ISBN 978-3-658-15904-7 .
  3. ↑ Scott Hogg. Jumbo kehykset. Tukeeko verkkosi Jumbo Frame -kehyksiä ja pitäisikö se ottaa käyttöön? // Verkkomaailma : http://www.networkworld.com/article/2224722/cisco-subnet/jumbo-frames.html . – 3.6.2013.
  4. ↑ 1 2 R. Braden, D. Borman, C. Partridge. RFC 1071 - Internet-tarkistussumman laskenta (syyskuu 1988). Haettu 3. lokakuuta 2014. Arkistoitu alkuperäisestä 6. lokakuuta 2014.

Linkit