| UDP | |
|---|---|
| namn | användardatagram protokoll |
| Nivå (enligt OSI-modellen ) | Transport |
| Familj | TCP/IP (kallas ibland UDP/IP) |
| Skapad i | 1980 [1] |
| Port/ID | 17 (i IP) |
| Specifikation | RFC 768 / STD 6 |
| Huvudsakliga implementeringar (klienter) | Kärnor Windows, Linux, UNIX |
| Kärnimplementationer ( servrar ) | Kärnor Windows, Linux, UNIX |
| Expanderbarhet | Nej |
| Mediafiler på Wikimedia Commons | |
UDP ( User Datagram Protocol ) är ett av nyckelelementen i uppsättningen nätverksprotokoll för Internet . Med UDP kan datorapplikationer skicka meddelanden (i det här fallet kallade datagram ) till andra värdar över ett IP-nätverk utan behov av föregående kommunikation för att skapa speciella överföringskanaler eller datavägar. Protokollet utvecklades av David P. Reed 1980 och definierades formellt i RFC 768 .
UDP använder en enkel överföringsmodell, utan explicita handslag, för att säkerställa tillförlitlighet, ordning och dataintegritet. Datagram kan komma ur funktion, dupliceras eller helt försvinna spårlöst, men det är garanterat att om de kommer fram i ett konsekvent tillstånd. UDP innebär att felkontroll och åtgärdande antingen inte behövs eller måste utföras i applikationen. Tidskänsliga applikationer använder ofta UDP, eftersom det är att föredra att släppa paket istället för att vänta på försenade paket, vilket kanske inte är möjligt i realtidssystem . Om det är nödvändigt att korrigera fel i nätverksgränssnittsskiktet kan applikationen använda TCP eller SCTP , som är designade för detta ändamål.
Naturen hos UDP som ett tillståndslöst protokoll är också användbart för servrar som svarar på små förfrågningar från ett stort antal klienter, såsom DNS och strömmande mediaapplikationer som IPTV , Voice over IP , IP- tunnlingsprotokoll och många onlinespel .
UDP-applikationer använder datagramsockets för att upprätta en anslutning mellan värdar. En applikation binder en socket till dess dataändpunkt, vilket är en kombination av en IP-adress och en serviceport. En port är en mjukvarustruktur som identifieras av ett portnummer, vilket är ett 16 -bitars heltalsvärde (det vill säga 0 till 65535). Port 0 är reserverad, även om det är ett giltigt källportvärde om sändningsprocessen inte väntar på svarsmeddelanden.
IANA har delat in portnummer i tre grupper.
UDP är ett minimalt meddelandeorienterat transportlagerprotokoll dokumenterat i RFC 768 .
UDP ger inga garantier för meddelandeleverans för uppströmsprotokollet och lagrar inte statusen för skickade meddelanden. Av denna anledning hänvisas ibland UDP till som Unreliable Datagram Protocol.
UDP tillhandahåller flerkanalsöverföring (via portnummer) och huvudkontroller och viktiga dataintegritetskontroller (via kontrollsummor ). Tillförlitlig överföring, om nödvändigt, måste implementeras av användarapplikationen.
| bitar | 0 - 15 | 16 - 31 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0-31 | Källport | Destinationshamn | ||||||||||||||||||||||||||||||
| 32-63 | Datagramlängd (längd) | Kontrollsumma | ||||||||||||||||||||||||||||||
| 64-... | Data | |||||||||||||||||||||||||||||||
UDP-huvudet består av fyra fält, vart och ett på 2 byte (16 bitar). Två av dem är valfria i IPv4 (rosa celler i tabellen), medan i IPv6 endast källporten är valfri.
Detta fält anger avsändarens portnummer. Det antas att detta värde anger porten till vilken svaret kommer att skickas vid behov. Annars bör värdet vara 0. Om källvärden är en klient är portnumret troligen dynamiskt. Om källan är en server kommer dess port att vara en av de "välkända".
Detta fält är obligatoriskt och innehåller destinationsporten. I likhet med källporten, om destinationsvärden är en klient, är portnumret dynamiskt, om destinationen är en server kommer det att vara en "välkänd" port.
Ett fält som anger längden på hela datagrammet (huvud och data) i byte. Minsta längd är lika med längden på rubriken - 8 byte. Teoretiskt sett är den maximala fältstorleken 65535 byte för ett UDP-datagram (8 byte för rubrik och 65527 för data). Den faktiska datalängden vid användning av IPv4 är 65507 (utöver 8 byte per UDP-huvud krävs ytterligare 20 byte per IP-huvud).
I praktiken bör det också beaktas att om längden på ett IPv4-paket med UDP överskrider MTU (för Ethernet är standardvärdet 1500 byte), då kan sändning av ett sådant paket orsaka fragmentering, vilket kan leda till att att den inte kan levereras alls om mellanroutrar eller slutvärd inte kommer att stödja fragmenterade IP-paket. RFC 791 anger också en minsta IP-paketlängd på 576 byte som alla IPv4-deltagare måste stödja, och det rekommenderas att skicka större IP-paket endast om du är säker på att den mottagande parten kan acceptera paket av denna storlek. Därför, för att undvika fragmentering av UDP-paket (och deras eventuella förlust), bör datastorleken i UDP inte överstiga: MTU - (Max IP Header Size) - (UDP Header Size) = 1500 - 60 - 8 = 1432 byte. För att vara säker på att paketet kommer att tas emot av vilken värd som helst, bör datastorleken i UDP inte överstiga: (minsta IP-paketlängd) - (Max IP Header Size) - (UDP Header Size) = 576 - 60 - 8 = 508 byte [2] .
I IPv6-jumbogram kan UDP-paket vara större. Det maximala värdet är 4 294 967 295 byte (232 - 1), varav 8 byte är header och de återstående 4 294 967 287 byte är data.
Det bör noteras att de flesta moderna nätverksenheter skickar och tar emot IPv4-paket upp till 10 000 byte långa utan att separera dem i individuella paket. Informellt kallas sådana paket "Jumbo-paket", även om konceptet Jumbo officiellt hänvisar till IPv6. Alla enheter stöder dock inte Jumbo-paket, och innan du organiserar kommunikation med UDP/IP IPv4-paket med en längd som överstiger 1500 byte, är det nödvändigt att kontrollera möjligheten till sådan kommunikation empiriskt på specifik utrustning [3] .
Kontrollsummafältet används för att kontrollera rubriken och data för fel. Om mängden inte genereras av sändaren, fylls fältet med nollor. Fältet är valfritt för IPv4.
Metoden för att beräkna kontrollsumman definieras i RFC 1071 [4] .
Innan kontrollsumman beräknas, om längden på UDP-meddelandet i byte är udda, så fylls UDP-meddelandet med en nollbyte i slutet (pseudohuvudet och den extra nollbyten skickas inte med meddelandet, de används endast vid beräkning av kontrollsumman). Kontrollsummafältet i UDP-huvudet antas vara noll under kontrollsummaberäkningen.
För att beräkna kontrollsumman delas pseudohuvudet och UDP-meddelandet i två-byte-ord. Sedan beräknas summan av alla ord i aritmetiken för den inversa koden (det vill säga koden där ett negativt tal erhålls från ett positivt tal genom att invertera alla bitar av talet och det finns två nollor: 0x0000 (betecknas med + 0) och 0xffff(betecknas med −0)). Resultatet skrivs till motsvarande fält i UDP-huvudet.
Kontrollsummans värde lika med 0x0000 (+0 i returkoden ) är reserverat och betyder att kontrollsumman inte beräknades för sändningen. Om kontrollsumman beräknades och visade sig vara lika med 0x0000, så anges värdet 0xffff(-0 i den omvända koden ) i kontrollsummans fält.
Vid mottagandet av meddelandet beräknar mottagaren kontrollsumman igen (redan med hänsyn till kontrollsummafältet), och om resultatet är -0 (det vill säga 0xffff), anses kontrollsumman ha konvergerat. Om summan inte konvergerar (data skadades under överföringen, eller kontrollsumman beräknades felaktigt på den sändande sidan), fattas beslutet om ytterligare åtgärder av den mottagande sidan. Som regel, i de flesta moderna enheter som fungerar med UDP / IP-paket, finns det inställningar som låter dig antingen ignorera sådana paket eller hoppa över dem för vidare bearbetning, oavsett den felaktiga kontrollsumman.
Låt oss till exempel beräkna kontrollsumman för flera 16-bitars ord: 0x398a, 0xf802, 0x14b2, 0xc281.
För att göra detta kan du först lägga till siffrorna i par, betrakta dem som 16-bitars osignerade nummer, följt av reduktion till en ytterligare kod genom att lägga till en till resultatet, om det under additionen skedde en överföring till den högsta (17:e) biten (det vill säga, de facto, genom denna operation konverterar vi ett negativt tal från komplement till invers kod ). Eller på motsvarande sätt kan vi anse att överföringen läggs till den minst signifikanta siffran i numret.
0x398a + 0xf802 = 0x1318c → 0x318d (high order carry) 0x318d + 0x14b2 = 0x0463f → 0x463f (positivt tal) 0x463f + 0xc281 = 0x108c0 → 0x08c1I slutet inverteras alla bitar av det resulterande talet
0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73eeller på annat sätt - 0xffff − 0x08c1 = 0xf73e. Detta är den önskade kontrollsumman.
RFC 1071 [4] tillhandahåller andra sätt att beräkna kontrollsumman, särskilt med hjälp av 32-bitars aritmetik.
Om UDP körs över IPv4, beräknas kontrollsumman med hjälp av en pseudohuvud som innehåller information från IPv4-huvudet. Pseudohuvudet är inte ett riktigt IPv4-huvud som används för att skicka ett IP-paket. Tabellen innehåller en pseudo-header som endast används för kontrollsummaberäkning.
| bitar | 0 - 7 | 8 - 15 | 16 - 23 | 24 - 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Käll adress | |||||||||||||||||||||||||||||||
| 32 | Adress till mottagaren | |||||||||||||||||||||||||||||||
| 64 | Nollor | Protokoll | UDP-längd | |||||||||||||||||||||||||||||
| 96 | Källport | Destinationshamn | ||||||||||||||||||||||||||||||
| 128 | Längd | Kontrollera summan | ||||||||||||||||||||||||||||||
| 160+ | Data | |||||||||||||||||||||||||||||||
Käll- och destinationsadresserna hämtas från IPv4-huvudet. Värdet på protokollfältet för UDP är 17 (0x11). Fältet "UDP Length" motsvarar längden på rubriken och data.
Beräkningen av kontrollsumman för IPv4 är valfri, om den inte används är värdet 0.
Vid arbete med UDP över IPv6 krävs kontrollsumman. En metod för att beräkna den har publicerats i RFC 2460 :
Vid beräkning av kontrollsumman används återigen en pseudo-header, som imiterar en riktig IPv6-header:
| bitar | 0 - 7 | 8 - 15 | 16 - 23 | 24 - 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Käll adress | |||||||||||||||||||||||||||||||
| 32 | ||||||||||||||||||||||||||||||||
| 64 | ||||||||||||||||||||||||||||||||
| 96 | ||||||||||||||||||||||||||||||||
| 128 | Adress till mottagaren | |||||||||||||||||||||||||||||||
| 160 | ||||||||||||||||||||||||||||||||
| 192 | ||||||||||||||||||||||||||||||||
| 224 | ||||||||||||||||||||||||||||||||
| 256 | UDP-längd | |||||||||||||||||||||||||||||||
| 288 | Nollor | Nästa titel | ||||||||||||||||||||||||||||||
| 320 | Källport | Destinationshamn | ||||||||||||||||||||||||||||||
| 352 | Längd | Kontrollera summan | ||||||||||||||||||||||||||||||
| 384+ | Data | |||||||||||||||||||||||||||||||
Källadressen är densamma som i IPv6-huvudet. Mottagarens adress - slutlig mottagare; om IPv6-paketet inte innehåller routinghuvudet, så kommer detta att vara destinationsadressen från IPv6-huvudet, annars kommer detta på startnoden att vara adressen till det sista elementet i routinghuvudet och på destinationsnoden, destinationsadressen från IPv6-header. Värdet för "Nästa rubrik" är lika med protokollvärdet - 17 för UDP. UDP Length - Längden på UDP-huvudet och data.
På grund av bristen på robusthet måste UDP-applikationer vara förberedda för vissa förluster, buggar och dubbelarbete. Vissa av dem (till exempel TFTP ) kan lägga till elementära mekanismer för att säkerställa tillförlitlighet i applikationslagret om det behövs.
Men oftare används inte sådana mekanismer av UDP-applikationer och till och med stör dem. Strömmande media , realtidsspel för flera spelare och VoIP är exempel på applikationer som ofta använder UDP-protokollet. I dessa speciella applikationer är paketförlust vanligtvis inte ett stort problem. Om applikationen behöver en hög nivå av tillförlitlighet kan du använda ett annat protokoll (TCP) eller använda bruskorrigerande kodningsmetoder ( Erasure code ).
Ett allvarligare potentiellt problem är att UDP-baserade applikationer, till skillnad från TCP, inte nödvändigtvis har bra mekanismer för överbelastningskontroll och undvikande. Överbelastningskänsliga UDP-applikationer som förbrukar en betydande mängd tillgänglig bandbredd kan äventyra internetstabiliteten.
Nätverksmekanismer utformades för att minimera effekterna av trafikstockningar på okontrollerade, höghastighetsbelastningar. Nätverkselement som routrar som använder paketköer och spolningstekniker är ofta det enda tillgängliga verktyget för att bromsa överflödig UDP-trafik. DCCP (Datagram Congestion Control Protocol) är utformad som en dellösning på detta potentiella problem genom att lägga till mekanismer till slutvärden för att spåra överbelastning för höghastighets UDP-strömmar som strömmande media.
Många viktiga internetapplikationer använder UDP, inklusive DNS (där frågor måste vara snabba och endast bestå av en fråga följt av ett enda svarspaket), Simple Network Management Protocol ( SNMP ), Routing Information Protocol ( RIP ), dynamisk värdkonfiguration ( DHCP ) .
Röst- och videotrafik överförs vanligtvis med UDP. Protokoll för streaming av video och ljud i realtid är utformade för att hantera slumpmässiga paketförluster så att kvaliteten endast försämras marginellt istället för långa förseningar när de förlorade paketen återsänds. Eftersom både TCP och UDP arbetar på samma nätverk har många företag märkt att den senaste tidens ökning av UDP-trafik på grund av dessa realtidsapplikationer hindrar prestandan hos TCP-applikationer som databassystem eller bokföring . Eftersom både affärs- och realtidsapplikationer är viktiga för företag, ses det av vissa som en högsta prioritet att utveckla kvalitetslösningar för ett problem.
TCP är ett anslutningsorienterat protokoll, vilket innebär att ett "handslag" krävs för att upprätta en anslutning mellan två värdar. När en anslutning väl har upprättats kan användare skicka data i båda riktningarna.
UDP är ett enklare, anslutningslöst, meddelandebaserat protokoll. Dessa typer av protokoll upprättar inte en dedikerad anslutning mellan två värdar. Kommunikation uppnås genom att skicka information i en riktning från källa till destination utan att kontrollera destinationens beredskap eller tillstånd. I Voice over Internet Protocol-applikationer (Voice over IP, TCP/IP) har UDP en fördel framför TCP där varje "handskakning" skulle störa bra röstkommunikation. I VoIP antas det att slutanvändare kommer att tillhandahålla all nödvändig realtidsbekräftelse på att ett meddelande har tagits emot.
| Grundläggande TCP / IP-protokoll efter lager av OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliserad | |
| nätverk | |
| Transport | |
| session | |
| Representation | |
| Applicerad | |
| Annat ansökt | |
| Lista över TCP- och UDP-portar | |