9.9. UDP – skicka ett paket, hoppas på det bästa

UDP, User Datagram Protocol, är den enklare av de två tjänster som transportlagret erbjuder. Varje UDP-sändning är ett datagram – en självständig samling byte adresserad till en IP och en port, släppt ut i nätverket på egen hand. Protokollet levererar det om det kan; om det inte kan, försöker det inte igen, varnar inte avsändaren, och bevarar ingen ordning mellan datagram.

9.9.1. Vad UDP lägger till utöver IP

UDP är ett tunt lager ovanpå IP. Det lägger till tre saker till den råa IP-leveransen:

• Portnummer i båda ändarna, så att ett datagram kan levereras till rätt program på destinationsvärden, inte bara värden (se Portar).

• Ett längdfält så att mottagaren vet exakt hur många byte nyttolast som ska läsas.

• En liten kontrollsumma över huvudet och nyttolasten, så att mottagaren kan upptäcka ett skadat datagram och kasta det.

Det är allt. Allt annat IP gjorde eller inte gjorde behåller UDP. Datagram skickas inte om. De kan anlända i fel ordning. De kan dupliceras av egenheter i det underliggande nätverket. De kan tyst tappas om nätverket är överbelastat, bufferten vid destinationen är full, eller en av routrarna däremellan bestämmer sig för det.

Varje UDP-datagram skickas oberoende. Om ett tappas under transporten talar ingenting om det för avsändaren eller mottagaren – glappet är tyst.

9.9.2. Varför någon skulle använda det

Om UDP är så opålitligt, varför ha det alls? Tre skäl.

• Hastighet och omkostnader. En UDP-sändning är ett enda paket som går ut; ingen handskakning, inga bekräftelser, inget anslutningstillstånd att upprätthålla. Latens- och bandbreddskostnad är minimal.

• Oberoende meddelanden. En del trafik är en ström av statusuppdateringar där varje meddelande är en färsk stillbild och en gammal är värdelös. En kamera som publicerar ”jag lever fortfarande, här är min nuvarande mätning” varje sekund bryr sig om att leverera varje ny mätning, inte om att spela upp de mätningar som gick förlorade.

• Multicast. Ett enda UDP-datagram kan skickas till många mottagare samtidigt. (TCP kan inte göra det; varje TCP-anslutning är mellan exakt två slutpunkter.) Användbart för tjänsteupptäckt, telemetri till många lyssnare, videoströmning.

Där nätverket är bra och avsändarens tolerans för förlust är hög är UDP rätt svar. Där leverans och ordning måste garanteras behöver UDP antingen ytterligare ett lager av pålitlighet ovanpå, eller så bör applikationen helt enkelt använda TCP istället.

9.9.3. När man inte ska använda det

Det motsatta är också värt att vara tydlig med. UDP är fel val när:

• Varje byte är viktig. Konfigurationsdata, koduppdateringar, signerade transaktioner – alla fall där en saknad byte gör resultatet fel.

• Ordning är viktig. UDP-datagram 2 kan anlända före datagram 1.

• Meddelandet är stort. Stora nyttolaster måste delas upp i mindre datagram av applikationen; transportlagret gör det inte. Om någon enskild del förloras är hela meddelandet ofullständigt.

Om något av detta gäller, ta till TCP istället.

9.9.4. Konkreta exempel på en kamera

Kamerasidans exempel på UDP-trafik i verkligheten:

• Upptäckt. En kamera sänder ett ”vem är här”-datagram till det lokala nätverket vid uppstart; andra enheter svarar.

• Telemetri. En gång i sekunden skickar kameran ett litet datagram med sina aktuella sensormätningar till en insamlare. Att förlora ett enstaka stickprov spelar ingen roll eftersom nästa ändå anländer inom en sekund.

• Tidssynkronisering. NTP, nätverkstidsprotokollet, körs över UDP. Klienten skickar en liten förfrågan, servern svarar med den aktuella tiden; om svaret förloras frågar klienten helt enkelt igen senare.

• DNS-uppslagningar. Att fråga nätverket ”vilken IP mappar detta namn till?” körs över UDP. (Behandlas i Namn och DNS.)

Python-API:t för att skicka och ta emot datagram finns i UDP-socketar, efter att resten av berättelsen om transportlagret är på plats.