User Datagram Protocol

User Datagram Protocol (UDP) protokoloa Internet sarean erabiltzen diren protokoloen artean beharrezkoetako bat da. UDP-rekin, ordenagailuen aplikazioek mezuak bidali ditzakete, kasu honetan datagramak deituak direnak, beste zerbitzari batzuetara Internet Protokoloa (Internet Protocol, IP) erabiliz, aurretik komunikaziorik behar izan gabe (ez da konexio bidezkoa, IP bezala), hau da, komunikazio erraza eta arina da. Protokoloa David P. Reed-ek diseinatu zuen 1980an eta [1]-an dago zehazki definitua.

UDP-k transmisiorako eredu sinple bat erabiltzen du, protokolo mekanismo minimoak baliatuz. Ez dauka handshaking elkarrizketarik eta, hortaz, azpiko sare protokoloaren edozein akats argitara ateratzen du erabiltzailearen programan. Kasu gehienetan IP protokoloa denez, ez dago entrega, orden edo errepikapenak ekidingo diren ziurtasunik. UDP protokoloak checksum izeneko hash funtzio bat darama datagramaren osotasuna bermatzeko, baita portu zenbakiak ere, jatorri eta helburuko helbideak jasotzeko.

UDP egokia da erroreen zainketa eta zuzenketa beharrezkoa ez denerako edo aplikazioan egiten ez direnerako, horrela sare interfaze mailako goiburukoaren prozesamendua ekidinez. Abiadura azkarra behar duten aplikazioek maiz erabiltzen dute UDP, komenigarriagoa delako paketeak galtzea atzeratutakoei itxarotea baino. [2] Erroreen zuzenketa beharrezkoa bada sare interfaze mailan, aplikazioak Transmission Control Protocol (TCP) edo Stream Control Transmission Protocol (SCTP) erabiliko du ziurrenik, zeinak helburu horretarako diseinatuak dauden hain zuzen ere.

Protokolo honen zenbait ezaugarrik aplikazio jakin batzuetarako egokia izatea eragiten dute:

  • Transakzio-orientatua da, eskaera-erantzun sinpleak erabiltzen dituzten protokoloentzako egokia, adibidez, Domain Name System edo Network Time Protocol.
  • Datagramak dauzka, beste protokolo batzuk modelatzeko egokia, IP tuneletan edo Remote Procedure Call eta Network File System-en bezala.
  • Sinplea da, abiatzea edo beste helburu batzuetarako egokia protokolo pilaketa guztia gabe, esaterako, DHCP eta Trivial File Transfer Protocol.
  • Stateless motakoa da, bezero kopuru handiarentzako egokia, media streaming-a egiten duten aplikazioentzat, esate baterako, IPTV.
  • Birbidalketen atzerapenik ez duenez, denbora errealeko aplikazioentzat egokia da, Voice over IP edo online jokuentzako adibidez, baita Real Time Streaming Protocol-ekin eraikitako zenbait protokolotan ere
  • Norabide bakarreko komunikazioetan ondo funtzionatzen du, informazio broadcast egiteko service discovery mota askotan bezala edo banatutako informazioarentzako Routing Information Protocol-en bezala.

Zerbitzu-portuak

Aplikazioek datagrama socketak erabiltzen dituzte zerbitzarien arteko komunikazioak ezartzeko. Aplikazioak socket bat lotzen du bere data garraioaren bukaeran, zeina IP helbidearen eta portuaren arteko konbinazio bat den. Portu bat software estruktura bat da, portu zenbaki batekin definitzen dena, 16 biteko osoko balio bat (hortaz, portu zenbakiak 0 eta 65535 balioen artean egon daitezke). 0 portua erreserbatuta da, baina onartuta dago jatorrizko portu bezala erabiltzea erantzunik espero ez denean.



Internet Assigned Numbers Authority-k 3 tartetan banatu ditu portu zenbakiak. [3] 0-1023 tarteko zenbakiak well-known zerbitzuetarako erreserbatuta daude. Unix motako sistema eragileetan, portu hauetako bat erabiltzeko supererabiltzaile edo administratzaile baimena behar da. 1024-49151 tarteko portu zenbakiak erregistratutako portu zenbakiak dira, IANA-erregistratutako zerbitzuetarako erabiliak. Gainerako portuak (49512-65535) dinamikoak dira eta ez daude ofizialki zerbitzu jakin batentzat gordeak; edozein helburutarako erabil daitezke. Behin behineko portu gisa ere erabiltzen dira, automatikoki hautatuak. Batez ere bezero eta zerbitzarien arteko komunikazioan erabiltzen dira denbora tarte batez.

Pakete estruktura

UDP garraio mailako protokolo bat da, ahalik eta mezu gutxien bidaltzea lortzeko helburuz. IETF RFC 786-an dago dokumentatuta.

UDP-k ez dio bermatzen maila bat altuagoko protokoloari mezuen entrega egingo denik eta mailan bertan ez da mezuaren egoera gordetzen behin hau bidali denean. Hori dela eta, batzuetan UDP-ri Unreliable Datagram Protocol (fidagaitza) deitzen zaio. [4]

Protokoloak aplikazioen multiplexazioa (portu zenbakien bitartez) eskaintzen du, baita goiburukoaren osotasunaren egiaztatzea (checksum bidez) ere. Garraioan fidagarritasuna nahi bada, erabiltzailearen aplikazioan inplementatu behar da. [5] If transmission reliability is desired, it must be implemented in the user's application.

UDP Goiburukoa
' Zortziko 0 1 2 3
Zortziko Bit 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0 0 Jatorrizko portuaHelburu portua
4 32 LuzeraChecksum-a

UDP goiburukoak 4 eremu dauzka, bakoitza 2 bytekoa (16 bit). [2] Checksum eta jatorrizko portuen eremuak hautazkoak dira IPv4ean (arrosaz). IPv6an, jatorrizko portua da hautazko bakarra.

Jatorrizko portuaren zenbakia
Igorlearen portua identifikatzen du garrantzitsua denean eta hona erantzun behar dela suposatzen da, behar denean. Ez bada erabiltzen, zero izan behar luke. Jatorrizkoa bezeroa bada, gehienetan behin-behineko portu zenbaki bat izango da. Aldiz, zerbitzaria bada, orokorrean well-known portu zenbaki bat izango da. [3]
Helburuko portuaren zenbakia
Hartzailearen portuaren identifikazioa da eta nahitaezkoa da. Jatorrizkoaren antzera, hartzailea bezeroa bada, portua behin-behinekoa izanen da; bestalde, zerbitzaria bada, well-known portua.[3]
Luzera
Eremu honetan datagrama osoaren luzera zehazten da bytetan: goiburukoa eta informazioa. Gutxienezko luzera 8 byte da, goiburukoaren luzera hau denez gero. Muga teorikoa 65 535 byte da (goiburukoaren 8 byte eta informazioaren 65 527 byte). Berriz, muga praktikoa IPv4an 65 507 da (65 535 – goiburukoaren 8 byte – IP goiburukoaren 8 byte). [3]
IPv6an posible da 65 535 byte baino handiagoko paketeak izatea. Hortaz, gehienezko luzeraren balioa 2^32-1da (goiburukoaren 8 byte eta informazioaren 4 294 967 287 byte).
Checksum
Goiburukoaren eta informazioaren erroreen zainketa egiteko da. Igorleak ez badu checksum sortzen, defektuz zeroz osatutako balioa hartuko du. [6] IPv6an ez da aukerazko eremua. [7]

Checksum kalkulatzea

Checksum-a kalkulatzeko erabiltzen den metodoa RFC 768-an definitua dago:

16 bitez osatutako hitz guztiak bateko konplementuaren aritmetika (one’s complement arithmetic) erabiliz batzen dira. Jarraian, batura honi berriro bateko konplementuaren aritmetika aplikatzen zaio, UDP-ren checksum eremuko balioa lortuz.[8]

Checksum balioa zero bada (16 bitak 0), bateko konplementu gisa bidali behar da, hots, 1 balioko 16 bit.

IPv4 eta IPv6 arteko desberdintasuna checksum-a kalkulatzeko erabilitzako informazioan datza.

Pseudo Goiburukoak

IPv4 Pseudo Goiburukoa

Checksum-a kalkulatzeko “pseudo-goiburuko”[9] bat erabiltzen da, IPv4-ren benetako goiburukoak duen informazio zati bat gordetzen duena. Pseudo-goiburukoa ez da IP paketeak bidaltzeko erabiltzen den benetako goiburukoa, checksum-a kalkulatzeko bakarrik erabiltzen da.

bitak 0 – 7 8 – 15 16 – 23 24 – 31
0 Jatorriko helbidea
32 Helburuko helbidea
64 Zeroak Protokoloa UDP luzera
96 Jatorriko portua Helburuko portua
128 Luzera Checksum
160+  
Data
 

Jatorriko eta helburuko helbideak IPv4 goiburuko berdinak dira. UDP luzera eremuko balioa UDP goiburukoaren eta informazioaren luzera da.

IPv4an, UDP checksum-a egitea hautazkoa da.

IPv6 Pseudo Goiburukoa

Kasu honetan, checksum-a nahitaezkoa da. Aldaketa egiteko metodoa RFC 2460 arauan zehaztuta dago:

Checksum-aren kalkuluan IP goiburukoko helbidea sartuta badago, aldatu egin behar da 128-biteko IPv6 helbideak sartzeko.[7]

Checksum-a kalkulatzerakoan, berriro ere pseudo-goiburuko bat erabiltzen da, benetako IPv6 goiburukoaren berdina.

Zortziko 0 1 2 3
Zortziko Bitak 0 – 7 8 – 15 16 – 23 24 – 31
0 0 Jatorriko helbidea
4 32
8 64
12 96
16 128 Helburuko helbidea
20 160
24 192
28 224
32 256 UDP luzera
36 288 Zeroak Hurrengo goiburukoa
40 320 Jatorriko portua Helburuko portua
44 352 Luzera Checksuma
48+ 384+  
Data
 

Jatorriko helbidea, IPv6ko goiburuko berdina da. Helburuko helbidea helmuga da.

Fidagarritasuna eta kongestio kontrolaren soluzioak

Fidagarritasun falta dela eta, UDP aplikazioak datu batzuen galera, erroreak eta errepikapenak onartu behar dituzte. Aplikazio batzuk, adibidez, TFTP-k, fidagarritasuna lortzeko mekanismo gehigarri batzuk gehitzen dituzte aplikazio mailan, beharren arabera. [3]

Media streaming-a, denbora errealeko jokalari ugariko jokoak eta voice over IP (VoIP) aplikazioek UDP erabiltzen dute gehienetan. Aplikazio hauetan zehazki, paketeen galera ez da arazo larria. Aplikazio batek fidagarritasun maila altua eskatzen badu, UDP protokoloa orde TCP erabili ohi da.

Potentzialki larriago, TCP-k ez bezala, UDP erabiltzen duten aplikazioek ez daukate kongestioa ekiditeko eta kontrolerako mekanismorik. Atzigarri dagoen banda zabaleraren zati handi bat erabiltzen duten UDP aplikazioek interneten egonkortasuna arriskuan jar dezakete. Sarean oinarritutako mekanismoak proposatu dira arazo hau ekiditeko. Adibidez, maiz, routerrak dira erreminta bakarra UDP trafikoa mantsotzeko, paketeak ilaran jarriz. Datagram Congestion Control Protocol (DCCP) arazo hau ekiditeko ari dira diseinatzen.

Aplikazioak

Interneten hainbat aplikaziok erabiltzen dute UDP, esaterako, Domain Name System (DNS), non eskaerak azkarrak diren eta eskaera eta erantzuna emateko pakete bakar bana behar den; Simple Network Management Protocol (SNMP); Routing Information Protocol (RIP) eta Dynamic Host Configuration Protocol (DHCP).

Ahotsa eta bideoa orokorrean UDP bidez garraiatzen dira. Denbora errealeko bideo eta soinuarentzako streaming protokoloak pakete batzuek galerari aurre egiteko diseinatzen dira, hortaz, degradazio txiki bat bakarrik gertatzen da galdutako paketeen zain atzerapen handiak jasan ordez.

TCP eda UDP alderatzen

Transmission Control Protocol konexio bidezko protokolo bat da, hots, handshaking-a beharrezkoa du komunikazio bat martxan jartzeko. Behin konexioa ezarri denean, informazioa bi norabidetan bidal daiteke.

  • Fidagarria. TCP-k mezuen entrega baieztapena, birbidalketak eta denbora kontrolatzen ditu. Saiakera bat baino gehiago egiten dira mezu bat entregatzeko. Bidean galtzen bada, zerbitzariak berriro eskatuko du galdutako zatia. TCP-n, ez dago galdutako daturik. Bidalketa denboraz gehiegitan gainditzen bada, konexioa bertan behera uzten da.
  • Ordena. Bi mezu konexio batean sekuentzialki bidaltzen badira, lehenengo mezua iritsiko da aurreneko zerbitzarira. Segmentuak orden okerrean iristen badira, TCP bufferrak informazio guztia zuzen ordenatu arte itxaroten dute eta ondoren pasako dio aplikazioari.
  • Pisutsua. TCP-k 3 pakete beharrezkoak ditu konexioa ezartzeko erabiltzaile batek informazioa bidali aurretik. Fidagarritasuna eta kongestio kontrola kudeatzen ditu.
  • Streaming. Data byte-ka irakurtzen da.
TCPren analogia

UDP sinpleagoa da. Ez du konexiorik behar, hots, ez du konexioa ezarri beharrik. Komunikazioa jatorri batetik helburu batera norabide bakarrean informazioa garraiatuz lortzen da, prest dagoen ala ez egiaztatu gabe.

  • Fidagaitza. Mezu bat bidaltzen denean, ezin da jakin bere helmugara iritsi den edo ez; bidean galdu liteke. Ez dago entrega baieztapenik, birbidalketarik edo denboragailurik.
  • Ez ordenatua. Bi mezu hartzaile berari bidaltzen bazaizkio, ez dakigu zein ordenatan iritsiko diren.
  • Arina. Ez dira mezuak ordenatzen, ez da konexioa ezartzen...
  • Datagramak. Paketeak banaka bidaltzen dira eta, iristen badira, osotasuna egiaztatzen da.
  • Kongestio kontrolik ez. UDP-k berak ez du kongestioa ekiditen eta posible da banda zabaleraren zati handi bat erabiltzen duten aplikazioek sarea kongestionatzea, kongestio kontrola ez bada aplikazio mailan bertan egiten, behintzat.



Erreferentziak

Ikus, gainera

RFC erreferentziak

  • RFC 768 – User Datagram Protocol
  • RFC 2460 – Internet Protocol, Version 6 (IPv6) Specification
  • RFC 2675 - IPv6 Jumbograms
  • RFC 4113 – Management Information Base for the UDP
  • RFC 5405 – Unicast UDP Usage Guidelines for Application Designers

Kanpo estekak

  1. RFC 768 p1
  2. ISBN 978-0-13-136548-3..
  3. Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  4. .
  5. Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
  6. .
  7. .
  8. RFC 768, p2
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.