Page History

TDAT2004-A Datakommunikasjon med nettverksprogrammering

Oppgave 27 - UDP virkemåte

Skrevet av Elena Falkenberg Nordmark og Erlend Tobiassen

1. Innledning

UDP, User Datagram Protocol, er en sluttpunkt-til-sluttpunkt-protokoll

1. Innledning

Hvor hører det valgte tema hjemme i lagmodellen. Hvilke standarder eller bestemmelser gjelder for dette temaet.

UDP, User Data Protocol, er en form for ende-til-ende-kommunikasjon som hører til i transportlaget. Den legger til rette for sending av meldinger, eller mer spesifikt: datagram, til andre tjenere på et IP-nettverk. . UDP ble laget som ett alternativ til TCP da TCP/IP ble separert ut i to lag. UDP var ment som et veldig enkelt alternativ til TCP.

Protokollen ble formelt formelt definert i 1980 i RFC 768.

Andre bestemmelser som er relevante for UDP er:

• RFC 2460 – Internet Protocol, Version 6 (IPv6) Specification*
• RFC 2675 – IPv6 Jumbograms
• RFC 4113 – Management Information Base for the UDP
• RFC 5405 – Unicast UDP Usage Guidelines for Application Designers

* Denne bestemmelsen er egentlig for IPv6, men på grunn av psudo-header-en som skal inkluderes i utregninga av checksum påvirker RFC 2675 også UDP.

2. Ønsket funksjonalitet

...

Hva er det man ønsker å oppnå, hvilke funksjonelle mangler vil man bøte på, hvorfor har man denne tjenesten eller dette systemet.

2.1 Hvorfor UDP?

• Forsinkelsessensitivtve applikasjoner (video- og lydstrømming)
• Applikasjoner som ønsker finkontroll over pakkebekreftelse, -gjensending og -timeout. (spill)
  
• Applikasjoner med kort levetid. (DNS)

Se under Attributes (wikipedia). streaming. 

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 funksjoner, står applikasjoner som har spesifikke krav fritt til å kunne, på sin egen måte, implementere funksjonaliteten som for eksempel TCP har. Den andre grunnen er overhead. Siden UDP er såpass minimal, er det mindre informasjon som må utveksles mellom sender og mottaker. header-en 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; om de ikke kommer frem, blir de ikke gjensendt. Dette er ideelt for live applikasjoner, da 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 lydstrø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 UDP ofte brukt, for eksempel når vi skal lage applikasjoner med kort levetid 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. UDP derimot er, som sagt, 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.com

246 bytes totalt (payload + UDP-headers)

Image Added

Eksempel på TCP DNS oppslag:

nslookup "-set vc" google.com

1.4 kB totalt (payload + TCP-headers)

Image Added

3. Virkemåte

3.1 Pakke-header

Pakke-header-en er første delen av UDP-pakken. Den er alltid 8 bytes lang og inneholder 4 felt, hvorav 2 er valgfrie.

...

3.2 Source port

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 gir senderen av pakken mulighet til å spesifisere hvilken port på tjeneren som pakken skal sendes til. 

Beskriv hvordan ting fungerer og gjøres. Oppbygning og struktur. Forklare med illustrasjoner eller skjermklipp, bilder eller analyse av pakkefangst.

4. Referanser

...

3.4 Length

Feltet spesifiserer lengden i bytes på pakken, inklusivt pakke-header-en og selve payload-en. Siden pakke-header-en 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 –.

RFC 2675 spesifiserer en måte å sende pakker opp til 4 GiB minus 1 byte i størrelse, kalt IPv6 jumbograms. Men siden maksimallengden til en UDP-pakke er mye mindre enn dette, blir det spesifisert i RFC 2675 at hvis length-feltet er 0, så er størrelsen på UDP-pakken 64 KiB eller større. Dette betyr at UDP-pakker kan tas i bruk med jumbograms.

3.5 Checksum

Checksum-feltet er brukt til å sjekke at all informasjon i UDP-pakken er tilstedet og ikke har blitt korrupt. Dette feltet er valgfritt for IPv4, men obligatorisk for IPv6. Hvis ubrukt, skal verdien være 0.

Checksum fungerer ved å utføre en matematisk operasjon på alle bytes i psudo-header-en, UDP-header-en og payload-en. Hvordan checksummen kan verifiseres og regnes ut står det mer om i neste kapittel.

3.6 Payload

Payload-feltet er selve innholdet som skal transporteres med UDP, størrelsen på payload-feltet i bytes er lik length-feltet sin verdi minus størrelsen på pakke-header-en.

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.

3.7 UDP eksempel

La oss ta en nærmere titt på DNS oppslaget som jeg gjorde i 2.3, med hjelp av Wireshark.

Image Added

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.

Image Added

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-header-en. Alt før UDP-header-en er andre lag i osi-modellen. Det som kommer etter er payload-en, i dette tilfellet er det DNS-protokollen. Vi ser at header-en inneholder (EC 55 00 35 00 24 C3 60)₁₆

Siden hvert felt i UDP består av 2 bytes får vi følgene oppdeling:

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.

Image Added

Som vi ser har tjeneren svart oss på port 60501 som forventet.

4. Referanser

User Datagram Protocol (Wikipedia)

RFC793 (x)

RFC768 (x) 

Purpose of pseudo header in TCP checksum (postel)

UDP, User Datagram Protocol (networksorcery)