Mest alle er allerede kjent med TCP som transportprotokoll. Ikke så mange skjønt er så kunnskapsrik med UDP som transportprotokoll. Det er for en god grunn. Nesten hver bit av data der ute enten det er program, session, eller andre lag transporteres via trofaste gamle TCP. Dette bringer tankene til en annen ting jeg hører ganske ofte fra folk, "Ja, TCP garantert å komme dit, vet du." Denne uttalelsen, faktisk er ganske galt.

TCP eller Transmission Control Protocol er bare forbindelse orientert. UDP eller User Datagram Protocol er imidlertid forbindelsesløs. Hva betyr det egentlig? Vel, hvis du har lest artiklene mine på TCP du vil ha bemerket at TCP har svært mange beregninger som inngår i spissen. Disse samme beregningene, dvs .: TCP sekvensnummer, kvitteringsnummer, er det som gjør den forbindelse orientert. Endelig hadde TCP en standard header lengde på tjue byte, vise åtte for UDP.

Hvordan UDP forskjellig?

Vel bare vår UDP protokollen har en lengde på åtte byte for å være nøyaktig. Det er tolv bytes mindre enn TCP. På grunn av dette, er UDP mye raskere ettersom det er mindre å overføre. En ekstra tolv bytes høres kanskje ikke mye ut, men multipliserer det med tusenvis av pakker, og du vil raskt merke en forskjell på nettverket. Sett på som en UDP header er så mye mindre, akkurat det ser det ut, spør du? Godt spørsmål! Vennligst se under for et diagram av hva en UDP header ser ut

_____________________________________________________
To byte kilde portnummer. | To byte målportnummeret
_____________________________________________________
to byte UDP pakkelengde | To bytes UDP kontrollsumverdi
_____________________________________________________
data om noen

Så vi kan se fra ovenstående som ikke har de ekstra tolv byte av overhead i UDP header gjør faktisk gjøre en betydelig forskjell. Dette ville forklare den manglende "connection orientert" for UDP. Du kan merke at vi også har en checksum i overskriften for UDP. Jeg vil gjerne benytte denne tiden til å påpeke at alle de fire kjerne protokoller, de er; IP, TCP, UDP, ICMP alle har summer. I alle de fire kjerne protokollene sjekksummen vil dekke protokollen header og alle data, hvis det er til stede. En av de siste tingene jeg har lyst til å nevne om UDP og dets kontrollsummen er at bruken er valgfritt. I hovedsak betyr det ikke til å bli brukt, mens i TCP, ICMP, og IP, det gjør det.

Er det garantert? Pokker ikke!

Vel, nå vet at UDP faktisk gir ingen garantier for levering, langt mindre noen bygget i beregninger for det, hvorfor skulle du ønske å bruke det? Med det i tankene, er det normalt avgjøres av utbygger, aka programmerer, hva transportprotokoll de ønsker å bruke når du utformer en ny søknad, eller andre lags protokollen. Det kan meget vel være tilfeller der hastigheten og størrelsen på en pakke er en vurdering. Skulle disse faktorene være en vurdering til utbygger så oddsen er at de vil velge UDP som sin transportprotokoll.

Hmmmmm, vel alt som er godt og bra, men noen applikasjonslaget, eller andre protokoller faktisk bruker UDP? Utmerket spørsmål, og svaret er ja. Det er ganske mange programmer som bruker UDP for transport. En av de mest kjente for de fleste er DNS eller domenenavnsystemet. Hovedtyngden av trafikken som genereres av DNS er faktisk fraktet om bruk av UDP. På en side note, er DNS en av disse protokollene som faktisk vil bruke både UDP og DNS. Det blir sagt mest DNS aktivitet er faktisk DNS-spørringer og svar. Disse, som nettopp nevnt, gjennomføres via UDP.

Skal vi noen gang kommer til å se en UDP pakke!

Vel sett på som jeg kan føle din forventning å komme inn guts av UDP hva vi ser på en UDP pakke, og gå over ulike feltene er beskrevet ovenfor i min snazzy diagram

02: 00:. 04,079943 192.168.1.100.53 > 192.168.1.200.57746: [udp sum ok] 60865 FormErr% [0q] 0/0/0 (12) (DF) (ttl 253, id 9987, len 40)
0x0000 4500 0028 2 703 4000 fd11 619a c0a8 0164 E .. ('. @ ... en .....
0x0010 c0a8 01c8 0035 E192 0014 ba83 EDC1 8091 ..... 5 ..........
0x0020 0000 0000 0000 0000 0000 0000 0000 ..............

Nå, hvis du har lest alle artiklene mine vil du innse at det er en utmerket ressurs for å gå gjennom pakker. I Hvis du ikke har kan du gå hit og laste ned TCP /IP og tcpdump flyer. Det er under "Additional Resources". Med dette dokumentet i hånden vi er nå klare til å navigere pakkene innholdet byte av byte.

En av måtene å raskt orientere deg i en pakke er å gå til destinasjonen adresse i IP header som er funnet på linje 0x0010 og er følgende fire byte med info;.. c0a8 01c8 Vi vet at med mindre det finnes alternativer i vår IP header at protokollen følgende IP header (i dette tilfellet UDP) som dokumentert av 11 i hex. Den 11 blir sett på den første linjen 0x00, og er i følge "fd11". Ved hjelp av noen av IP header beregninger vil tillate deg å raskt orientere deg om hvor oppfølging på protokollen starter.

Så med det sagt den første byte av vår UDP header blir deretter funnet på 0035 på linjen 0x0010. Det bemerkes på vår ned TCP /IP cheatsheet at de to første bytene i UDP header er viet til kilden port. Vel, hvis vi konvertere vår hex verdi av 0035 vil vi se at det faktisk svarer til kilden port nevnt ovenfor i pakken ie: port 53.

Så langt, så bra? Nå etter kilden port de neste to bytes er for destinasjonen port som dokumentert av hex verdier av E192, eller som det skal være representert ved meg for klarhet 0xe192. Når vi konvertere dette til desimal ser vi at det faktisk matcher målporten i pakken limes over.

Utmerket, er vi godt på vei gjennom UDP header! Etter dette er det UDP pakkelengde som er representert ved den heksadesimale verdi av 0x0014, som konverterer til 20 i desimal. Det er faktisk slik det skal være. Neste er opp UDP checksum verdi, og som er tildelt to bytes mye som alle de tidligere beregningene sett så langt dvs: kilde portnummer, målportnummeret, og UDP pakkelengde. Sjekksummen verdi i dette tilfellet er 0xba83. Vi har ikke faktisk se denne verdien representert i pakkehodet, men det er som det skal være. Bare vær oppmerksom på at det er der det ville bli funnet.

Vel nå sett på som dette er slutten av UDP header, etter rett etter at det er der applikasjonslaget data ville være. I dette tilfellet ville det være den DNS-informasjon. Det er mye mer til UDP protokollen da dette alene, men jeg vil foreslå at ytterligere lesing gjort på en del å bidra til å forbedre din kunnskap om dette lite verdsatt protokollen. Som alltid, jeg håper dette var til nytte for deg, og jeg alltid velkommen kommentarer.