UDP

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 19. oktober 2018; verifikation kræver 21 redigeringer .
UDP
Navn Brugerdatagramprotokol
Niveau (ifølge OSI-modellen ) Transportere
Familie TCP/IP (nogle gange kaldet UDP/IP)
Oprettet i 1980 [1]
Port/ID 17 (i IP)
Specifikation RFC 768 / STD 6
Vigtigste implementeringer (klienter) Kerner Windows, Linux, UNIX
Kerneimplementeringer ( servere ) Kerner Windows, Linux, UNIX
Udvidelsesmuligheder Ingen
 Mediefiler på Wikimedia Commons

UDP (  User Datagram Protocol ) er et af nøgleelementerne i sættet af netværksprotokoller til internettet .  Med UDP kan computerapplikationer sende beskeder (i dette tilfælde kaldet datagrammer ) til andre værter over et IP-netværk uden behov for forudgående kommunikation for at oprette særlige transmissionskanaler eller datastier. Protokollen blev udviklet af David P. Reed i 1980 og formelt defineret i RFC 768 .

UDP bruger en simpel transmissionsmodel uden eksplicitte håndtryk for at sikre pålidelighed, rækkefølge eller dataintegritet. Datagrammer kan ankomme ude af drift, duplikeres eller helt forsvinde sporløst, men det er garanteret, at hvis de ankommer, så i en konsistent tilstand. UDP indebærer, at fejlkontrol og afhjælpning enten ikke er nødvendig eller skal udføres i applikationen. Tidsfølsomme applikationer bruger ofte UDP, da det er at foretrække at droppe pakker i stedet for at vente på forsinkede pakker, hvilket måske ikke er muligt i realtidssystemer . Hvis det er nødvendigt at rette fejl på netværksgrænsefladelaget, kan applikationen bruge TCP eller SCTP , som er designet til dette formål.

Naturen af ​​UDP som en statsløs protokol er også nyttig for servere, der reagerer på små anmodninger fra et stort antal klienter, såsom DNS og streaming medieapplikationer som IPTV , Voice over IP , IP- tunneling-protokoller og mange onlinespil .

Serviceporte

UDP-applikationer bruger datagram sockets til at etablere en forbindelse mellem værter. Et program binder en socket til dets dataendepunkt, som er en kombination af en IP-adresse og en serviceport. En port er en softwarestruktur, der identificeres af et portnummer, som er en 16- bit heltalsværdi (det vil sige 0 til 65535). Port 0 er reserveret, selvom det er en gyldig kildeportværdi i tilfælde af, at afsendelsesprocessen ikke venter på svarmeddelelser.

IANA har opdelt portnumre i tre grupper.

Pakkestruktur

UDP er en minimal meddelelsesorienteret transportlagsprotokol, der er dokumenteret i RFC 768 .

UDP giver ingen meddelelsesleveringsgarantier for upstream-protokollen og gemmer ikke tilstanden for sendte meddelelser. Af denne grund omtales UDP nogle gange som Unreliable Datagram Protocol.

UDP leverer multi-kanal transmission (via portnumre) og header og væsentlige dataintegritetstjek (via kontrolsummer ). Pålidelig transmission skal om nødvendigt implementeres af brugerapplikationen.

stykker 0 - 15 16 - 31
0-31 Kildeport Destinationshavn
32-63 Datagramlængde (længde) Kontrolsum
64-... Data

UDP-headeren består af fire felter, hver på 2 bytes (16 bit). To af dem er valgfri i IPv4 (lyserøde celler i tabellen), mens i IPv6 kun kildeporten er valgfri.

Senderport

Dette felt angiver afsenderens portnummer. Det antages, at denne værdi angiver den port, som svaret vil blive sendt til, hvis det er nødvendigt. Ellers skal værdien være 0. Hvis kildeværten er en klient, er portnummeret sandsynligvis dynamisk. Hvis kilden er en server, så vil dens port være en af ​​de "velkendte".

Destinationsport

Dette felt er obligatorisk og indeholder destinationsporten. I lighed med kildeporten, hvis destinationsværten er en klient, så er portnummeret dynamisk, hvis destinationen er en server, så vil det være en "velkendt" port.

Datagramlængde

Et felt, der angiver længden af ​​hele datagrammet (header og data) i bytes. Den mindste længde er lig med længden af ​​headeren - 8 bytes. Teoretisk set er den maksimale feltstørrelse 65535 bytes for et UDP-datagram (8 bytes for header og 65527 for data). Den faktiske datalængdegrænse ved brug af IPv4 er 65507 (ud over 8 bytes pr. UDP-header kræves der yderligere 20 bytes pr. IP-header).

I praksis skal det også tages i betragtning, at hvis længden af ​​en IPv4-pakke med UDP overstiger MTU (for Ethernet er standarden 1500 bytes), så kan afsendelse af en sådan pakke forårsage dens fragmentering, hvilket kan føre til, at at det slet ikke kan leveres, hvis mellemroutere eller slutvært ikke vil understøtte fragmenterede IP-pakker. RFC 791 angiver også en minimum IP-pakkelængde på 576 bytes, som alle IPv4-deltagere skal understøtte, og det anbefales kun at sende større IP-pakker, hvis du er sikker på, at den modtagende part kan acceptere pakker af denne størrelse. For at undgå fragmentering af UDP-pakker (og deres eventuelle tab), bør datastørrelsen i UDP derfor ikke overstige: MTU - (Max IP Header Size) - (UDP Header Size) = 1500 - 60 - 8 = 1432 bytes. For at være sikker på, at pakken vil blive modtaget af enhver vært, bør datastørrelsen i UDP ikke overstige: (minimum IP-pakkelængde) - (Max IP Header Size) - (UDP Header Size) = 576 - 60 - 8 = 508 bytes [2] .

I IPv6-jumbogrammer kan UDP-pakker være større. Den maksimale værdi er 4.294.967.295 bytes (232 -  1), hvoraf 8 bytes er header og de resterende 4.294.967.287 bytes er data.

Det skal bemærkes, at de fleste moderne netværksenheder sender og modtager IPv4-pakker på op til 10.000 bytes lange uden at adskille dem i individuelle pakker. Uformelt kaldes sådanne pakker "Jumbo-pakker", selvom konceptet Jumbo officielt refererer til IPv6. Det er dog ikke alle enheder, der understøtter Jumbo-pakker, og før man organiserer kommunikation ved hjælp af UDP/IP IPv4-pakker med en længde på over 1500 bytes, er det nødvendigt at kontrollere muligheden for sådan kommunikation empirisk på specifikt udstyr [3] .

Kontrolsum

Kontrolsum-feltet bruges til at kontrollere overskriften og data for fejl. Hvis beløbet ikke genereres af senderen, er feltet udfyldt med nuller. Feltet er valgfrit for IPv4.

Kontrolsum beregning

Metoden til beregning af kontrolsummen er defineret i RFC 1071 [4] .

Før beregning af kontrolsummen, hvis længden af ​​UDP-meddelelsen i bytes er ulige, så udfyldes UDP-meddelelsen med en nul-byte i slutningen (pseudo-headeren og den ekstra nul-byte sendes ikke med beskeden, de bruges kun ved beregning af kontrolsummen). Kontrolsumfeltet i UDP-headeren antages at være nul under kontrolsumberegningen.

For at beregne kontrolsummen opdeles pseudo-headeren og UDP-meddelelsen i to-byte-ord. Derefter beregnes summen af ​​alle ord i aritmetikken af ​​den omvendte kode (det vil sige koden, hvor et negativt tal opnås fra et positivt tal ved at invertere alle bits af tallet, og der er to nuller: 0x0000 (angivet med + 0) og 0xffff(angivet med -0)). Resultatet skrives til det tilsvarende felt i UDP-headeren.

Checksumværdien lig med 0x0000 (+0 i returkoden ) er reserveret og betyder, at checksummen ikke blev beregnet for afsendelsen. Hvis kontrolsummen blev beregnet og viste sig at være lig med 0x0000, så indtastes værdien 0xffff(-0 i omvendt kode ) i kontrolsumfeltet.

Ved modtagelse af beskeden beregner modtageren checksummen igen (allerede under hensyntagen til checksum-feltet), og hvis resultatet er -0 (det vil sige 0xffff), så anses checksummen for at være konvergeret. Hvis summen ikke konvergerer (dataene blev beskadiget under transmissionen, eller kontrolsummen blev forkert beregnet på den transmitterende side), så træffes beslutningen om yderligere handlinger af den modtagende side. Som regel er der i de fleste moderne enheder, der arbejder med UDP / IP-pakker, indstillinger, der giver dig mulighed for enten at ignorere sådanne pakker eller springe dem over til videre behandling, uanset den forkerte kontrolsum.

Kontrolsum beregningseksempel

Lad os f.eks. beregne kontrolsummen af ​​flere 16-bit ord: 0x398a, 0xf802, 0x14b2, 0xc281.

For at gøre dette kan du først tilføje tallene parvis og betragte dem som 16-bit usignerede tal, efterfulgt af reduktion til en ekstra kode ved at tilføje en til resultatet, hvis der under addition var en overførsel til den højeste (17.) bit (det vil sige, de facto, ved denne operation konverterer vi et negativt tal fra komplement til invers kode ). Eller på samme måde kan vi overveje, at bæringen lægges til det mindst betydende ciffer i tallet.

0x398a + 0xf802 = 0x1318c → 0x318d (high order carry) 0x318d + 0x14b2 = 0x0463f → 0x463f (positivt tal) 0x463f + 0xc281 = 0x108c0 → 0x08c1

Til sidst inverteres alle bits af det resulterende tal

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73eeller på anden måde - 0xffff − 0x08c1 = 0xf73e. Dette er den ønskede kontrolsum.

RFC 1071 [4] giver andre måder at beregne kontrolsummen på, især ved hjælp af 32-bit aritmetik.

Pseudo-titler

Pseudo-header til IPv4

Hvis UDP kører over IPv4, beregnes kontrolsummen ved hjælp af en pseudo-header, der indeholder nogle oplysninger fra IPv4-headeren. Pseudo-headeren er ikke en rigtig IPv4-header, der bruges til at sende en IP-pakke. Tabellen indeholder en pseudo-header, der kun bruges til kontrolsumberegning.

stykker 0 - 7 8 - 15 16 - 23 24 - 31
0 Kildeadresse
32 Adresse på modtageren
64 Nuller Protokol UDP-længde
96 Kildeport Destinationshavn
128 Længde Tjek sum
160+
Data

Kilde- og destinationsadresserne er taget fra IPv4-headeren. Værdien af ​​feltet Protocol for UDP er 17 (0x11). Feltet "UDP Length" svarer til længden af ​​overskriften og dataene.

Beregningen af ​​kontrolsummen for IPv4 er valgfri, hvis den ikke bruges, er værdien 0.

Pseudo-header til IPv6

Når du arbejder med UDP over IPv6, er kontrolsummen påkrævet. En metode til at beregne det er blevet offentliggjort i RFC 2460 :

Når kontrolsummen beregnes, bruges en pseudo-header igen, der efterligner en ægte IPv6-header:

stykker 0 - 7 8 - 15 16 - 23 24 - 31
0 Kildeadresse
32
64
96
128 Adresse på modtageren
160
192
224
256 UDP-længde
288 Nuller Næste titel
320 Kildeport Destinationshavn
352 Længde Tjek sum
384+
Data

Kildeadressen er den samme som i IPv6-headeren. Modtageradresse - endelig modtager; hvis IPv6-pakken ikke indeholder Routing-headeren, vil dette være destinationsadressen fra IPv6-headeren, ellers vil dette på startnoden være adressen på det sidste element i routing-headeren og på destinationsknuden, destinationsadressen fra IPv6-headeren. Værdien "Næste overskrift" er lig med protokolværdien - 17 for UDP. UDP Length - Længden af ​​UDP-headeren og data.

Pålidelighed og overbelastningsløsninger

På grund af manglen på robusthed skal UDP-applikationer være forberedt på nogle tab, fejl og duplikering. Nogle af dem (for eksempel TFTP ) kan tilføje elementære mekanismer til at sikre pålidelighed på applikationslaget, hvis det er nødvendigt.

Men oftere bruges sådanne mekanismer ikke af UDP-applikationer og forstyrrer endda dem. Streamingmedier , multiplayer-spil i realtid og VoIP er eksempler på applikationer, der ofte bruger UDP-protokollen. I disse særlige applikationer er pakketab normalt ikke et stort problem. Hvis applikationen har brug for et højt niveau af pålidelighed, så kan du bruge en anden protokol (TCP) eller bruge støjkorrigerende kodningsmetoder ( Erasure code ).

Et mere alvorligt potentielt problem er, at UDP-baserede applikationer, i modsætning til TCP, ikke nødvendigvis har en god overbelastningskontrol og -undgåelsesmekanismer. Overbelastningsfølsomme UDP-applikationer, der bruger en betydelig mængde tilgængelig båndbredde, kan kompromittere internetstabiliteten.

Netværksmekanismer blev designet til at minimere virkningerne af overbelastning på ukontrollerede højhastighedsbelastninger. Netværkselementer såsom routere, der bruger pakkekø- og skylleteknikker, er ofte det eneste tilgængelige værktøj til at bremse overskydende UDP-trafik. DCCP (Datagram Congestion Control Protocol) er designet som en delvis løsning på dette potentielle problem ved at tilføje mekanismer til slutværten for at spore overbelastning for højhastigheds UDP-streams som streaming media.

Ansøgninger

Adskillige vigtige internetapplikationer bruger UDP, inklusive DNS (hvor forespørgsler skal være hurtige og kun bestå af én forespørgsel efterfulgt af en enkelt svarpakke), Simple Network Management Protocol ( SNMP ), Routing Information Protocol ( RIP ), dynamisk værtskonfiguration ( DHCP ) .

Tale- og videotrafik transmitteres normalt ved hjælp af UDP. Video- og lydstreamingprotokoller i realtid er designet til at håndtere tilfældigt pakketab, så kvaliteten kun forringes marginalt i stedet for lange forsinkelser, når de tabte pakker gentransmitteres. Fordi både TCP og UDP opererer på det samme netværk, har mange virksomheder bemærket, at den seneste stigning i UDP-trafik på grund af disse realtidsapplikationer hindrer ydeevnen af ​​TCP-applikationer som databasesystemer eller regnskaber . Fordi både forretnings- og realtidsapplikationer er vigtige for virksomheder, er udvikling af kvalitetsløsninger til et problem af nogle set som en topprioritet.

Sammenligning af UDP og TCP

TCP  er en forbindelsesorienteret protokol, hvilket betyder, at der kræves et "håndtryk" for at etablere en forbindelse mellem to værter. Når en forbindelse er etableret, kan brugere sende data i begge retninger.

UDP er en enklere, forbindelsesløs, beskedbaseret protokol. Disse typer protokoller etablerer ikke en dedikeret forbindelse mellem to værter. Kommunikation opnås ved at videregive information i én retning fra kilde til destination uden at kontrollere destinationens beredskab eller tilstand. I Voice over Internet Protocol (Voice over IP, TCP/IP) applikationer har UDP en fordel frem for TCP, hvor ethvert "håndtryk" ville forstyrre god stemmekommunikation. I VoIP antages det, at slutbrugere vil give enhver nødvendig realtidsbekræftelse af, at en besked er modtaget.

Links til RFC'er

Se også

Noter

  1. ↑ https://tools.ietf.org/html/rfc768
  2. ↑ Valentin Plenk. Angewandte Netzwerktechnik kompakt: Filformat, Übertragungsprotokolle og ihre Nutzung i Java-Applikationen . — 1te Aufl. - Springer Vieweg, 2017. - S. 130. - XIV, 194 S. - (IT kompakt). — ISBN 978-3-658-15904-7 .
  3. ↑ Scott Hogg. Jumbo rammer. Understøtter dit netværk Jumbo Frames, og bør du aktivere det? // Network World: http://www.networkworld.com/article/2224722/cisco-subnet/jumbo-frames.html . — 3. juni 2013.
  4. ↑ 1 2 R. Braden, D. Borman, C. Agerhøne. RFC 1071 - Internet Checksum Calculation (september 1988). Hentet 3. oktober 2014. Arkiveret fra originalen 6. oktober 2014.

Links