I det här avsnittet tittar vi närmare på User Datagram Protocol (UDP) – vad det gör, hur det fungerar och när det är ett bättre val än TCP.

UDP är ett så kallat best-effort transportprotokoll, vilket innebär att det gör sitt bästa för att leverera data, men utan att garantera leverans eller ordning. Det är ett enkelt och snabbt protokoll som utför samma grundläggande uppgifter som TCP – att dela upp och återmontera data – men utan de extra funktioner som gör TCP tillförlitligt, såsom kvittenser och flödeskontroll.

Eftersom UDP är mycket enklare än TCP, brukar man ofta beskriva det utifrån vad det inte gör.

UDP:s viktigaste egenskaper

• Data sätts ihop i den ordning den tas emot.
• Förlorade datagram skickas inte om.
• Ingen session behöver etableras mellan avsändare och mottagare.
• Avsändaren får ingen information om mottagarens status eller tillgängliga resurser.

För mer teknisk information om UDP kan du läsa standarddokumentet RFC 768.

UDP-headern

UDP är ett tillståndslöst protokoll (stateless). Det betyder att varken klienten eller servern sparar information om sessionens status. Om tillförlitlighet krävs, måste detta hanteras av applikationen själv – inte av UDP.

En av de viktigaste faktorerna vid överföring av livevideo och röst är att datat kan flöda snabbt och utan avbrott. Den typen av applikationer kan acceptera viss dataförlust utan att användaren märker det, vilket gör UDP till ett utmärkt val för realtidskommunikation.

De dataenheter som skickas i UDP kallas datagram. Dessa skickas enligt principen best effort – UDP gör ett försök att leverera, men utan att kontrollera eller bekräfta mottagningen.

UDP-headern är mycket enklare än TCP-headern. Den består av endast fyra fält och kräver totalt 8 byte (64 bitar). Figuren visar hur dessa fält är placerade i headern.

Fält i UDP-headern

• Source Port – Detta 16-bitarsfält identifierar den avsändande applikationen eller processen på den sändande enheten. Source-porten används för att skapa en unik identifiering så att olika dataströmmar från samma avsändaradress kan särskiljas.

När ett UDP-datagram skickas tilldelas det en specifik source-port av operativsystemet eller applikationen. Denna port kan antingen vara:

• • en slumpmässigt vald port (ofta temporär), eller
  • en fördefinierad port som reserverats för en viss applikation eller tjänst.

Source-porten är viktig eftersom den gör det möjligt för mottagaren att veta vilken port den ska svara till om ett svar behöver skickas tillbaka.

• Destination Port – Detta 16-bitarsfält anger vilken port på mottagarens sida som datagrammet är avsett för. När avsändaren skapar ett UDP-datagram anger den en destinations port som pekar ut vilken applikation eller tjänst som ska ta emot datan på mottagarenheten.

När datagrammet når sin destination använder mottagaren portnumret för att avgöra vilken process eller applikation som ska hantera datan.
Destinations porten kan, precis som source-porten, vara antingen en förutbestämd port (t.ex. DNS = port 53) eller en dynamiskt tilldelad port av operativsystemet.

• Length – Detta 16-bitarsfält anger den totala längden på UDP-datagrammet, inklusive både UDP-headern (8 byte) och själva nyttolasten (datan). Längd-fältet visar antalet byte (oktetter) i hela datagrammet, vilket gör det möjligt för mottagaren att korrekt identifiera och extrahera datan.

Om längden som anges i headern inte stämmer överens med den faktiska mängden mottagen data, tyder det på att datagrammet kan ha skadats under överföringen.

Observera: längd-fältet inkluderar även eventuella fyllnadsbyte (padding) som används för att justera datagrammet till en multipel av 8 byte vid behov.

• Checksum – Kontrollsumman används för att kontrollera datans integritet och upptäcka eventuella fel som uppstått under överföringen. Värdet beräknas genom att utföra en checksummeberäkning på hela UDP-datagrammet – både headern och nyttolasten. Mottagaren utför samma beräkning och jämför sitt resultat med det mottagna kontrollsummavärdet:

• • Om värdena matchar, anses datan vara korrekt.
  • Om de inte matchar, indikerar det att datagrammet kan ha skadats, och det kasseras.

Kontrollsumman gör alltså UDP något mer tillförlitligt genom att kunna upptäcka fel – men inte åtgärda dem. UDP har inga inbyggda mekanismer för återförsändning eller felkorrigering, så applikationen själv måste hantera detta om det krävs.

Applikationer som använder UDP

UDP används ofta i applikationer där snabbhet är viktigare än tillförlitlighet, eller där applikationen själv kan hantera fel. Nedan följer tre huvudkategorier:

• Livevideo och multimedia – Applikationer som kan tåla viss dataförlust men inte fördröjning. Exempel: VoIP (Voice over IP) och live streaming.
• Enkla fråga–svar-tjänster – Program som skickar små mängder data och snabbt kan skicka om vid behov. Exempel: DNS (Domain Name System) och DHCP (Dynamic Host Configuration Protocol).
• Applikationer som själva hanterar tillförlitlighet – Enkelriktad kommunikation där applikationen själv ansvarar för felkontroll och kvittenser. Exempel: SNMP (Simple Network Management Protocol) och TFTP (Trivial File Transfer Protocol).

Figuren nedan visar exempel på applikationer som använder UDP.

Trots att UDP saknar flera av de tillförlitlighets- och säkerhetsmekanismer som finns i TCP, är det fortfarande mycket användbart för många typer av applikationer.

UDP används framför allt i realtidsapplikationer, där snabbhet och låg fördröjning är viktigare än att varje enskilt datapaket garanterat når fram. Exempel är röst- och videokommunikation, onlinespel och live streaming, där enstaka förlorade paket inte påverkar användarupplevelsen märkbart, men fördröjningar skulle göra det.