Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

TDAT2004-A Datakommunikasjon med nettverksprogrammering

Oppgave 27 - UDP virkemåte

...

Skrevet av Elena Falkenberg Nordmark og Erlend Tobiassen

 

Widget Connector
width854
urlhttps://www.youtube.com/watch?v=Z_ZXg1X89TU&feature=youtu.be
height480

1. Innledning

UDP, User Datagram Protocol, er en sluttpunkt-til-sluttpunkt-protokoll 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 når da TCP/IP ble separert ut i to lag. UDP var ment som et veldig enkelt 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-headeren header-en 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 . Den er laget som en minimal implementasjon av transportlaget.

Hensikten med å ha et slikt design er hovedsiktelig todelt, den . Den første grunnen er kontroll, siden . Siden UDP ikke implementerer avanserte funsjoner funksjoner, står applikasjoner som har spesefikke spesifikke krav fritt til å implementere – eller ikke –funksjonaliteten kunne, på sin egen måte, implementere funksjonaliteten som for eksempel TCP har, på sin egen måte. Den andre grunnen er overheadsiden . Siden UDP er såpass minimal, er det mindre informasjon som må utveksles mellom sender og mottaker, headeren . 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, ved at ; 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 lyd strømminglydstrømming.

2.2 Applikasjoner som ønsker finkontroll

...

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 sakt sagt, en minimal implementasjon og har så lite overhead som mulig.

...

1.4 kB totalt (payload + TCP-headers)

3. Virkemåte

3.1 Pakke-header

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

...

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

...

Checksum-feltet er brukt til å sjekke at all informasjon i UDP-pakken er tilstede 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-headerenheader-en, UDP-headeren og payloaenheader-en og payload-en. Hvordan checksummen kan verifiseres og regnes ut står nærmere 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-headerenheader-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.

...

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

...

Dette gir mening, 53 er standardporten til DNS så dette er porten maskinen min spør tjeneren på, maskinen . Maskinen min vil ha svar på port 60501, og lengden på DNS forespørrselen er 36 bytes.

...

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

4. Referanser

User Datagram Protocol (Wikipedia)

RFC793 (https://tools.ietf.org/html/rfc793x)

RFC768 (x)

Purpose of pseudo header in TCP checksum (postel)

...