...
* Denne bestemmelsen er egentlig for IPv6, men på grunn av psudo-headeren som skal inkluderes i utregninga av checksum påvirker RFC 2675 også UDP.
<video her>
2. Ønsket funksjonalitet
UDP er en protokoll som er ganske simpel av design, den er laget som en minimal implementasjon av transportlaget.
Hensikten med å ha et slikt design er hovedsiktelig todelt, den første grunnen er kontroll, siden UDP ikke implementerer avanserte funsjoner står applikasjoner som har spesefikke krav fritt til å implementere – eller ikke –funksjonaliteten som for eksempel TCP har, på sin egen måte. Den andre grunnen er overhead, siden UDP er såpass minimal er det mindre informasjon som må utveksles mellom sender og mottaker, headeren til UDP er 8 bytes i motsettning til TCP som har en header på minimum 20 bytes og maksimum 60 bytes.
2.1 Forsinkelsessensitive applikasjoner
I motsettning til TCP gir UDP ingen garantier for at pakker blir levert, ved at om de ikke kommer frem, blir de ikke gjensendt. Dette er ideelt for strømming live applikasjoner, da ting gjerne er live, gir det ikke gir mening å gjensende tapte pakker. Hvis man skulle gjensendt de ville de sannsynligvis ikke være nødvendige lenger. Noen eksempler på slike applikasjoner er video og lyd strømming.
2.2 Applikasjoner som ønsker finkontroll
Enkelte applikasjoner ønsker å selv ha all kontroll over bekreftelse, gjensending og timeout av pakker. Dette er gjengående i for eksempel multiplayer-spill, der egne avanserte system blir tatt i bruk for å holde et konsistent syn på spillverden. Siden UDP overlater gjensending til applikasjonen, vil det ikke forstyrre applikasjonens system.
2.3 Applikasjoner med kort levetetid
For å spare tid er det enkelt å bruke UDP UDP ofte brukt, for eksempel når vi skal bruke lage applikasjoner med kort levetid , for eksempel DNS. Til forskjell fra TCP der man måtte ha opprettet som DNS. Når man har kort levetid og liten payload vil overhead være på flere hundre prosent. I TCP er dette på grunn av at man må opprette et "handshake" og andre kontrollmekanismer, vil UDP ikke ha noen unødvendig overhead.. UDP derimot er som sakt en minimal implementasjon og har så lite overhead som mulig.
For å undersøke overheaden i et DNS lookup gjorde jeg to DNS oppslag og analyserte pakkene med Wireshark:
Eksempel på UDP DNS oppslag:
nslookup google.com246 bytes totalt (payload + UDP-headers)
...
Eksempel på TCP DNS oppslag:
nslookup "-set vc" google.com
1.4 kB totalt (payload + TCP-headers)
...
Dette feltet kan spesifisere et portnummer hos senderen av pakken, og er valgfritt. Når det ikke er i bruk skal verdien være 0.
Feltet er ofte brukt av senderen for å si hvilken port mottakeren skal sende svaret.
3.3 Destination port
Dette feltet angir portnummeret gir senderen av pakken mulighet til å spesifisere hvilken port på tjeneren som mottar pakken skal sendes til.
3.4 Length
Feltet spesifiserer lengden i bytes på pakken, inklusivt pakke-headeren og selve payload-en. Siden pakke-headeren alltid er 8 bytes, vil det si at 8 er minsteverdien til feltet. Siden feltet er 16-bits og beskriver lengden på pakken, er det en teoretisk øvre grense på størrelsen til en UDP melding – nemlig 64 KiB minus 1 byte –.
...
Unntaket på denne regelen er da hvis length-feltet er lik 0, som nevnt over er da størrelsen hva som helst over eller lik 64 KiB.
4. Referanser
Når man i den løpende teksten omtaler standarder, organisasjoner eller annet skal dette refereres. Referanselisten føres her (ikke URL i den løpende teksten)
3.6 UDP eksempel
La oss ta en nærmere titt på DNS oppslaget som jeg gjorde i 2.3, med hjelp av Wireshark.
Her ser vi de 2 pakkene som har blitt sendt frem og tilbake, Wireshark viser oss noe informasjon her, men la oss se nærmere på den første pakken.
Her ser vi hele pakken som ble sendt over nettet, vi er kun interessert i delen som er markert i blått, det er UDP-headeren. Alt før UDP-headeren er andre lag i osi-modellen. Det som kommer etter er payloaden, her er det da DNS protokollen. Vi ser at headeren inneholder (EC 55 00 35 00 24 C3 60)16
Siden hvert felt i UDP består av 2 bytes får vi følgene oppdeling:
| Source port | (EC 55)16 | 60501 |
|---|---|---|
| Destination port | (00 35)16 | 53 |
| Length | (00 24)16 | 36 |
| Checksum | (C3 60)16 | 50016 |
Dette gir mening, 53 er standardporten til DNS så dette er porten maskinen min spør tjeneren på, maskinen min vil ha svar på port 60501 og lengden på DNS forespørrselen er 36 bytes.
La oss se på den andre pakken som ble sendt, og om tjeneren svarte på port 60501.
Som vi ser har tjeneren svart oss på port 60501 som forventet.
4. Referanser
User Datagram Protocol (Wikipedia)
RFC793 (https://tools.ietf.org/html/rfc793User Datagram Protocol (Wikipedia)
RFC768 (x)
Purpose of pseudo header in TCP checksum (postel)
...