Nätverk och protokoll

UDP

Anslutningsfri transport som skickar oberoende datagram med minimal overhead.

Var du ser detta: Syns i paketfångster, nätverksdiagram, brandväggsregler samt system- och nätverksloggar.

Vad det är

UDP (User Datagram Protocol) är ett transportprotokoll som levererar diskreta meddelanden som kallas datagram. Till skillnad från TCP skapar den inte en anslutning eller underhåller en stream. Enheten du skickar är den enhet som mottagaren får, förutsatt att den kommer överhuvudtaget.

Nyckelpunkter

Varje UDP-paket är ett meddelande. Om den försvinner, försöker inte UDP igen.
Används när låg latens är viktig eller när högre lager hanterar tillförlitlighet.
Ofta ihopkopplad med protokoll som DNS, VoIP, streaming och QUIC.

Hur det fungerar i stora drag

En applikation skapar ett datagram och väljer en destination IP adress och port.
UDP lägger till en liten rubrik med källport, destinationsport, längd och kontrollsumma.
IP dirigerar paketet som alla andra IP-paket. Routrar behåller inte tillstånd per flöde för UDP som standard.
Mottagarens operativsystem använder destinationsporten för att leverera datagrammet till rätt uttag.
Om paketet försvinner eller kommer i fel ordning gör UDP ingenting. Återhämtning hanteras av applikationen.
Många nätverk använder NAT, så det första utgående paketet skapar ofta en tillfällig mappning som tillåter svar tillbaka.

Konkret exempel

En DNS-resolver skickar en liten UDP-fråga till port 53. Om svaret går förlorat försöker resolvern helt enkelt frågan igen, ofta till en annan server, istället för att förlita sig på UDP för att reparera förlusten.

Varför det är viktigt

Ibland är tillförlitlighet inte prioritet. Ljud, video och spel i realtid föredrar data i rätt tid framför perfekta data, och många protokoll har redan sina egna regler för omförsök och beställning. UDP finns för att tillhandahålla portar och grundläggande integritetskontroll utan vikten av en fullständig anslutning.

Säkerhetsperspektiv

UDP är lätt att förfalska, vilket möjliggör reflektion och förstärkningsattacker när protokoll svarar med större svar än förfrågan.
Eftersom det inte finns något handslag måste servrar vara försiktiga med att tilldela tillstånd eller göra tung krypto baserat på ett enda paket.
Använd autentisering på ett högre lager när identiteten är viktig, till exempel DTLS eller applikationsnivåsignaturer.

Vanliga fallgropar

Förutsatt att UDP alltid är snabbare. Förlust och återsändning vid applikationslagret kan göra det långsammare totalt sett.
Skickar stora datagram. Fragmentering ökar förlusteffekten och blockeras ofta.
Att glömma att UDP fortfarande behöver medvetenhet om trafikstockningar. Hög hastighet UDP kan överbelasta länkar och skada allt.
NAT och brandväggstimeout kan tyst bryta långlivade UDP-flöden.
Feldiagnostisera paketförlust som en serverbugg när det verkligen är sökvägsförlust.

FÖRDJUPNING

▾

Vad en UDP-sändning verkligen gör

När en applikation skickar med UDP ger den operativsystemet ett meddelande och en destination: IP adress och port. UDP lindar in det meddelandet i en liten rubrik och ger det till IP. Det finns inget handslag, inget anslutningstillstånd och inget löfte om att meddelandet kommer. Om det anländer kommer det som ett helt datagram, så meddelandegränser bevaras till skillnad från TCPs byteström.

Eftersom det inte finns någon inbyggd återställning kan UDP ha lägre latens. Det finns ingen väntan på bekräftelser innan fler skickas, och det finns ingen blockering av linjehuvudet orsakad av ett förlorat paket. Det är därför realtidsmedia, spel och moderna transporter som QUIC ofta väljer UDP som underlag.

UDP har fortfarande portar, vilket är hur en värd demultiplexerar inkommande datagram till rätt applikation. Den har också en kontrollsumma som hjälper till att upptäcka korruption. I praktiken är kontrollsumman inte en tillförlitlighetsfunktion, det är ett skyddsnät som låter en mottagare kasta dålig data istället för att skicka den uppåt.

Typiskt flöde: förfrågan, svar, klart

Ett vanligt UDP-mönster är en enda förfrågan och ett enda svar. DNS är det klassiska exemplet. Klienten skickar en fråga till port 53 och väntar kort. Om svaret kommer, bra. Om inte, sänder klienten om, eventuellt till en annan resolver. Applikationen hanterar logiken igen eftersom UDP själv inte gör det.

Eftersom omförsök görs i applikationslagret, ser du ofta unika identifierare inuti nyttolasten. Identifieraren låter klienten matcha ett svar på rätt förfrågan och ignorera dubbletter. Detta är en anledning till att nybörjare ibland tror att UDP är oordnad. I verkligheten tillhandahålls helt enkelt inte beställning, så ansökan måste ta ställning till om beställning alls spelar någon roll.

NAT och brandväggsbeteende formar också verklig användning. Utgående UDP skapar vanligtvis ett tillfälligt tillstånd i en NAT-enhet. Om programmet tystnar för länge kan det tillståndet upphöra och inkommande svar tas bort. Det är därför många UDP-baserade protokoll inkluderar keepalives även om själva applikationen är inaktiv.

Storlek, fragmentering och varför små paket vinner

Ett UDP datagram kan vara stort på papper, men nätverksvägen har en maximal överföringsenhet. Om ett datagram inte passar, kan IP fragmentering inträffa, och om ett fragment förloras förloras hela datagrammet. Många nätverk och mellanlådor hanterar fragment dåligt, så stora UDP nyttolaster är ömtåligare än de ser ut.

Praktiska UDP-protokoll håller nyttolasten tillräckligt liten för att passa i ett enda IP-paket på vanliga vägar. Om de behöver flytta mer data skickar de flera datagram och lägger till sina egna regler för sekvensering och återmontering. Detta är i huvudsak att bygga om en del av vad TCP gör, men skräddarsytt efter applikationens behov.

Om du någon gång ser en protokollbyte från UDP till TCP för stora svar, är det vanligtvis ett tecken på att fragmentering ansågs vara för riskabel. DNS gör detta, och andra protokoll gör liknande val beroende på implementeringens verklighet.

Bygga tillförlitlighet utöver UDP

Om en applikation behöver tillförlitlighet kan den lägga till bekräftelser och återsändningar. Det vanliga tricket är att bekräfta specifika meddelandenummer, skicka om efter en timeout och tolerera dubbletter. Detta kan vara enklare än TCP om applikationen inte behöver en kontinuerlig ström och kan behandla varje meddelande oberoende.

Om en applikation behöver trängselkontroll kan den implementera hastighetsbegränsning och backoff baserat på observerad förlust och fördröjning. QUIC är ett viktigt exempel: den använder UDP-paket, men den implementerar strömmar, bekräftelser, kryptering och trängselkontroll i användarutrymmet, vilket möjliggör snabbare utveckling än kärnbaserade TCP i många miljöer.

Nyckeln är att välja vad du faktiskt behöver. Många UDP-protokoll accepterar viss förlust eftersom det är mindre skadligt än fördröjning. Ett röstsamtal föredrar att släppa ett gammalt paket istället för att vänta på en återsändning, medan en filöverföring vill ha alla byte och har råd med förseningar.