TCP/IP
Kommunikationsstandarden på Internet er baseret på TCP/IP arkitekturen. Formålet med denne note er at give indblik i TCP/IP arkitekturens opbygning og de vigtigste protokoller knyttet dertil. Noten indledes med et generelt overblik over TCP/IP arkitekturen. Herefter følger en mere detaljeret beskrivelse af de vigtigste protokoller, hvorunder følgende emner behandles:
• adressering
• netværksprotokoller
• transportprotokoller
1. Overblik over TCP/IP arkitekturen
I dette afsnit introduceres TCP/IP arkitekturen, herunder en præsentation af den lagdelte model samt en kort beskrivelse af de vigtigste protokoller. For at give en bedre forståelse af baggrunden for TCP/IP og de dertil knyttede funktioner indledes afsnittet med en kort beskrivelse af den fysiske opbygning af Internet.
1.1. Den fysiske Infrastruktur
Internet består af et meget stort antal private netværk, som er sammenkoblede (for øjeblikket flere hundrede tusinde). I den gængse terminologi opereres der med 3 typer af netværk:
• Lokalnet: Et netværk baseret på broadcast topologi og LAN teknologi.
• Regionalnet: Et fjernnet med moderat transmissionskapacitet (typisk 512 kbps - 2 Mbps) bestående af få til mange routere, der er sammenkoblet i punkt-til-punkt topologi (typisk en irregulær topologi). Som eksempel kan nævnes Undervisningsministeriets Sektornet.
• Backbone: Et fjernnet med stor transmissionskapacitet (typisk mere end 2 Mbps) bestående af få til mange routere, der er sammenkoblet i punkt-til-punkt topologi (typisk en irregulær topologi). Som eksempel kan nævnes det danske forskningsnet, der administreres af UNI•C (det har en kapacitet på 34 Mbps).
Et lokalnet ejes typisk af en Internet udbyder eller en virksomhed med Internet adgang. Det er typisk forbundet til et regionalnet via en router, men kan i sjældne tilfælde have direkte forbindelse til et backbone net. Et regionalnet kan være forbundet til et eller flere regional- eller backbone net via routere. Det ejes typisk af en større organisation eller en større Internet udbyder. Backbone net er ofte forbundet til andre backbone net på tværs af landegrænser. De ejes typisk af meget store Internet udbydere eller meget store organisationer.
Til at forbinde routerne anvendes der offentlige datatjenester. Der anvendes i de fleste tilfælde tjenester, hvor der ikke skal foretages opkald, hvilket vil sige faste forbindelser eller tjenester med permanent virtuelt kredsløb (X.25, Frame Relay og ATM).
Computere med Internet adgang (dvs. en registreret IP-adresse), såvel arbejdsstationer som servere, kaldes hosts. De er typisk forbundet til et lokalnet, enten direkte eller via en opkaldt offentlig datatjeneste (f.eks. DATEL opkaldt eller ISDN2), men kan i meget sjældne tilfælde have direkte forbindelse til en Internet router. Det anslås, at der i dag findes omkring 20 millioner hosts.
Betragtet som en helhed der altså tale om ét meget stort pakkekoblet net med irregulær topologi. Nettet består af hosts (arbejdsstationer og servere) og routere, der forbinder de enkelte lokal- regional- og backbone net. Routerne er forbundet indbyrdes vha. offentlige datatjenester, og hver host har forbindelse til én eller flere routere - i langt de fleste tilfælde via et lokalnet.
1.2. Den lagdelte model
TCP/IP arkitekturen (også kaldet TCP/IP protokolstakken) er opbygget som en 5-lags model med funktionalitet svarende til OSI-modellens. Den væsentligste forskel i forhold til OSI-modellen er, at de applikationsorienterede funktioner i TCP/IP arkitekturen er samlet i et enkelt lag, hvor OSI-modellen opererer med 3 lag. TCP/IP arkitekturen anvendes også som kommunikationsstandard i mange lokalnet.
1.3. De vigtigste protokoller
TCP/IP specifikationerne er beskrevet i nummererede dokumenter kaldet Request For Comments (RFC). Organisationerne Internet Architecture Board (
http://www.iab.org) og Internet Engineering Task Force (
http://www.ietf.org/) er ansvarlige for vedligeholdelse og publikation af disse dokumenter. Dokumenterne findes mange steder på WWW, men den officielle hjemmeside er RFC Editor (
http://www.rfc-editor.org/). Det samlede sæt af specifikationer er ret omfattende (flere tusinde sider), og mange af dokumenterne er svære at forstå. Hvis man er interesseret i at vide noget om de nyeste standarder, kan det imidlertid være nødvendigt at kigge i RFC’erne, da sådanne emner normalt først kommer med i lærebøger efter nogle år.
1.3.1. Applikationslaget
Applikationsprotokollerne i TCP/IP arkitekturen arbejder efter client/server princippet, hvor klienter kommunikerer med en server på følgende måde:
• klienten sender en forespørgsel til serveren og afventer svar.
• serveren modtager forespørgsler, behandler dem og sender svar til klienterne.
Serveren kan betjene flere klienter samtidigt, endda samtidig med at den “lytter” efter nye forespørgsler fra klienter. Kommunikationsforløbet “forespørgsel + svar” kaldes en transaktion, og det er altid klienten, der har initiativet. Som eksempel på klient og server kan nævnes henholdsvis Web-browser og Web-server. Bemærk at klient og server er programmer. De vigtigste applikationsprotokoller er kort beskrevet nedenfor
DNS (RFC 1034-1035 og 974)
DNS (Domain Name System) gør det muligt, via forespørgsel til en navneserver (Domain Name Server), at finde en computers Internet adresse (IP-adresse), når dens domænenavn er kendt. Fordelen ved domænenavne er at de er lettere at huske end IP-adresser. Det kræver særlig registrering (og betaling) at få et domænenavn til en computer.
FTP (RFC 959)
Formålet med FTP (File Transfer Protocol) er at tilbyde en brugervenlig, fleksibel, effektiv og pålidelig form for filoverførsel.
HTTP (RFC 2616-2617)
Formålet med HTTP (HyperText Transfer Protocol) er at tilbyde en fleksibel form for informationsoverførsel, hvor der kan overføres flere informationstyper i én transaktion (tekst, hypertekst, billeder, video m.m), og hvor den af klienten modtagne information i en transaktion automatisk bliver vist på skærmen.
SMTP (RFC 821) og POP (RFC 1939)
SMTP (Simple Mail Transfer Protocol) benyttes, når en klient skal sende elektronisk post, mens POP (Post Office Protocol) benyttes, når en klient skal hente elektronisk post fra en Mail server. Der findes også specifikationer for formatet af et brev, dvs. hvordan et brev skal opbygges samt hvilke typer information det må indeholde, hvis det skal kunne modtages af en Mail server. Disse specifikationer indgår dog hverken i SMTP eller POP, men er placeret i seperate dokumenter (RFC 822 samt RFC 2045-2049). RFC 822 specificerer formatet af et brev, som kun indeholder tekst fra standard ASCII tabellen. RFC 2045-2049 indeholder formatspecifikationer for breve, der indeholder andet end standard ASCII tegn (herunder også grafik, audio og video). Disse specifikationer kaldes Multipurpose Internet Mail Extensions (MIME). HTTP benytter også MIME specifikationerne til at fastlægge formater for Web dokumenter.
Telnet (RFC 854)
Telnet er en ældre protokol beregnet på kommunikation mellem uintelligente terminaler og en central mainframe computer. Der kan overføres tastaturkoder og skærmbilleder, men kun som ren tekst. Derfor anvendes Telnet protokollen i dag ikke særligt meget. For at lave en Telnet opkobling fra en intelligent arbejdsstation (f.eks. en PC) kræves et terminalemuleringsprogram.
NNTP (RFC 977)
NNTP (Network News Transfer Protocol) anvendes til overførsel af Usenet nyheder. Indlæg til nyhedsgrupper sendes til såkaldte News servere, der findes rundt omkring på Internet. De fleste News servere kræver, at man er registreret som abonnent for at kunne læse indlæggene. Ligesom der er tilfældet med transmissionsprotokollerne for E-mail, beskriver NNTP ikke formatet af et indlæg. Dette er specificeret i RFC 1036. Specifikationerne i RFC 1036 er stærkt baseret på formatet for E-mail (RFC 822 samt RFC 2045-2049), og derfor er reglerne for opbygning og indhold af nyhedsindlæg meget lig reglerne for et brev.
PING og Traceroute
PING (Packet Internet Groper) og Traceroute er kommandoer, der anvendes til at se, om der er kontakt til en given host. Traceroute kan desuden anvendes til at se, hvilken rute en pakke til en anden host fulgte. Ping og Traceroute er begge slutbrugertjenester, der er velegnede til diagnosticering, hvis der er manglende eller dårlig kontakt til en host, som man ønsker at kommunikere med. Traceroute er specificeret i RFC 1393, mens der ikke findes specifikationer for PING. PING benytter sig af informationer, der er til rådighed i de pakker, der transmitteres.
1.3.2. Transportlaget
Der findes 2 transportprotokoller, TCP og UDP:
TCP (RFC 793)
Formålet med TCP (Transmission Control Protocol) er at sikre pålidelig og effektiv dataoverførsel mellem to programmer på vikårligt forbundne computere. TCP er forbindelsesafhængig.
UDP (RFC 768)
Formålet med UDP (User Datagram Protocol) er at sikre effektiv dataoverførsel mellem to programmer på vikårligt forbundne computere. UDP bidrager ikke til pålidelig dataoverførsel, da protokollen er forbindelsesuafhængig.
De fleste applikationsprotokoller anvender TCP.
1.3.3. Internet laget
Internet laget består af Internet Protocol (IP), nogle hjælpeprotokoller samt nogle dedikerede routing protokoller.
IP (RFC 791)
Formålet med IP (Internet Protocol) er at sikre effektiv overførsel af data mellem 2 computere, uanset hvor i verden de 2 computere befinder sig. IP er forbindelsesuafhængig og bidrager således ikke til pålidelig dataoverførsel. IP varetager følgende funktioner:
• Basale routing funktioner, som er nødvendige for en host. Dedikerede routere anvender normalt ikke IP’s routing funktioner men derimod nogle dedikerede routing protokoller.
• Congestion control, dvs. undgå at nettet overbelastes.
Fragmentering, dvs. mulighed for at opsplitte en pakke i flere mindre pakker, kaldet fragmenter, og samle disse igen til den oprindelige pakke ved den endelige destination. Funktionen fragmentering er nødvendig, fordi de forskellige netteknologier (Ethernet, Token Ring, X.25 m.m) opererer med maksimale pakkelængder, som er forskellige. F.eks. må en pakke i Ethernet ikke være større end 1500 Bytes, mens et datagram i et X.25 net må være op til 32 kB.
ICMP (RFC 792)
Formålet med ICMP (Internet Control Message Protocol) er at udveksle kontrolinformation mellem computere (hosts og routere), herunder især fejl- og statusinformation. De informationer, der udveksles via ICMP, benyttes bl.a. af kommandoen PING, der der blev omtalt tidligere.
ARP (RFC 826)
ARP (Address Resolution Protocol) gør det muligt at finde MAC-adressen for en PC i lokalnet, når PC’ens IP-adresse er kendt. Denne funktion bruges af hosts og Internet routere, som er tilsluttet lokalnet.
RARP (RFC 903)
RARP (Reverse Address Resolution Protocol) gør det muligt i lokalnet at tildele en midlertidig IP-adresse til en computer, der ikke har et permanent lager, f.eks. en diskløs PC eller en netværksprinter. Det er i øvrigt almindeligt at tildele alle arbejdsstationerne en midlertidig IP-adresse, da denne procedure kan foregå automatisk, mens en permanent IP-adresse skal konfigureres på hver enkelt PC. Enkeltstående PC’er med Internet abonnement tildeles for de fleste abonnementtypers vedkommende også en midlertidig IP-adresse, når de er on-line(Her anvendes dog Point-to-Point Protocol (se afsnit 1.3.4), da RARP er beregnet på computere i lokalnet.) . Derved kan en Internet udbyder have flere abonnenter end det antal IP-adresser, som udbyderen råder over. Ulempen herved er, at alle abonnenter ikke kan være on-line samtidigt. Der findes 2 nyere og bedre protokoller, kaldet Bootstrap Protocol (BOOTP: RFC 951) og Dynamic Host Configuration Protocol (DHCP: RFC 2131-2132), der i praksis anvendes i dag.
Dedikerede Routing protokoller:
Der kan vælges mellem flere forskellige dedikerede routing protokoller. De er opdelt i to grupper, kaldet henholdsvis IGP (Interior Gateway Protocol) og EGP (Exterior Gateway Protocol). IGP betegner en routing protokol, som kan benyttes af Internet routere, der opererer internt i et autonomt
system. Et autonomt system består af et eller flere regional- eller backbone net, der styres af en enkelt organisation. EGP betegner en routing protokol, der kan benyttes af Internet routere, som har forbindelse til andre autonome systemer.
1.3.4. Network Interface laget
Formålet med Network interface laget er at sikre effektiv og pålidelig dataoverførsel mellem 2 direkte forbundne computere (dvs. hosts eller routere). I TCP/IP arkitekturen er der specificeret 2 network interface protokoller, PPP (Point-to-Point Protocol - RFC 1661-1662) og SLIP (Serial Line Interface Protocol - RFC 1055), hvoraf den sidstnævnte er forældet og stort set ikke anvendes mere. PPP skal kun anvendes, hvis der ikke i forvejen findes en brugbar datalink protokol til den netteknologi, som forbinder de 2 computerr (dette er kun tilfældet for DATEL opkaldt, ISDN og faste forbindelser). Er der tale om computere med direkte forbindelse til et lokalnet, benyttes en LAN-protokol (Logical Link Control - LLC) fra OSI-modellen. Er der tale om computere forbundet vha. andre offentlige tjenester end DATEL opkaldt, ISDN og faste forbindelser, benyttes en datalink protokol, som er fast tilknyttet den pågældende tjeneste. Disse datalink protokoller er ligeledes specificeret i OSI modellen. PPP er forbindelsesafhængig med mulighed for
• fejlhåndtering og flowkontrol
• adgangskontrol vha. brugernavn og password
• automatisk tildeling af midlertidig IP-adresse
1.3.5. Hardware laget
I TCP/IP arkitekturen findes der ingen specifikationer for hardware laget. De fleste hardware standarder er specificeret i OSI-modellen under det fysiske lag.
2. Adressering
Der findes 4 niveauer af adressering i TCP/IP protokolstakken:
Network Interface laget:
Hvis der sendes fra en computer (host eller router) i et lokalnet til en anden computer i samme lokalnet, skal rammerne indeholde MAC-adresser på afsender og modtager. En MAC-adresse er et tal på 6 bytes, der angiver nummeret på computerens netværkskort. MAC adresser er kun nødvendige, når der skal udveksles rammer mellem 2 computere i samme lokalnet.
Internet laget:
Når der udveksles pakker mellem 2 computere på Internet, skal pakkerne indeholde IP-adresser på afsender og modtager, også selvom de 2 computere er i samme lokalnet. En IP-adresse er et tal på 4 bytes (32 bit), der angives som 4 tal mellem 0 og 255, adskilt med punktum (f.eks. 233.103.7.15). Den består af tre dele, hvor det første felt angiver adressetypen (der findes 4 forskellige), det andet felt hvilket netværk computeren hører til, og det tredje nummeret på computeren i det pågældende netværk. Formatet for IP-adresser omtales nærmere i afsnit 2.1. Organisationen Internet Corporation for Assigned Names and Numbers (ICANN) er ansvarlige for tildeling af IP-adresser på Internet.
Transportlaget:
Da flere programmer på samme computer kan kommunikere samtidigt, er selve computerens adresse ikke tilstrækkelig, når der skal udveksles data. Derfor udvides adresseinformationen i transportlaget til også at omfatte numre på de programmer, der kommunikerer. Disse numre kaldes i TCP/IP arkitekturen for porte. En port er et tal på to bytes, hvilket giver mulighed for 65536 forskellige porte. En del af portene er reserverede til bestemte formål. F.eks. er det standard, at en Web server tildeles port 80. Fordelen herved er, at man ikke behøver at angive Web serverens port, når man kalder op til denne, men kan nøjes med at angive domænenavnet eller IP-adressen på den computer, som Web serveren ligger på. Der findes reserverede porte for alle de typer af servere, der kan kontaktes via Internet (HTTP, FTP, Telnet, DNS, SMTP/POP, NNTP mm.). Organisationen Internet Assigned Numbers Authority (
http://www.iana.org/) er ansvarlig for publikation af reserverede portnumre.
Applikationslaget:
Når en bruger ønsker at udveksle information med en server på Internet, er det uhensigtsmæssigt for brugeren at skulle indtaste IP-adressen på den computer, der skal kaldes op til, da IP-adresser er svære at huske. Derfor tilbyder TCP/IP arkitekturen, at brugeren i stedet kan indtaste computerens domænenavn (f.eks.
www.ehs.dk). Til hvert domænenavn er der knyttet en IP-adresse. Inden opkaldet til serveren påbegyndes, oversættes domænenavnet automatisk til en IP-adresse vha. DNS protokollen. For at kunne anvende domænenavne kræves der naturligvis, at den server, der skal udveksles information med, har et domænenavn, men også at klienten har adgang til en DNS server. Organisationen ICANN er ansvarlige for tildeling af domænenavne på Internet.
Ligesom man kan adressere en computer vha. IP-adresse eller domænenavn og et program vha. portnummer, kan man adressere ressourcerne på Internet (Web dokumenter mm.) vha. en såkaldt URL (Uniform Ressource Locator). Det er denne information man angiver i browserens adressefelt, når man skal indlæse en Webside. En URL består normalt af en protokolspecifikation, et domænenavn og en stispecifikation (f.eks.
http://www.ehs.dk/EDBSkole/Datamatiker/), men den kan også opbygges på andre måder. Mulighederne er beskrevet i RFC1738.
2.1. IP adresseformat
Som tidligere nævnt, består består en IP-adresse af 3 dele - en adressetype, en netværksadresse og et computernummer. Computernummeret kaldes normalt hostadresse, selvom det også kan angive nummeret på en router. Det generelle format er vist nedenfor:
Adressetype.Netværksadresse.Hostadresse
Fordelen ved at opdele adressen i flere dele er, at routing bliver meget enklere. En router behøver således ikke at have information om hver enkelt host for at kunne sende en pakke videre i den rigtige retning. Det er tilstrækkeligt, at routeren har information om beliggenheden af det netværk, som pakken skal sendes til. Det gør det også lettere at registrere adresser, da en virksomhed kun behøver at få registreret adressetypen og netværksadressen hos ICANN. Virksomhedens netværksansvarlige kan så selv tildele hostadresser til de enkelte computere uden risiko for adressekonflikt. Ulempen er, at en computer skal have ny IP-adresse, hvis den flyttes til et andet netværk.
De 4 adressetyper, der findes, kaldes klasse A, klasse B, klasse C og klasse D. Klasse D er et specielt format, der muliggør transmission af en pakke til flere modtagere. Det omtales ikke yderligere i denne note. Formatet for de 3 førstnævnte typer er vist nedenfor.
Klasse A: 0 netværk (7 bit) host (24 bit)
Klasse B: 10 netværk (14 bit) host (16 bit)
Klasse C: 110 netværk (21 bit) host (8 bit)
Adressetypen består, som det ses, af 1, 2 eller 3 bits afhængig af om der er tale om en klasse A, B eller C adresse. Klasse A adresser er beregnet for meget store netværk. Som det ses består netværksadressen af 7 bits. Dette giver 27=128 kombinationsmuligheder, men da det laveste og det højeste tal ikke må anvendes (dette gælder også for hostadresser), kan der maksimalt være 126 netværk i verden, som anvender klasse A adresser. Alle klasse A adresser er i dag opbrugt. Klasse B adresser er beregnet for store netværk, f.eks. et universitets samlede netværk. Da der i dag kun er få klasse B adresser tilbage, er det kun særlige organisationer, som kan få rådighed over klasse B adresser. Klasse C adresser er beregnet for forholdsvis små lokalnet, idet hostfeltets 8 bit giver plads til maksimum 254 computere. Har man mere end 254 computere i sit lokalnet, må man anvende flere netværksadresser, medmindre man kan få tildelt klasse B adresser. I tabellen nedenfor er der for hver adressetype angivet, hvor mange netværk der er plads til, samt hvor mange hosts der kan være pr. netværk.
Adressetype Antal netværk Antal hosts pr. netværk
Klasse A 126 16777218
Klasse B 16382 65534
Klasse C 2097150 254
Det er muligt at konfigurere et netværk, så en del af hostfeltet i en IP-adresse angiver en såkaldt subnet (undernet) adresse. Har man f.eks. 2 sammenkoblede lokalnet med hver 100 hosts, kan man nøjes med én netværksadresse og derved spare penge, hvis man benytter første bit i hostadressen til at angive undernet adresse for de 2 lokalnet. Det forudsætter dog, at de 2 lokalnet sammenkobles med en router, da en bro opererer på Network Interface laget og derfor ikke kan læse IP-adresser.
I praksis angiver man i den såkaldte subnet mask (undernetmaske), om der anvendes subnet adresser eller ej. Undernetmasken, der skal konfigureres på alle computere og routere i netværket, består ligesom IP-adressen af et tal på 32 bit, der angives som 4 tal mellem 0 og 255, adskilt af punktum. Hvis der ikke anvendes subnet adresser, har undernetmasken i et klasse C netværk værdien
255.255.255.0
hvilket svarer til den binære værdi (24 1’ere og 8 0’er):
11111111 11111111 11111111 00000000
Nullerne i subnetmasken ovenfor angiver, at de sidste 8 bit i IP-adressen skal opfattes som en hostadresse, mens de 24 foranstående skal opfattes som adressetype og netværksadresse. Hvis man ønsker at anvende den første bit af hostadressen til at angive undernet adresse for 2 sammenkoblede lokalnet, skal undernetmasken se således ud:
11111111 11111111 11111111 10000000 = 255.255.255.128
Dette svarer til følgende adresseformat:
110 netværk (21 bit) undernet (1 bit) host (7 bit)
Der er plads til godt 2 millioner netværk i verden på Internet. Da dette antal ikke vil være tilstrækkeligt i fremtiden, er der udviklet en helt ny protokol, kaldet IP version 6 (ipv6: RFC 2460), hvor adressefeltet er på 128 bit (dette gør det muligt at have en IP adresse for ca. hver kvadratcentimeter på jorden). Desuden er ipv6 i modsætning til den gamle IP protokol (version 4) forberedt for ATM-teknologi. Dette betyder, at man med indførelsen af ipv6 får mulighed for erstatte de eksisterende transmissionsfaciliteter på Internet med ATM, og herved få mulighed for at transmittere TV via Internet. Allerede på nuværende tidspunkt kører en del backbone netværk rundt omkring i verden med ipv6/ATM (se
http://www.6bone.net/). Danmark var blandt de første, der implementerede et sådan backbone netværk. Det indgår i forskningsnettet (
http://www.darenet.dk/), der administreres af UNI-C. IP version 6 indeholder også avancerede sikkehedsfaciliteter (hemmeligholdelse vha. kryptering og sikker identitet vha. digital signatur).
3. Internet laget
Internet laget består som tidligere nævnt af Internet Protocol (IP), nogle hjælpeprotokoller og nogle dedikerede routing protokoller. Disse behandles i det følgende.
3.1. Internet Protocol
IP protokollen indeholder kernefunktionerne i Internet laget - routing, congestion control og fragmentering. I dette afsnit beskrives disse funktioner sammen med dataformatet for IP. Protokollen er som tidligere nævnt forbindelsesuafhængig og understøtter derfor ikke funktionerne fejlhåndtering og flowkontrol.
3.1.1. IP dataformat
Dataenheden kaldes en pakke eller et datagram, og dens format er vil her blive beskrevet.
Version:
Angiver hvilken version af IP protokollen, der har genereret datagrammet. Nuværende - og sidste version med det ovenfor viste dataformat - er version 4 (der findes ingen version 5, og IP version 6 benytter et andet dataformat).
Header længde:
Længden af headeren målt i enheder á 32 bits (maks. 16 enheder = 64 bytes).
Service type:
Angiver ønsker med hensyn til transmissionskvalitet. En router kan benytte disse oplysninger til valg af en udgående linie med passende transmissionskvalitet samt til prioritering af rækkefølgen for ventende datagrammer.
Datagram længde:
Længden af datagrammet målt i bytes ( maks. 64 kB).
Datagram nummer, flag og fragment position:
Disse felter er knyttet til funktionen fragmentering. Som tidligere nævnt gør fragmenteringsfunktionen det muligt at opsplitte en pakke i flere mindre pakker, kaldet fragmenter, og samle disse igen til den oprindelige pakke ved den endelige destination. De 3 felter knyttet til fragmentering indeholder oplysninger, som gør det muligt at gendanne den oprindelige pakke. Sender en computer på et Token Ring netværk f.eks. et datagram på 4000 bytes til en computer på et Ethernet netværk, skal datagrammet opsplittes i 3 fragmenter, da den maksimalt tilladelige pakkestørrelse på Ethernet er 1500 bytes. Opsplitningen i fragmenter foretages altid af en router og først, når behovet opstår, mens samlingen af fragmenter sker ved den endelige destination, dvs. en host. Feltet “datagram nummer” angiver, hvilket oprindeligt datagram et fragment hører til. Feltet “fragment position” angiver fragmentets position i det oprindelige datagram målt i enheder á 8 bytes (således kan længden af et fragment ikke være mindre end 8 bytes). Antager vi, at datagrammet på 4000 bytes i ovennævnte eksempel opsplittes i 3 fragmenter på hhv. 1440, 1280 og 1280 bytes (hhv. 180, 160 og 160 enheder á 8 bit), vil første fragment have positionen 0, andet fragment positionen 180 og tredje fragment positionen 340. Feltet “flag” angiver, om det er lovligt at fragmentere datagrammet (af hensyn til ældre protokoller, der ikke understøtter fragmentering), og det indeholder desuden et slutmærke for det sidste fragment.
Time to live (TTL):
Et tal på mellem 0 og 255, der angiver hvor lang tid datagrammet kan blive på nettet, inden det afvises (slås ihjel). Talværdien reduceres, hvergang datagrammet ankommer til en router. Hvis værdien bliver 0, afvises datagrammet af routeren, og det er derved tabt. Selve talværdien kan fortolkes på flere måder, afhængig af hvilken routing protokol der anvendes. Nogle routere opfatter TTL, som det antal hop fra router til router, som datagrammet stadig må foretage, inden det slås ihjel. Andre routere opfatter TTL som datagrammets levetid målt i sekunder. Formålet med TTL er at begrænse trafikken på nettet, dvs. congestion control.
Protocol:
Angiver den ovenliggende protokol, som datagrammet skal afleveres til (TCP, UDP, ICMP eller en transportprotokol fra en anden netværksarkitektur, f.eks. OSI).
Header checksum:
Anvendes til fejlkontrol. IP foretager således kun fejlkontrol på datagrammets header. I tilfælde af fejl afvises datagrammet, så snart fejlen er konstateret.
Options:
I dette felt kan der angives yderligere oplysninger om datagrammet. Disse oplysninger kan anvendes af andre protokoller i forbindelse med routing eller sikkerhed. F.eks. er det muligt at angive, hvilken rute datagrammet skal følge fra afsenderen frem til den endelige destination. Denne form for routing kaldes source routing. Fordelen ved source routing er, at routerne i nettet ikke behøver at have egne routing tabeller, da de kan se i datagrammets options felt, hvilken udgående linie datagrammet skal sendes videre på. Ulempen er, at alle hosts skal kende nettets topologi for at kunne angive en rute. Derfor er source routing kun egnet til forholdsvis små net, og det anvendes sjældent i praksis.
Padding:
Dette felt skal blot sikre, at længden af datagrammets header bliver et multiplum af 32 bit. Indeholder datagrammets header ingen options, er der ikke behov for padding.
3.1.2. IP routing
Når der ikke anvendes source routing, bliver datagrammets rute fra afsenderen til den endelige destination ikke fastlagt af en enkelt computer. Hver computer (den sendende host og de routere der passeres undervejs) vælger kun det næste hop ved at slå op i en routing tabel og finde en passende udgående linie. Denne form for routing er langt den mest almindelige. Der kan anvendes enten statisk eller adaptiv routing. Ved statisk routing fastlægges routing tabellerne af den netværksansvarlige, når nettet installeres, og en senere ændring af routing tabellerne som følge af, at nettes topologi er blevet ændret, kræver manuelle indgreb. Ved adaptiv routing, opdateres routing tabellerne automatisk, hvis nettets topologi eller trafikken på nettet ændrer sig.
Den indbyggede routing funktion i IP er statisk, mens de dedikerede routing protokoller anvender adaptiv routing. Da statisk routing kræver manuel vedligeholdelse af routing tabellerne, anvender routere i langt de fleste tilfælde dedikerede routing protokoller, mens det er mere almindeligt, at hosts benytter den indbyggede routing funktion i IP. Grunden til sidstnævnte er, at hosts normalt kun har forbindelse til en enkelt router. Dette betyder, at de blot skal kunne tage stilling til, om modtageren findes på samme lokalnet eller på et andet. Hvis modtageren findes på samme lokalnet, adresserer en sendende host såvel ramme som datagram direkte til modtageren. Hvis modtageren ikke findes på samme lokalnet, adresseres rammen til routeren og datagrammet til den endelige destination. Routeren vil da modtage rammen, pakke datagrammet ud af rammen ved at fjerne rammens kontrolinformation, kigge på modtageradressen i datagrammet og slå op i sin routing tabel for at finde en passende udgående linie.
3.2. Hjælpeprotokoller
Hjælpeprotokollerne varetager nogle funtioner, der ikke findes i IP, men alligevel er nødvendige i mange tilfælde. Der findes 3 hjælpeprotokoller: Address Resolution Protocol (ARP), Reverse Address Resolution Protocol (RARP) og Internet Control Message Protocol (ICMP).
3.2.1. Address Resolution Protocol
ARP gør det muligt at finde MAC-adressen for en computer i et lokalnet, når dens IP-adresse er kendt. Når der skal sendes fra en computer i et lokalnet (host eller router) til en anden computer i samme lokalnet, skal rammerne indeholde MAC-adresser på afsender og modtager, mens pakkerne skal indeholde IP-adresser på afsender og modtager. Den sendende computer kender altid IP-adresserne på de computere i lokalnettet, som den kan sende til (dette er en del af computerens konfiguration), mens den ikke nødvendigvis kender deres MAC-adresser. Hver computer i lokalnettet indeholder en tabel i RAM-lageret, kaldet ARP-cache, der indeholder MAC-adresser på andre computere i lokalnettet sammen med deres IP-adresser. Når en computer skal sende til en anden computer i lokalnettet, slår den op i sin ARP-cache for at finde modtagerens MAC-adresse. Findes modtagerens MAC-adresse ikke i ARP-cachen, benytter den sendende computer ARP til at finde MAC-adressen. Når MAC-adressen er fundet, indsættes den i ARP-cachen. En computers ARP-cache er tom, når computeren tændes (da den ligger i RAM-lageret), og den bygges op efterhånden, hver gang der bliver behov for en ny MAC-adresse. Grunden til at man har valgt at placere ARP-cachen i RAM lageret og ikke permanent på computerens harddisk er, at et lokalnets tilstand mht. hvilke computere, der er slukket og tændt, er meget varierende.
Når en computers MAC-adresse skal findes vha. ARP, sker der følgende:
1) den computer, der ønsker at finde en anden computers MAC-adresse, rundspreder en ARP-pakke på lokalnettet, indeholdende IP-adressen på den computer, hvis MAC-adresse ønskes fundet (rundspredning på et lokalnet sker ved at der indsættes en speciel MAC-modtageradresse i rammen, der angiver at rammen skal modtages af alle computere).
2) alle computere på lokalnettet modtager ARP-pakken og undersøger den.
3) den computer, der har den IP-adresse, der er angivet som modtageradresse i ARP-pakken, sender en ARP-pakke tilbage til afsenderen indeholdende den forespurgte MAC-adresse.
4) den computer, der forespurgte MAC-adressen har nu fået et svar, og den lagrer den fundne MAC-adresse i sin ARP-cache.
En computer, der har forbindelse til flere lokalnet (typisk en router), indeholder et netværkskort og ARP-modul (dvs. en kørende ARP-protokol og -cache) for hvert lokalnet, den har forbindelse til.
3.2.2. Reverse Address Resolution Protocol
RARP benyttes, når der skal tildeles en midlertidig IP-adresse til en computer i lokalnet. For at RARP kan fungere kræves der en RARP server. Denne server er ansvarlig for tildeling af midlertidige IP-adresser. Når en computer ønsker en midlertidig IP-adresse, sker der følgende:
1) computeren rundspreder en RARP-pakke på lokalnettet, indeholdende computerens MAC-adresse (rundspredning er nødvendig, fordi en diskløs PC ikke kender adressen på RARP serveren).
2) RARP serveren modtager ligesom alle andre computere RARP-pakken, hvorefter den sender en RARP-pakke tilbage til den afsenderen indeholdende en midlertidig IP-adresse (forudsat der er flere ledige IP-adresser til rådighed på det pågældende tidspunkt).
3.2.3. Internet Control message Protocol
ICMP benyttes til at udveksle kontrolinformation mellem computere på nettet, herunder især status- og fejlinformation. ICMP kan bl.a. benyttes til
• at undersøge om en bestemt computer er tilgængelig (denne funktion benyttes af PING kommandoen)
• at måle transmissionsforsinkelsen mellem 2 hosts vha. tidsmærker
• at give besked til en host, der forsøger at sende data til en anden host, som ikke findes
• at give en host besked på skrue ned for blusset, hvis den sender datagrammer for ofte (congestion control)
• at give en host besked på, at et datagram blev slået ihjel, fordi der var fejl i checsummen ,eller fordi datagrammets levetid (TTL) udløb, eller fordi routeren ikke havde ledig bufferkapacitet til at håndtere datagrammet
• at foreslå en host at benytte en anden router, hvis dette medfører en kortere vej til den endelige destination (en host kan kun modtage denne meddelelse, hvis den har forbindelse til flere routere, og den har ingen glæde af meddelelsen, medmindre den anvender en dedikeret routing protokol, så den er i stand til selv at opdatere sin routing tabel)
ICMP har ikke sit eget pakkeformat, ligesom ARP og RARP. I stedet indsættes en ICMP-meddelelse i datafeltet i en IP-pakke (datagram).
3.3. Dedikerede routing protokoller.
Som nævnt tidligere i denne note anvender de dedikerede routing protokoller adaptiv routing, hvor routing tabellerne opdateres automatisk, hvis nettets topologi eller trafikken på nettet ændrer sig. Opdateringen sker ved at routerne løbende udveksler information. Der 2 findes former for adaptive routing - Distance-Vector-Routing og Link-State-Routing. Distance-Vector-Routing er den simpleste form, idet routerne kun udveksler information med sine naboroutere. Ved Link-State-Routing, som er den bedste metode, udveksler routerne information med alle andre routere i netværket. I adaptiv routing skal routing tabellerne foruden de oplysninger, der er vist i figur 7, indeholde oplysning om afstanden til den endelige destinations netværk. En router benytter denne afstand til at vurdere, om den skal opdatere sin routing tabel, når den modtager information fra en anden router. Afstanden kan angives på flere måder, afhængig af hvilken routing protokol, der benyttes. De to mest almindelige måder at angive afstanden på er
1) det antal routere (hop), der skal passeres, for at nå den endelige destination
2) den tid det vil tage at nå den endelige destination
Der er en grænse for, hvor mange routere der kan være i et netværk, hvis adaptiv routing skal fungere. Derfor er Internet opdelt i mange mindre netværk, kaldet autonome systemer. Et autonomt system består af et eller flere regional- og backbone net, og det er kendetegnet ved at
• det administreres af enkelt organisation (typisk en Internet udbyder eller en større offentlig eller privat organisation)
• alle routere internt i det autonome system anvender samme routing protokol (dette er nødvendigt, da routerne ellers ikke ville kunne forstå den information, som de udveksler med hinanden)
Som følge af opdelingen i autonome systemer findes der to typer routere - nemlig routere der opererer internt i et autonomt system, og routere der har forbindelse til andre autonome systemer. Den førstnævnte type kaldes Interior Gateway, mens den sidstnævnte kaldes Exterior Gateway. Routing protokoller er ligeledes opdelt i to grupper - Interior Gateway Protokoller og Exterior Gateway Protokoller, hvor førstnævnte betegner routing protokoller der kan anvendes internt i autonome systemer, og sidstnævnte betegner routing protokoller der kan anvendes af eksterne routere (exterior gateways). Exterior Gateway protokoller er mere komplekse end Interior Gateway protokoller, da de skal være mere fleksible (to eksterne routere skal bl.a. kunne aftale, om de overhovedet vil snakke sammen, og hvilken type information de vil udveksle).
4. Transportlaget
I transportlaget findes der to protokoller - Transmission Control Protocol (TCP) der er forbindelsesafhængig, og User Datagram Protocol der er forbindelsesuafhængig. Disse to protokoller behandles i det følgende.
4.1. Transmission Control Protocol
Da TCP er forbindelsesafhængig, er de vigtigste to funktioner fejlhåndtering og flowkontrol. Fejlhåndtering består i, at en dataenhed retransmitteres, hvis der ikke indenfor rimelig tid ankommer en bekræftelse fra modtageren på, at dataenheden er modtaget korrekt. Flowkontrol består i, at data modtages af applikationsprotokollen ved modtageren i samme rækkefølge, som de blev afsendt af applikationsprotokollen ved senderen. Desuden sikrer flowkontrol, at senderen ikke sender data hurtigere, end modtageren er i stand til håndtere. Fejlhåndtering og flowkontrol kræver, at dataenhederne nummereres.
Når en dataenhed sendes, starter den sendende hosts TCP-protokol en timer. Hvis timeren udløber (timeout), inden der ankommer bekræftelse på, at dataenheden er modtaget korrekt, retransmitteres dataenheden. Da trafikintensiteten på nettet er varierende, er timerens udløbstid ikke fast men justeres ved løbende at måle transmissionsforsinkelsen frem og tilbage mellem den sendende og modtagende host. Når modtageren sender en bekræftelse, angiver den, hvor stor en datamængde der må sendes, inden der ankommer en ny bekræftelse. Det er muligt at sende en ny dataenhed, inden der er ankommet bekræftelse på en tidligere afsendt dataenhed, når blot den af modtageren fastsatte grænse for datamængde ikke overskrides. Timeout kan indtræffe, hvis dataenheden går tabt eller er fejlbehæftet. Tab af dataenheder skyldes ofte, at trafikintensiteten på nettet er meget høj (i sådanne situationer kan pakker afvises af routere eller deres levetid kan udløbe). Derfor bliver en tabt eller fejlbehæftet dataenhed retransmitteret i flere mindre enheder således, at der for hver transmission ventes på en bekræftelse, inden den næste af disse enheder sendes. Dette vil mindske trafikintensiteten på nettet, og TCP bidrager således også til congestion control.
Den modtagende hosts TCP protokol har til opgave at sende bekræftelser på korrekt modtagne dataenheder, i hvilken forbindelse den også fortæller senderen, hvor stor en datamængde der må sendes næste gang. Protokollen skal ligeledes sørge for, at korrekt modtagne dataenheder afleveres til applikationslaget i den rigtige rækkefølge, uden at der forekommer duplikater. Duplikater kan opstå ved, at en korrekt modtaget dataenhed retransmitteres af senderen, fordi bekræftelsen ikke nåede frem i tide. Bemærk at der kun sendes en bekræftelse, hvis den modtagne dataenhed er fejlfri.
En TCP dataenhed eller bekræftelse kaldes et segment. Et segment kan indeholde data og bekræftelse samtidigt. Dette gør det muligt for en applikation at optræde som sender og modtager samtidigt, uden at der skal oprettes to TCP-forbindelser - også kaldet TCP-sessioner (en for hver retning).
4.2. User Datagram Protocol
Da UDP er forbindelsesuafhængig, er der ingen garanti for fejlfri dataoverførsel. Til gengæld kan data overføres med en meget begrænset mængde af kontrolinformation. De fleste applikationsprotokoller anvender TCP, da de har behov for garanteret fejlfri overførsel. En UDP-datahenhed kaldes et user datagram.