Här är de optionsklasser och värden som används nu. Det är inte så stor idé att översätta beskrivningen av vad dom gör, de gör sig bäst på engelska. Men som vi ser så har vi exempelvis säkerhet, tidsstämpling och felsökning.
Vad betyder dom olika delarna av headern då?
Versionfältet Talar om vilken version det är av IP-protokollet. Det behövs för att mottagaren skall kunna avkoda resten av informationen på rätt sätt. Att det finns ett sånt här versionsfält gör också att man kan byta protokoll under drift. Just nu är det version fyra av IP-protokollet som används.
Dataoffsetfältet Talar om hur lång IP-headern är så att IP-protokollet vet när headern slutar och datan börjar.
Tjänstetypsfältet Talar om vilken tjänst som anropas. Kan användas för att sätta olika prioriteter, t.ex. kanske en viss tjänst vill ha pålitilighet och felkorrigering medan en annan vill ha snabbheten istället. Men i verkligheten är det så att i princip alla protokoll behandlas med samma prioritet, oavsett vad det här fältet säger.
Totallängdsfältet Talar om hur långt hela datagrammet är, alltså både headern och datan. Det här fältet är på 16 bitar vilket begränsar storleken på datagramen till 65.535 bytes.
Identifikationsfältet Talar om vilket datagram ett del-datagram tillhör. För att sedan sätta ihop rätt delar av ett datagram med varandra så används det här fältet.(Fragmenteringen kommer lite senare.)
Flaggfältet Ett trebitars fält med tre olika flaggor. Den första är reserverad, den andra kallas för DF vilket står för Dont Fragment. Här tvingar man alltså ett datagram att bevaras intakt hela vägen. Om en viss nod inte kan göra det så får datagramet antingen ta en annan väg eller kastas bort. Det tredje fältet kallas för MF som står för More Fragments, dvs. det kommer flera fragment som tillhör samma sammanhängande datagram.
Fragmentoffset Talar om var i ett datagram som ett delpaket skall vara. Det kan vara max 8192 fragmenterade block då det här fältet är på 13 bitar.
Livslängdfältet Talar om hur många sekunder ett paket skall leva. Varför har man den här möjligheten? Därför att ett paket inte skall kunna cirkulera runt och ta upp bandbredd på nätet under obegränsad tid. Tänk dig själv om alla paket som skickades och inte nådde sin mottagare skulle cirkulera runt på nätet, då skulle det gå rejält slött. Maxvärde för livslängden är 255 sekunder.
Protokollfältet Talar om vilket protokoll som skall användas på nästa nivå (transportnivån), t.ex. TCP.
Header kontrollsummafältet Används för att kontrollera att headern kommit fram oskadad genom en checksummealgoritm.
Källadress- och destinationsadress- fälten 32 bitars adresser av sändare respektive motttagare. Adressen delas upp i fyra fält om vardera 8 bitar, vilket betyder att varje adress fält kan anta värden mellan0-255. Så en IP-adress ser ut exempelvis så här 192.168.10.1
Optionfältet Har flera olika användningsområden. Kan användas för att prova nya funktioner och protokoll, för framtida bruk eller för t.ex. säkerhet, felrapportering och felsökning.
Här är de optionsklasser och värden som används nu. Det är inte så stor idé att översätta beskrivningen av vad dom gör, de gör sig bäst på engelska. Men som vi ser så har vi
exempelvis säkerhet, tidsstämpling och felsökning.
IP-protokollet väljer alltså rätt väg, klarar av att hantera olika långa datagram och kan skicka data i olika media.
ICMP-headern ser ut ungefär så här:
Typfältet Kan sättas till olika värden, t.ex.
0 Eko svar(vid användning av PING
3 Målet går inte att nå
11 Livlängden har gått ut
12 Parameter problem/fel
13 Tidsstämpel förfrågning
Kodfältet Här specifieras ännu mera precist vilket fel det gäller.
| Kodfältsvärde | |
| 0 Nätet ej nåbart | |
| 1 Server ej nåbar | |
| 2 Protokoll ej nåbart | |
| 3 Porten ej nåbar | |
| 4 Fragmentering nödvändig, men DF flaggan är satt | |
| 5 Källkoppling misslyckad (!?) | |
| 0 Livslängden gick ut under överföring | |
| 1 Tid för hopsättning av fragment överskriden |
Kontrollsummefältet Precis samma teknik som i IP-headern, dvs. för kontroll av att headernkommit fram oskadad/oförändrad. Kontrollerar endast headern, inte datan
Parameterfältet Används när det finns ett syntaxfel i IP-headern. När ett problem har upptäckts så innehåller parameterfältet en pekare till den byte i IP-headern som orsakat problemet.
Så här ser en ARP-request ut:
Hårdvarutypsfältet Identifierar hårdvaru interfacet.
Exempel:
Protokolltypen Definierar vilket protokoll som används.
Exempel:
Hårdvaruadress längd Längden på varje hårdvaruadress i datagrammet i bytes. Det här är ett 8-bitars fält, vilket innebär att adressen kan anta värden från 0-255.
Protokolladress längd Samma som för hårdvaru adress längdsfältet, men för protokollet istället.
Processkod Talar om om det är en ARP-request eller en ARP-reply. Om det är en ARP-request så är det en etta och om det är en ARP-reply så är det en 2.
Avsändarens hårdvaruadress Är precis som det låter den avsändarens hårdvaruadress
Avsändarens IP-adress Precis vad det låter som, avsändarens IP-adress.
Mottagarens hårdvaruadress Mottagarens hårdvaruadress.
Mottagarens IP-adress Mottagarens IP-adress.
TCP-protokollet arbetar på nivå fyra(transport) i OSI-modellen. Paketen på transportnivån kallas för Transport Protocol Data Unit(TPDU). Det finns olika typer av TPDU:er t.ex. begäran om uppkoppling, nedkoppling eller dataöverföring. Som du kanske kommer ihåg så var TCP inte det ursprungliga protokollet, utan det hette NCP. TCP utvecklades för att täcka upp NCPs brister som bland annat hade att göra med säkerhet och hantering av stora trafikvolymer. TCP utvecklades t.ex. på ett sånt sätt att det skulle klara att arbeta på en osäker grund, dvs. ett stort nät med många olika vägar och olika hastigheter.
Vi börjar med att titta på TCP-headern.
Källportfältet Källporten är ett 16 bitars tal som visar från vilken port en TPDU skickas, alltså från vilken applikation datan skickas.
Mottagarportfältet Ett 16 bitars tal som talar om vart en TPDU ska hos mottagaren, alltså till vilken applikation datan ska.
Sekvensnummerfältet Talar om vilken TPDU det här är i ordningen.
Kvittensnummerfältet Talar om vilken TPDU som skall kvitteras med denna sändning.
Headerlängdfältet Talar om hur lång headern är och pekar på så sätt även ut var datan börjar.
URG-fältet Urgent. En flagga som kan sättas om det är bråttom. Då skall detta paket behandlas före andra, vanliga paket.
ACK-fältet Acknowledge. Talar om att det här skall användas som kvittenspaket. Både för kontaktetablering och datatrafik.
EOM-fältet End Of Message. Slut på meddelandet.
RST-fältet Reset. För att starta om en förbindelse.
SYN-fältet För att etablera en förbindelse. Den host som vill ha förbindelsen sätter SYN till ett och ACK till noll och skickar en TBPU. Mottagaren svarar med en TBPU med SYN ett och ACK ett.
FIN-fältet För att avsluta en förbindelse.
Fönsterfältet Hanterar flödeskontrollen. Talar om hur många bytes (16 bitar, dvs. max 65.535 bytes) som kan skickas utan kvittens.
Checksummefältet Feldetektering av enklare modell.
Brådskande pekare talar om var den brådskande informationen finns när URG biten är satt.
Optionfältet T.ex. när hostarna förhandlar om bufferstorleken.
Datafältet Max 64Kb data.
TCP-protokollet erbjuder alltså en säker överföring från punkt till punkt och till rätt applikation. Klarar av att dela upp informationen, fragmentera, och defragmentera information. TCP är väldigt integrerat med IP så det är nästan omöjligt att skilja dom åt, därav det välkända TCP/IP.
Mottagarportfältet Portnumret till mottagarapplikationen.
Längdfältet Talar om hur långt hela paketet är inklusive informationen.
Checksummefältet Man kan ha med en 16 bitars kontrollsumma, men UDP hanterar inte den.
Det är nästan så man skulle klara sig utan UDP och köra med bara IP, men då skulle man inte kunna adressera datan till en applikation och inte heller ha checksumman.
Copyright Andreas Höglund © 1999.