Internet - Gerrit Tiemens

Gerrit Tiemens,
Medewerker HCC
Locatie Arnhem
Zevenaar, 21 oktober 2004
Inhoudsopgave
Inleiding ............................................................................................................. 3
1. Netwerkprotocollen ........................................................................................ 3
1.1 De fysieke laag ............................................................................................. 4
1.1.1 MAC-adressering ..................................................................................... 5
1.1.2 De MTU .................................................................................................. 5
1.1.3 PPP ........................................................................................................ 5
1.2 Hosts en routers ........................................................................................... 5
1.3 Protocollen en interfaces ................................................................................ 6
1.4 Encapsulatie ................................................................................................. 8
1.5 Demultiplexing .............................................................................................. 9
1.6 TCP/IP en standaardisatie .............................................................................10
1.6.1 Organisaties op het gebied van Internet-technologie ...................................10
1.6.2 RFC's ....................................................................................................11
2 Het IP-protocol .............................................................................................. 12
2.1 Taken en eigenschappen van het IP-protocol ...................................................13
2.1.1 IP: een connectionless protocol ...................................................................13
2.1.2 IP: geen betrouwbaarheid geboden .............................................................13
2.2 De IP-header ...............................................................................................14
2.3 IP-adressering .............................................................................................15
2.3.1 De structuur van IP-adressen ...................................................................15
2.3.2 Notatie van IP-adressen ..........................................................................16
2.3.3 Registratie van IP-adressen .....................................................................17
2.3.4 Vrij te gebruiken: private Internets ...........................................................18
2.3.5 Speciale IP-adressen ...............................................................................18
2.4 IP-routering .................................................................................................18
2.4.1 De routeringstabel ..................................................................................18
2.5 IP: speciale diensten.....................................................................................20
2.5.1 Fragmentatie ............................................................................................20
2.6 IP-troubleshooting ........................................................................................20
2.6.1 Testen van de IP-verbinding: ping ............................................................20
2.6.2 Testen van de IP-routering: tracert ...........................................................21
2.6.3 Protocolstatistieken opvragen ...................................................................21
3 HTTP-protocol ............................................................................................... 22
3.1 Opbouwen van een sessie .............................................................................22
3.2 http: headers...............................................................................................23
Internet
Inleiding
In deze lezing gaan we aandacht besteden aan enkele protocollen die gebruikt worden in
het Internet. De volgende protocollen komen aan de orde:
 TCP/IP
Dit staat voor Transmission Control Protocol / Internet Protocol en zijn twee
netwerkprotocollen. Netwerkprotocollen zijn gedragsregels/afspraken met
betrekking tot het versturen en ontvangen van gegevens via netwerken.
 HTTP
Dit staat voor Hypertext Transfer Protocol. HTTP maakt het mogelijk om op een
relatief eenvoudige manier multimedia bestanden bruikbaar te maken voor het
Internet, zoals tekst, foto's, geluid en video.
1. Netwerkprotocollen
Computers in een netwerk gebruiken netwerkprotocollen: afspraken over de vorm en
betekenis van boodschappen (pakketten) die op het netwerk uitgewisseld worden. Novell
NetWare bijvoorbeeld, dat hier en daar in de PC-wereld nog gebruikt wordt, is gebaseerd
op protocollen met de naam SPX/IPX. In het Internet gebruikt men de TCP/IPprotocollen. De TCP/IP-protocollen hebben de laatste jaren een enorme opmars
gemaakt: ook binnen organisatie- en bedrijfsnetwerken overvleugelt TCP/IP
langzamerhand de andere netwerktechnologieën. Men gebruikt zelfs IP om
telefoongesprekken te transporteren (Voice over IP).
Netwerkprotocollen zijn in een aantal functionele niveaus (lagen) opgesplitst, waarbij
elke laag zijn eigen specifieke functie heeft. Door het opsplitsen in lagen met elk een
deelfunctie wordt de netwerksoftware als geheel beheerbaar en overzichtelijk.
Het totaal aan lagen wordt een protocol-suite of protocol-stack of kortweg stack
genoemd. In figuur 1 is de TCP/IP protocol-stack getoond. De taakverdeling van de lagen
in de TCP/IP-stack is ruwweg als volgt:



De fysieke laag zorgt voor het fysieke transport over het netwerkmedium (de
hardware). TCP/IP kan over elk willekeurig fysiek medium gebruikt worden:
Ethernet, FDDI, Frame Relay, ATM, WiFi, satellietverbindingen, seriële lijnen,
enzovoort.
De netwerklaag zorgt onder andere voor de routering: het vinden van een route
van de afzender naar de bestemming. In hoofdstuk 2 gaan we in op het protocol
dat in het Internet gebruikt wordt op netwerklaag-niveau: het IP-protocol.
De transportlaag zorgt voor de communicatie tussen processen: dit in
tegenstelling tot de netwerklaag, die zorgt voor de communicatie tussen
machines. In de TCP/IP-suite zijn er twee transportprotocollen: TCP en UDP. Elke
applicatie is ofwel gebouwd op het TCP-protocol, ofwel op het UDP-protocol. TCP
en UDP hebben volstrekt verschillende karakteristieken. Kort samengevat komt
het er op neer dat TCP volledige garanties biedt met betrekking tot de juiste
aankomst van pakketten, terwijl UDP dergelijke zekerheden niet biedt.
Een applicatie die steunt op TCP kan dus verzekerd zijn van een foutvrije
verbinding, terwijl een UDP-gebaseerde toepassing dat niet kan zijn. Het lijkt
misschien alsof applicaties dus maar beter altijd TCP als transportprotocol kunnen
kiezen, maar zo eenvoudig ligt dat niet: het nadeel van TCP is namelijk een
relatief grote overhead. Toepassingen zoals telefonie en videoconferencing via het
Internet, waarbij snelheid belangrijker is dan 100% foutvrije transmissie, zijn dan
ook vrijwel zonder uitzondering op UDP gebouwd.
Voorbeelden van bekende op TCP gebouwde toepassingen zijn FTP (het File
blz. 3

Transfer Protocol), HTTP (het Hypertext Transfer Protocol waar het Web op is
gebouwd) en SMTP (het Simple Mail Transfer Protocol, dat gebruikt wordt voor
transport van emailberichten over het Internet). Voorbeelden van bekende op
UDP gebouwde toepassingen zijn RealAudio (distributie van geluid), CU-SeeMe en
NetMeeting (conferencing).
In de applicatielaag bevinden zich de toepassingen: electronic mail, filetransfer,
remote login, enzovoort. De meeste Internet-toepassingen hebben een clientserver structuur. Vaak speelt de client de rol van informatieafnemer en de server
de rol van informatie-aanbieder. Een voorbeeld vormt een Web-server: deze biedt
informatie aan (een homepage en andere Web-pagina's) die door een Web-client
(een browser) benaderd kan worden.
Applicatielaag
Transportlaag:
procesadressering via
poortnummers
Netwerklaag:
adressering, routering
Fysieke laag:
datatransport over een
fysiek netwerk
Figuur 1
1.1 De fysieke laag
We zullen ons in deze lezing nauwelijks bezighouden met de fysieke laag. TCP/IP kan
gebruikt worden in combinatie met welk fysiek netwerk dan ook, zonder dat daarbij veel
kennis van de laag-niveau eigenschappen van dit fysieke netwerk nodig is. Hieronder
noemen we toch een paar belangrijke zaken.
blz. 4
1.1.1 MAC-adressering
Bij gebruik van TCP/IP in een LAN krijgt men bijvoorbeeld te maken met Ethernet, tokenring of FDDI. Dergelijke LAN-netwerken kennen een eigen adressering om aan te duiden
voor welk station (systeem) een bepaald pakket is bestemd. Deze zogenaamde MAC(Media Access Layer ) adressen zijn 48 of 64 bits lang en hebben niets te maken met de
adressen die op IP-niveau worden gebruikt. Een speciaal MAC-adres is het broadcastadres. Een pakket dat als bestemming het broadcast-adres heeft, komt aan bij alle
systemen op het lokale netwerk. Het MAC broadcast-adres bestaat uit (48 of 64) bits die
allemaal op 1 staan.
Netwerkkaarten halen pakketten van het netwerk die ofwel het MAC-adres van het eigen
systeem als bestemming hebben, ofwel gericht zijn aan het broadcast-adres. Er is nog
een derde mogelijkheid, die te maken heeft met het versturen van pakketten naar
groepen van machines. Deze techniek wordt multicasting genoemd. Ten slotte kunnen
veel netwerkkaarten ook in promiscuous mode opereren, wat wil zeggen dat ze alle
pakketten (ongeacht de bestemming) van het netwerk halen. Deze mogelijkheid wordt
gebruikt door netwerk-sniffers: programma's die het netwerkverkeer afluisteren en door
beheerders vaak toegepast worden bij het oplossen van problemen. Overigens zijn
netwerk-sniffers ook populair gereedschap van hackers die vertrouwelijke informatie
zoals wachtwoorden willen afluisteren tijdens het transport over een netwerk.
Voor beginnende netwerkbeheerders kan het verwarrend zijn dat elke computer op een
LAN twee adressen heeft: een IP-adres dat een rol speelt op IP-niveau en een MAC-adres
dat alleen binnen het eigen LAN gebruikt wordt.
Er is een speciaal protocol voor het leggen van de koppeling tussen een IP-adres en het
bijbehorende MAC-adres: het ARP-protocol.
1.1.2 De MTU
Een van de karakteristieken van fysieke netwerken is de zogenaamde Maximal
Transmission Unit (MTU). De MTU van een netwerk is de maximale grootte die een over
dat netwerk reizend frame (een pakket op MAC-niveau wordt een frame genoemd) mag
hebben. Een Ethernet heeft bijvoorbeeld een MTU van 1500 bytes, een FDDI-netwerk
van 4352 bytes en een X.25-netwerk van 576 bytes. Een seriële verbinding (bijvoorbeeld
een telefoonlijn) heeft geen inherent maximum aan de pakketgrootte, maar afhankelijk
van de situatie kunnen er toch redenen zijn om de pakketgrootte ook voor deze
netwerken niet al te hoog in te stellen.
1.1.3 PPP
Bij gebruik van TCP/IP over een telefoonlijn, ISDN-verbinding, ADSL, huurlijn of
andersoortige punt-naar-punt verbinding wordt PPP gebruikt voor het inpakken van IPpakketten. Het PPP-protocol moet men dus zien op het niveau van de fysieke laag.
1.2 Hosts en routers
Het Internet is een wereldwijd netwerk van netwerken. In een dergelijk netwerk is een
speciale rol weggelegd voor de systemen die de netwerken met elkaar verbinden. Deze
worden routers genoemd. Elk netwerk bestaat uit een aantal `gewone' machines (deze
worden hosts genoemd) en uit een of meer routers die de verbindingen met andere
netwerken verzorgen.
Een boodschap die verstuurd moet worden van een host naar een andere host maakt een
reis door het Internet en passeert daarbij onderweg de routers van een aantal
tussenliggende netwerken. Als bijvoorbeeld een boodschap verstuurd wordt van host A in
figuur 2 naar host E, zou deze boodschap de route A-R1-R3-R2-E volgen.
blz. 5
Als router wordt meestal speciaal daarvoor gemaakte hardware gebruikt. Bekende
leveranciers van dat soort routers zijn onder meer Cisco en 3COM.
Daarnaast kan echter ook een UNIX- of Windows systeem met twee of meer
netwerkkaarten als router fungeren. Men noemt een dergelijk systeem met meerdere
netwerk-interfaces ook wel een multihomed host.
Het voordeel van een multihomed host als router is een relatief lage prijs, het nadeel is
echter dat een dergelijk `general-purpose' systeem niet dezelfde performance kan
bieden als een commerciële router. Daarnaast is het zo dat commerciële routers allerlei
extra's bieden die general-purpose systemen vaak ontberen.
Figuur 2
Voorbeelden zijn ondersteuning voor meerdere protocol suites (TCP/IP, DECnet, SPX/IPX,
NetBEUI, enzovoort) en de mogelijkheid van beveiliging via packet _ltering. Dat laatste
wil zeggen dat het bij gebruik van moderne routers mogelijk is om pakketten selectief te
filteren, op grond van allerlei beveiligingscriteria. Een router tussen een bedrijfsnetwerk
en het Internet zou bijvoorbeeld inkomende telnet- en ftp-sessies kunnen verbieden,
maar tegelijk uitgaande telnet- en ftp-sessies kunnen toestaan.
1.3 Protocollen en interfaces
Hierboven is al het begrip protocol genoemd. Een protocol is een set van afspraken over
de vorm en betekenis van boodschappen (pakketten) die op het netwerk uitgewisseld
worden. Op elke laag in de protocol-suite zijn aparte protocollen in gebruik. Bij clientserver verkeer spelen dan ook verschillende protocollen een rol, zoals in figuur 3 wordt
getoond. In dit voorbeeld benadert een Netscape-gebruiker een Web-server. In de figuur
wordt aangenomen dat de Web-server zich in het lokale (Ethernet-)netwerk bevindt. De
tekening verandert nauwelijks als dit niet het geval is: er komen alleen een aantal
tussenstappen bij.
blz. 6
Figuur 3
In figuur 3 spelen de volgende protocollen een rol:




Op applicatieniveau wordt HTTP (het Hypertext Transfer Protocol) gebruikt. Het
HTTP-protocol bevat onder meer operaties om Web-pagina's op te vragen bij een
Web-server.
Op transportniveau wordt gebruikgemaakt van het TCP-protocol: het HTTPprotocol is gebouwd op TCP.
Op netwerkniveau wordt gebruikgemaakt van het IP-protocol.
Op fysiek niveau wordt gebruikt gemaakt van het Ethernet-protocol.
Merk op dat alleen op het laagste niveau werkelijk sprake is van fysieke communicatie:
op de andere niveaus is er een `virtuele communicatie'. De browser Netscape in figuur 3
heeft de illusie van een verbinding met de Webserver, maar in werkelijkheid
communiceert hij niet direct met de Web-server: hij overhandigt de boodschap aan de
TCP-laag op het eigen systeem. Deze zal de boodschap inpakken in een TCP-pakket en
overhandigen aan de IP-laag op het eigen systeem. De IP-laag verpakt het IP-pakket in
een Ethernet-frame en overhandigt het aan de fysieke laag, waarna het uiteindelijk op de
kabel kan worden gezet. Bij aankomst op de machine waar de Web-server draait maakt
het pakket een soortgelijke reis door de protocol-suite, maar dan `van onder naar
boven'.
Bij het bovenstaande is het begrip interface van belang. Een interface legt de interactie
tussen twee aangrenzende lagen vast. Van belang is vooral het interface tussen de
applicatielaag en de transportlaag: dit bepaalt de netwerkoperaties die applicaties
kunnen uitvoeren. Deze interface is een API (Application Programmers Interface) die
vastlegt welke netwerk-functies programmeurs tot hun beschikking hebben. De
meestgebruikte en bekendste API is de socket-API. Deze bevat onder meer de volgende
functies:
 Een functie connect om een verbinding met een bepaalde server op een bepaalde
computer op te zetten. Deze functie wordt aangeroepen door een client.
blz. 7


Een functie accept om te wachten op binnenkomende connectieverzoeken. Deze
functie wordt aangeroepen door een server.
Functies voor het versturen en ontvangen van netwerk-pakketten over een
opgebouwde verbinding, zoals recvfrom en sendto.
De onderste drie lagen in figuur 3 zitten in het besturingssysteem. De socket-API vormt
dus de grens tussen het besturingssysteem en de toepassingen.
Een speciale faciliteit die het socket interface biedt is de mogelijkheid om vanuit de
applicatie rechtstreeks in te grijpen op TCP/UDP- en IP-niveau en in detail de protocolheaders in te vullen. Men noemt deze raw sockets. Het raw socket interface biedt
interessante mogelijkheden voor het testen van nieuwe protocollen en toepassingen,
maar wordt helaas ook nogal eens misbruikt door hackers: deze sturen dan met opzet
gecorrumpeerde IP-pakketten naar systemen, in de hoop dat deze systemen daardoor in
de war raken en crashen. Er zijn veel voorbeelden van dergelijke denial-of-service
aanvallen, zoals land, teardrop, smurf , de Ping `O Death en TCP SYN-flooding.
1.4 Encapsulatie
In de vorige paragraaf is aan de hand van figuur 3 beschreven hoe de reis van een
pakket van browser naar Web-server er uit ziet:



Eerst reist het pakket van boven naar beneden door de eigen protocollagen:
HTTP, TCP, IP, driver.
Dan volgt de fysieke reis over het netwerk.
Na aankomst op de computer van de Web-server reist het pakket van beneden
naar boven door de protocollagen: driver, IP, TCP, HTTP.
In deze paragraaf gaan we in op wat er tijdens deze reis gebeurt met het datapakket: dit
blijft namelijk niet onveranderd.
Elk protocol houdt controle-informatie bij in een eigen protocol-header of kortweg
header. Bij de reis van boven naar beneden door de protocollagen worden dus steeds
headers toegevoegd (zie figuur 4). Dit wordt encapsulatie genoemd.
Figuur 4
blz. 8
Na aankomst op de doelmachine worden de diverse headers er weer een voor een
afgestript. De IP-module bijvoorbeeld zal de IP-header verwerken, deze er af strippen, en
het overgebleven pakket (TCP-header en applicatie-data) aan de TCP-laag overhandigen.
1.5 Demultiplexing
In de vorige paragraaf is beschreven hoe een pakket, na aankomst op de doelmachine,
de reis naar boven door de protocollagen aflegt en hoe daarbij headers gestript worden.
Daarbij blijft echter nog een vraag over: hoe weet een module voor welke hoger gelegen
module een bepaald pakket is bedoeld? Er zijn immers verschillende situaties waarin er
meerdere mogelijkheden zijn (zie figuur 5).



Een Ethernet-pakket kan een IP-pakket bevatten, maar kan bijvoorbeeld ook een
SPX/IPX- of een NetBEUI-pakket bevatten. Zelfs wanneer alleen TCP/IP gebruikt
wordt zijn er op dit niveau nog meerdere mogelijkheden.
Een IP-pakket kan een TCP-pakket bevatten, maar kan ook een UDP-pakket
bevatten. De IP-module moet het pakket dus ofwel aan de TCP-, ofwel aan de
UDP-module doorspelen.
Een TCP-pakket kan bedoeld zijn voor vele toepassingen, bijvoorbeeld voor de
Web-server, voor de email-server of voor de ftp-server.
De oplossing voor deze problemen is eenvoudig. Elke header bevat onder meer een getal
dat aangeeft voor welke hogere protocollaag het pakket bedoeld is. In de volgende
paragraaf zullen we zien dat dit soort nummers uitgedeeld wordt door een speciaal
daartoe bevoegde organisatie (ICANN).
Een paar voorbeelden om het bovenstaande toe te lichten:




In de Ethernet-header staat het getal 0800 (hexadecimaal) als het Ethernetpakket een IP-pakket bevat en 0806 als het een ARP-pakket bevat.
In de IP-header staat het getal 17 als het IP-pakket een UDP-pakket bevat en 6
als het een TCP-pakket bevat.
In de TCP-header staat het getal 80 als het TCP-pakket bedoeld is voor de Webserver, 25 als het voor de email-server bestemd is en 21 als het aan de ftp-server
is gericht.
Deze `applicatie-nummers' worden poortnummers genoemd.
Het op basis van deze getallen in de header bepalen voor welke hogere protocollaag een
pakket bedoeld is noemt men demultiplexing.
blz. 9
Figuur 5
1.6 TCP/IP en standaardisatie
De TCP/IP-protocollen en de daarop gebouwde toepassingen zijn open: de specificaties
zijn openbaar en vrij verkrijgbaar. Het gevolg is dat elke leverancier die dat wil een
implementatie van TCP/IP-protocollen en –toepassingen kan bouwen. Dit heeft ertoe
geleid dat TCP/IP beschikbaar is voor vrijwel elk type computer. De meeste moderne
systemen zijn standaard voorzien van TCP/IP-faciliteiten: dat geldt bijvoorbeeld voor
allerlei Windows versies, MacOS en alle UNIX-varianten. Vanwege de algemene
beschikbaarheid van TCP/IP bestaat het Internet dan ook uit een bonte verzameling van
computers in alle soorten en maten: IBM-mainframes, UNIX-werkstations, PC’s met
Windows of Linux, Macintoshes, VAX/VMS-systemen, supercomputers, enzovoort.
De ontwikkeling van de TCP/IP-protocollen en -toepassingen staat niet stil: voortdurend
worden er nieuwe toepassingen bedacht en worden bestaande toepassingen verbeterd of
uitgebreid met nieuwe mogelijkheden. Met name het Web is erg in beweging: J2EE,
.NET, allerlei Web-applicaties. In deze paragraaf beschrijven we hoe deze ontwikkelingen
gecoördineerd worden.
1.6.1 Organisaties op het gebied van Internet-technologie
De ontwikkeling en standaardisatie van nieuwe techniek is in handen van de Internet
Architecture Board (IAB). Onder IAB vallen drie organisaties (zie figuur 6):
Figuur 6
blz. 10



De Internet Research Task Force (IRTF) houdt zich bezig met langetermijn
research op het gebied van Internet-technologie.
De Internet Engineering Task Force (IETF, zie www.ietf.org) houdt zich bezig met
de ontwikkeling van nieuwe technologie en protocollen.
De Internet Engineering Steering Group (IESG) is eindverantwoordelijk voor het
vastleggen van nieuwe Internet-standaarden.
IETF heeft een aantal algemene aandachtsgebieden, waaronder bijvoorbeeld routering,
security, de volgende generatie van het IP-protocol, enzovoort.
Voor elk aandachtsgebied is een aantal werkgroepen actief, die zich bezighouden met
onderdelen van het aandachtsgebied. Alle IETF-werkgroepen zijn open, met
vertegenwoordigers uit het internationale bedrijfsleven en de internationale academische
wereld als leden. Men moet zich IAB, IETF en IRTF overigens niet voorstellen als een
`echte' organisatie met een kantoorgebouw en medewerkers: het overgrote deel van de
activiteiten in de werkgroepen vindt plaats via Internet, middels discussies in mailinglists.
Een andere belangrijke organisatie is de Internet Corporation for Assigned Names and
Numbers (ICANN) Deze is eindverantwoordelijk voor het uitdelen van domeinnamen, IPadressen en protocol-parameters in het Internet.
De nummers in figuur 2.5 zijn bijvoorbeeld onder verantwoordelijkheid van ICANN
uitgedeeld. Overigens werd het werk van ICANN voorheen uitgevoerd door de Internet
Assigned Numbers Authority (IANA).
1.6.2 RFC's
Alle door IETF-werkgroepen vastgelegde specificaties van protocollen en toepassingen
zijn openbaar en worden beschreven in zogenaamde RFC's (Request For Comments).
Deze documenten zijn op te halen vanaf diverse ftp-servers, bijvoorbeeld:
ftp://ftp.ripe.net/rfc/
Bekende RFC's zijn onder meer RFC 791 (specificaties van het IP-protocol), RFC 793
(specificaties van TCP) en RFC 768 (specificaties van UDP). Andere bekende RFC's zijn de
host requirements (RFC 1122 en 1123) en de router requirements (RFC 1812). In de
genoemde directory staat overigens ook een bestand rfc-index.txt met een
inhoudsopgave van alle RFC's.
Niet alle RFC's betreffen standaarden. Er zijn ook vele informatieve RFC’s en RFC's die als
een soort discussiestukken dienen: vandaar ook de naam `Request For Comments'.
Verder zijn er ook 1 april grappen zoals RFC 3541 i.The Security Flag in the IPv4
Headerly. Standaarden `in wording' worden overigens beschreven in andere documenten
die men Internet drafts noemt.
Een RFC wordt na publicatie nooit meer veranderd. Als wijzigingen of uitbreidingen
gewenst zijn, wordt een nieuwe RFC met een nieuw nummer gepubliceerd. In de rfcindex wordt dit aangegeven. Als voorbeeld volgt hierna de lijst van RFC's die betrekking
hebben op het routeringsprotocol OSPF, dat aanvankelijk werd vastgelegd in RFC 1131
en daarna werd aangepast in achtereenvolgens RFC 1247, RFC 1583, RFC 2178 en ten
slotte RFC 2328.
blz. 11
De meeste RFC's bevatten op verschillende plaatsen de kwalificaties MUST, SHOULD en
MAY. Dit zijn richtlijnen voor implementaties: MUST geeft aan wat verplicht is, SHOULD
wat sterk aanbevolen wordt en MAY wat optioneel is. Een voorbeeld (uit RFC 1123) is:
Mailer software MUST be able to send and receive messages of at least 64K bytes in
length (including header), and a much larger maximum size is highly desirable.
Hier staat dus dat emailberichten tot 64 Kilobytes lengte door alle emailproducten altijd
goed afgehandeld moeten worden, maar dat het afhandelen van grotere berichten niet
verplicht is (hoewel dit wel `highly desirable' is – in feite een SHOULD).
Een tweede voorbeeld (ook uit RFC 1123) heeft betrekking op de maximale lengte van
machinenamen:
Host software MUST handle host names of up to 63 characters and SHOULD handle host
names of up to 255 characters.
Het is goed om het verschil tussen een protocol en een implementatie te benadrukken.
RFC's bevatten beschrijvingen van protocollen en geven daarbij via MUST, SHOULD en
MAY de bewegingsvrijheid van implementaties aan. In dit verband zijn ook de volgende
begrippen van belang:


Een implementatie wordt unconditionally compliant genoemd als deze in alle
MUST- en SHOULD-clausules voorziet.
Een implementatie wordt conditionally compliant genoemd als deze in alle MUSTclausules voorziet, maar niet in alle SHOULD-clausules.
Hoewel RFC's geen wettelijke status hebben en men geen proces kan aanspannen tegen
een leverancier van een product als dit zich niet aan de RFC's houdt, doen leveranciers
over het algemeen erg hun best om producten te bouwen die zich houden aan de RFC's
en liefst zelfs unconditionally compliant zijn.
De volgende RFC's zijn speciaal het vermelden waard (zie figuur 2.2 voor een toelichting
op de begrippen `host' en `router'):
RFC 1812 staat bekend als de router requirements RFC. Deze bevat een overzicht van de
regels waar (de software van) routers aan moet voldoen. Er staat bijvoorbeeld in welke
protocollen en welke onderdelen van protocollen routers verplicht moeten ondersteunen.
RFC 1122 en RFC 1123 staan bekend als de host requirements RFC's. Deze bevatten een
overzicht van de regels waar (de software van) hosts aan moet voldoen.
In het bovenstaande zijn diverse bijzondere RFC's genoemd. Onderstaande tabel bevat
een samenvatting van een aantal RFC's die speciaal de moeite waard zijn.
RFC-nummer
1122
1123
1812
1700
1718
2700
Inhoud
Host requirements (deel 1)
Host requirements (deel 2)
Router requirements
Assigned Numbers
Uitleg Internet standaardisatieorganen: IAB, IETF, IRTF, etc
Overzicht van officiële Internet-standaarden
2 Het IP-protocol
In dit hoofdstuk gaan we in op het protocol dat op netwerklaag-niveau wordt gebruikt in
de TCP/IP-stack: het Internet Protocol (IP). Naast het bespreken van de basis (IP-
blz. 12
adressering en IP-routering) gaan we ook in op geavanceerdere en modernere zaken
zoals multicasting, CIDR en IP versie 6. We gaan in op de techniek: de werking van de
protocollen, de vorm van de adressen, enzovoort.
2.1 Taken en eigenschappen van het IP-protocol
De belangrijkste taken van het IP-protocol (RFC 791) zijn routering (het vinden van een
route van afzender naar bestemming) en adressering (de nummering van machines in
het netwerk).
De belangrijkste eigenschappen van het IP-protocol zijn dat het connectionless is en geen
garanties biedt. We lichten deze termen hieronder toe.
2.1.1 IP: een connectionless protocol
Met connectionless wordt bedoeld dat IP niet werkt met vaste netwerkverbindingen
tussen de afzender en de bestemming. Elk IP-pakket reist onafhankelijk van de vorige en
de volgende, en het is dan ook mogelijk dat verschillende pakketten in één en dezelfde
sessie (bijvoorbeeld een ftp-sessie) verschillende routes nemen. IP-routering is `hop-byhop': elke host en router hoeft slechts de volgende stap op weg naar de bestemming te
weten en niet het volledige pad naar de bestemming.
Het grote voordeel van een connectionless protocol is de flexibiliteit. Als er een router in
het netwerk uitvalt kan een andere route worden gezocht en kunnen alle toepassingen
gewoon blijven doordraaien. Een van de redenen waarom men bewust heeft gekozen
voor een connectionless protocol is dat men een zeer robuust netwerk op het oog had,
dat onder meer voor militaire toepassingen bedoeld was. Toepassingen moesten onder
alle omstandigheden blijven doorwerken, zelfs in situaties waarin netwerkcomponenten
(bijvoorbeeld door militaire acties) weg zouden vallen.
In een connection-oriented netwerk (zoals het telefonie-netwerk) wordt een vast `pad'
tussen twee partijen opgebouwd (geswitched) voordat datatransport plaatsvindt.
Voordelen zijn dat de snelheid na de opbouwfase wat groter is (omdat geen route meer
gezocht hoeft te worden) en dat er een stuk capaciteit gereserveerd wordt. Het nadeel is
echter dat de verbinding als geheel verbroken wordt als er een probleem is met één
enkele switch onderweg.
2.1.2 IP: geen betrouwbaarheid geboden
IP is een onbetrouwbaar protocol: het behoort niet tot de taken van IP om foutcontroles
uit te voeren. IP onderneemt bijvoorbeeld geen actie wanneer verstuurde IP-pakketten
niet aankomen door congestie (drukte) op het netwerk of wanneer pakketten in een
verkeerde volgorde aankomen. IP wordt een `best-effort' protocol genoemd: het doet
zijn best, maar maakt zich niet druk om mogelijke optredende problemen. Foutcontroles
moeten, als ze gewenst zijn, plaatsvinden op een hoger niveau. Dat hogere niveau is in
de praktijk meestal het TCP-protocol.
Bij het ontwerp van IP is bewust gekozen voor een onbetrouwbaar protocol. De filosofie
daarbij was onder meer dat applicaties zélf moeten kunnen beslissen welke mate van
betrouwbaarheid ze krijgen. Toepassingen voor videoconferencing en telefonie over het
Internet zijn gebouwd op UDP en kunnen razendsnel werken door de relatief geringe
overhead van deze protocollen. Toepassingen voor file-transfer zijn gebouwd op TCP/IP
en zijn verzekerd van een foutvrije transmissie, maar wel ten koste van een grotere
overhead.
Als de netwerklaag garanties zou bieden, zouden applicaties de keus tussen
betrouwbaarheid en snelheid niet meer kunnen maken.
blz. 13
2.2 De IP-header
Het is illustratief om de IP-header te bekijken. Deze is in figuur 7 weergegeven. Een
toelichting bij de diverse velden in de header:
Figuur 7






De huidige versie is 4. In de komende jaren zal geleidelijk aan ook IP versie 6 in
gebruik genomen worden.
De hdr len is de lengte van de IP-header, uitgedrukt in eenheden van 4 bytes. De
IP-header is normaal gesproken 20 bytes lang, maar door de mogelijkheid van IPopties (zie hieronder) kan dit meer zijn. Het veld hdr len is slechts 4 bits, zodat de
maximale lengte van de IP-header 15 (maximale waarde van een 4-bits getal)
maal 4 (de eenheid van hdr len) bytes, dus 60 bytes is. Er is dus maximaal plaats
voor 40 bytes aan IP-opties.
Het veld TOS (Type Of Service) bevat een paar bits die bedoeld zijn om aan te
geven op welke manier het IP-pakket verwerkt moet worden: onder meer het bit
minimize delay en het bit maximize reliability. Het idee is dat het eerste bit gezet
wordt door applicaties waarbij het vooral om snelheid gaat (bijvoorbeeld
interactieve applicaties) en het tweede door applicaties waarbij het vooral om
betrouwbaarheid gaat (bijvoorbeeld een applicatie voor netwerk-management).
Hoewel er enkele implementaties zijn die de bits zetten voor verstuurde IPpakketten, wordt een en ander in de praktijk maar beperkt gebruikt. Het zetten
van de bits heeft alleen zin als alle routers `meewerken' door de bits te
inspecteren en dienovereenkomstig te handelen. Dat is echter niet het geval:
vrijwel alle routers negeren de TOS-bits.
De totale lengte is de lengte van het IP-pakket in bytes, inclusief de data.
De velden identificatie, flags en fragment offset worden gebruikt voor
fragmentatie.
De TTL (Time To Live) is de maximale levensduur van een IP-pakket. Elke router
waar een pakket passeert zal 1 aftrekken van dit getal. Als het getal 0 is
geworden, wordt het pakket weggegooid en wordt een foutboodschap
blz. 14




teruggestuurd naar de afzender van het pakket. Het is afhankelijk van de
implementatie op welke waarde de TTL geïnitialiseerd wordt. Waarden die we in
de praktijk vaak tegenkomen zijn 32, 64 en (de maximale waarde) 255.
Het veld protocol wordt gebruikt voor demultiplexing. Hier staat bijvoorbeeld het
getal 6 voor een TCP-pakket en 17 voor een UDP-pakket.
De header checksum is een controlegetal over de IP-header zelf, niet over de
data. De integriteit van de databytes moet gecontroleerd worden door een hogere
protocollaag (zoals TCP of UDP).
IP-adres van afzender en IP-adres van bestemming geven aan wie het pakket
verzonden heeft en voor wie het bestemd is.
IP kent een aantal opties. De bekendste IP-opties hebben te maken met source
routing.
2.3 IP-adressering
In figuur 7 zagen we dat in elk IP-pakket het IP-adres van de afzender en dat van de
bestemming is opgenomen. Een IP-adres is een nummer dat dient als identificatie van
een computer. Elke computer in het Internet heeft een IP-adres.
2.3.1 De structuur van IP-adressen
IP-adressen zijn getallen met een lengte van 32 bits. Deze 32 bits zijn verdeeld in twee
stukken: een netwerknummer en een machinenummer. Dit betekent dat alle netwerken
in het Internet genummerd zijn en dat de computers binnen een netwerk ook een
nummer hebben. Twee computers die in hetzelfde netwerk zitten hebben hetzelfde
netwerknummer en moeten verschillende machinenummers hebben. Twee computers in
verschillende netwerken mogen hetzelfde machinenummer hebben, maar hebben een
verschillend netwerknummer. De opdeling is te vergelijken met die van
telefoonnummers. Ook deze bestaan uit twee delen, te weten een netnummer en een
abonneenummer. Twee personen mogen hetzelfde abonneenummer hebben, als het
netnummer dan maar verschillend is.
Een gevolg van de opdeling in een netwerknummer en een machinenummer is dat IProutering gebaseerd kan worden op het netwerknummer: om een IP-pakket af te leveren
bij de bestemming hoeft alleen bekend te zijn hoe het bestemmings-netwerk bereikt kan
worden. Is het pakket eenmaal in het juiste netwerk aangekomen, dan wordt het
vervolgens vanzelf bij de juiste machine afgeleverd.
De verdeling van de 32 bits in een netwerkgedeelte en een machinegedeelte is niet vast.
Er zijn drie soorten IP-adressen:
 Klasse-A adressen
 Klasse-B adressen
 Klasse-C adressen
Klasse-A
eerste bit = 0 + 7 bits = netwerk id. + 24 bits = host id.
Klasse-A adressen bestaan uit 7 bits voor het netwerknummer en 24 bits voor het
machinenummer. Er zijn dus maar heel weinig Klasse-A netwerken (128), maar van elk
van deze kan zeer veel machines bevatten (2 tot de macht 24 = 16.777.216).
Klasse-B
eerste 2 bit = 10 + 14 bits = netwerk id. + 16 bits = host id.
blz. 15
Klasse-B adressen bestaan uit 14 bits voor het netwerknummer en 16 bits voor het
machinenummer. Er zijn dus 16.384 klasse-B netwerken (2 tot de macht 14), waarbij
elke klasse-B netwerk 2 tot de macht 16 machines (65.536) kan bevatten.
Klasse-C
eerste 3 bit = 110 + 21 bits = netwerk id + 8 bits=hostid.
Klasse-C adressen bestaan uit 21 bits voor het netwerknummer en 8 bits voor het
machinenummer. Klasse-C netwerken kunnen dus niet groot worden (256 machines),
maar er zijn er wel veel van (2 tot de macht 21 = 2.097.152)
Het voordeel van deze variabele verdeling in netwerkgedeelte en machinegedeelte is een
grotere flexibiliteit. Stel dat de verdeling vast zou zijn, bijvoorbeeld 16 bits voor het
netwerknummer en 16 bits voor het machinenummer. Dan zouden er maximaal zo’n
65.000 netwerken kunnen voorkomen in het Internet, wat duidelijk te weinig is voor het
Internet. Of stel dat verdeeld zou zijn in 24 bits voor het netwerknummer en 8 bits voor
het machinenummer, dan zou geen enkel netwerk meer dan 256 machines kunnen
bevatten.
Overigens is deze flexibiliteit in werkelijkheid maar beperkt. Het verschil tussen
bijvoorbeeld een klasse-B en een klasse-C netwerk is levensgroot. Daarom wordt
tegenwoordig dan ook gewerkt met klasseloze IP-adressering, een techniek die bekend
staat onder de naam CIDR.
Naast klasse-A, klasse-B en klasse-C adressen zijn er ook nog klasse-D en klasse-E
adressen. Klasse-D adressen beginnen met de bits 1110 en zijn bedoeld voor
multicasting. Klasse-E adressen beginnen met de bits 11110 en zijn bedoeld voor
experimentele doeleinden.
2.3.2 Notatie van IP-adressen
Zoals gezegd bestaan IP-adressen uit 32 bits. Een nummer als
10100011110000000100000010011110
is echter niet praktisch in gebruik. Daarom worden IP-adressen meestal op en andere
manier weergegeven in de zogenaamde dotted decimal notatie. In deze notatie worden
IP-adressen genoteerd als vier getallen met punten ertussen.
Voor het eerste groepje van 8 bits uit bovenstaand IP-adres:
10100011
is de decimale waarde bijvoorbeeld:
1*2^7 = 128
0*2^6 = 0
1*2^5 = 32
0*2^4 = 0
blz. 16
0*2^3
0*2^2
1*2^1
1*2^0

=
=
=
=
0
0
2
1
= 163
De getallen kunnen dus alleen waarden aannemen tussen de 0 en 255.
Enkele andere voorbeelden van IP-adressen in dotted decimal notatie:
131.174.22.56 (klasse-B)
192.84.30.66 (klasse-C)
19.2.23.7 (klasse-A)
Aan het eerste van de vier decimale getallen in een IP-adres is direct te zien of het een
klasse-A, klasse-B of klasse-C adres is.
Klasse
A
B
C
Gebied
0-127
128-191
192-223
Aantal netwerken
128
16.384
2.097.152
2.3.3 Registratie van IP-adressen
Elke machine en elke router op het Internet heeft een of meerdere IP-adressen. Het
spreekt vanzelf dat IP-adressen niet dubbel mogen voorkomen. Daarom moet een
particulier of een organisatie die zich op het Internet aansluit een officieel IP-adres
aanvragen. Eindverantwoordelijke voor het uitdelen van IP-adressen is de organisatie
ICANN (Internet Corporation for Assigned Names and Numbers). Omdat het echter te
veel werk zou zijn om de registratie van IP-adressen voor de hele wereld af te handelen,
heeft ICANN dit werk gedelegeerd aan enkele organisaties die de verantwoordelijkheid
voor een bepaalde regio hebben, de zogenaamde Regional Internet Registries. ICANN
heeft elke Internet Registry voorzien van blokken IP-adressen die het mag uitdelen in de
eigen regio. Er zijn verschillende Internet Registries, w.o.:

RIPE (www.ripe.net), gevestigd te Amsterdam. Deze is verantwoordelijk voor
Europa, het Midden-Oosten en Noord-Afrika;

ARIN is verantwoordelijk voor Noord- en Zuid-Amerika en Zuid-Afrika;

APNIC is verantwoordelijk voor Azië
In de praktijk kan het aanvragen van IP-adressen meestal via de ISP worden geregeld,
omdat RIPE deze verantwoordelijkheid verder gedelegeerd heeft door blokken van IPadessen uit te delen aan Internet Service Providers (de zogenaamde Local Internet
Registries). De delegatie van blokken IP-adressen van ICANN via bijvoorbeeld RIPE en de
ISP naar de klant verloopt via de systematiek van CIDR.
Een organisatie die een bedrijfsnetwerk aansluit op het Internet krijgt overigens alleen
een IP-netwerknummer. Men is uiteraard vrij om diverse machines binnen het netwerk
zelf te nummeren. Iets preciezer is overigens om te zeggen dat men geen
netwerknummer, maar een netwerk-prefix krijgt.
Organisaties die geen Internetkoppeling hebben en ook niet van plan zijn, moeten zich
realiseren dat het later alsnog koppelen van het bedrijfsnetwerk aan het Internet
gepaard zal gaan met een mogelijk complexe en tijdrovende hernummeringsoperatie.
Om de pijn van een eventuele latere hernummering te verzachten kan men
gebruikmaken van de speciale adressen.
blz. 17
2.3.4 Vrij te gebruiken: private Internets
ICANN heeft enkele series adressen gereserveerd voor wat men private Internets noemt.
Het betreft de volgende adressen:
10.0.0.0 tot en met 10.255.255.255
172.16.0.0. tot en met 172.31.255.255
192.168.0.0 tot en met 192.168.255.255
Deze gebieden kunnen vrijelijk gebruikt worden door elke organisatie die dat wil. Er
kunnen nooit botsingen of misverstanden ontstaan, omdat deze adressen op het
Internet niet gerouteerd worden. Het gevolg is dus wel dat systemen die van dergelijke
adressen voorzien zijn, geen rechtstreekse connectiviteit met het Internet kunnen
hebben.
2.3.5 Speciale IP-adressen
Er zijn een tweetal speciale IP-adressen:
Het netwerk 127 is het zogenaamde loopback-netwerk. De meeste implementaties
gebruiken van dit netwerk alleen het adres 127.0.0.1. Dit adres is het loopback-adres,
dat staat voor eigen systeem. Het kan bijvoorbeeld gebruikt worden om servers te
benaderen die op het eigen systeem draaien.
Het IP-adres 0.0.0.0 staat, wanneer het als afzendadres gebruikt wordt, voor ‘de eigen
machine’. Het mag uitsluitend gebruikt worden in boot-situaties: als het systeem nog niet
weet wat zijn IP-adres is (omdat hij dat nog te weten moet komen van een boot-server)
maar al wel een IP-pakket moet versturen (bijvoorbeeld een broodkastpakket met
bestemming 255.255.255.255), mag 0.0.0.0 als afzendadres invullen.
Het adres 0.0.0.0 is geen geldig bestemmingsadres. Het wordt echter in veel
implementaties wel gebruikt om de default route aan te geven.
2.4 IP-routering
Een boodschap die verstuurd moet worden van een host naar een andere host maakt een
reis door het Internet en passeert daarbij onderweg de routers van een aantal
tussenliggende netwerken.
Een router die een pakket binnenkrijgt moet een beslissing nemen:
 Ligt de bestemming van het pakket op een direct verbonden netwerk? Zo ja, lever
het pakket dan af bij de bestemming
 Zo nee, stuur het pakket dan door naar de router van een ander netwerk dat
dichter bij de uiteindelijke bestemming ligt.
Het nemen van dit soort beslissingen wordt routering genoemd. Vandaar dat men die
systemen die het werk doen routers noemt. Routering vindt plaats op het niveau van de
netwerklaag en is een van de belangrijkste taken van het IP-protocol.
2.4.1 De routeringstabel
Routeringsbeslissingen worden genomen op basis van de routeringstabel. De
routeringstabel is een stuk boekhouding waarin staat hoe andere hosts en netwerken
bereikt kunnen worden. Er zijn vier soorten routes die in routeringstabellen kunnen
voorkomen:
Directe routes: Deze corresponderen met de netwerken waarmee een systeem
rechtstreeks is verbonden.
Netwerk-routes: deze geven voor een bepaald netwerk aan wat de volgende stap op weg
naar dat netwerk is.
Hosts-routes: deze geven voor een bepaalde host aan wat de volgende stap op weg naar
die host is.
blz. 18
Een default route. Als een host of router niet weet hoe een bepaalde bestemming bereikt
kan worden (er is geen directe, host- of netwerk-route voor de bestemming), wordt de
default route gebruikt. De default route bestaat doorgaans uit een ‘slimmer’systeem dat
wel raad zal weten met het pakket. Dit slimmere systeem wordt de default router of
default gateweay of soms kortweg gateway genoemd.
Het is goed om te benadrukken dat elk systeem dat TCP/IP gebruikt een routeringstabel
heeft, dus niet alleen de routers. Hosts moeten immers ook routeringsbeslissingen
nemen. Met name moeten ze het onderscheid kunnen maken tussen pakketten die op
het lokale netwerk afgeleverd moeten worden en pakketten die naar een router moeten
worden gestuurd. Omdat routers verbindingen met meerdere netwerken hebben, zijn
hun routeringstabellen natuurlijk wel uitgebreider dan die van hosts. Routers hebben
verstand van netwerk-topologie, terwijl een host dat nauwelijks hoeft te hebben.
In de routeringstabel staat voor elke bestemming alleen de volgende stap op weg naar
de bestemming en dus niet de complete route naar de bestemming.
Het opvragen van de routeringstabel in Windows gaat met het commando netstat -r of
met het commando route print. Beide commando’s moeten vanuit de DOS-shell worden
aangeroepen. Het systeem waarop dit commando gegeven werd, zoals aangegeven in
onderstaand schermafdruk, heeft het IP-adres 169.254.188.87.
Figuur 8
Een toelichting bij de uitvoer:





Network Address is de bestemming van de route.
Gateway Address is de volgende stap op weg naar die bestemming. Voor een
bestemming die lokaal is (een netwerk waar het systeem zelf aan gekoppeld is)
staat daar het eigen IP-adres op dat netwerk.
Netmask is het netwerkmasker dat bij de bestemming hoort. Het geeft aan of de
bestemming (het Network Address) een host is, een netwerk, of een subnet.
Interface is het IP-adres van het netwerk-interface waarover de route loopt.
Metric is het aantal stappen dat de bestemming van ons vandaan ligt. Deze wordt
alleen gebruikt bij dynamische routering met RIP.
blz. 19
2.5 IP: speciale diensten
De belangrijkste taken van het IP-protocol zijn adressering en routering. Daarnaast
voorziet IP echter ook in enkel andere diensten, waaronder fragmentatie.
2.5.1 Fragmentatie
Een IP-pakket dat een reis maakt over het Internet kan onderweg door vele netwerken
passeren. Een probleem wat daarbij kan optreden is dat elke fysiek netwerk zijn eigen
karakteristieken heeft met betrekking tot de maximale pakketgrootte. De maximale
pakketgrootte in een ethernet is 1500 bytes, terwijl dat voor een x.25-netwerk 576 bytes
is en voor een FDDI-netwerk 4352 bytes. Men noemt dit de maximale pakketgrootte van
een netwerk de MTU (Maximum Transmission Unit).
Stel nu dat een IP-pakket een reis begint op een ethernet en 1500 bytes groot is, en dat
het vervolgens door een x.25-netwerk moet passeren. Dan moet het in kleinere stukjes
worden opgeknipt. Dit noemt men fragmentatie. Het omgekeerde proces – het weer aan
elkaar plakken van de stukjes – heet defragmentatie. Fragmentatie en defragmentatie
behoren tot het takenpakket van IP. In de IP-header (zie figuur 7) hebben enkele velden
te maken met fragmentatie. Een IP-pakket dat opgeknipt is in meerdere fragmenten
heeft in elk fragment dezelfde identificatie. De fragmet offset geeft de positie binnen het
totale pakket aan. Een van de bits in het veld flags geeft aan of er nog meer fragmenten
komen of dat dit het laatste fragment is. Dit bit wordt meestal aangeduid als MF (van
More Fragments).
Fragmentatie is een dure operatie. Nog los van al het knip- en plakwerk is dat te wijten
aan het feit dat alle fragmenten opnieuw verstuurd moeten worden als er eentje verloren
raakt in het netwerk. Als één fragment verloren gaat, kan het IP-pakket waartoe het
behoorde immers niet meer gereconstrueerd worden. Moderne TCP/IP-implementaties
proberen daarom fragmentatie te voorkomen door de pad-MTU uit te rekenen: de grootst
mogelijke pakketgrootte warbij fragmentatie toch niet nodig is.
2.6 IP-troubleshooting
Er zijn vele hulpmiddelen om de correcte werking van een IP-netwerk te testen en om de
oorzaak van eventuele problemen te traceren.
2.6.1 Testen van de IP-verbinding: ping
Het commando ping is een eenvoudig hulpmiddel om te testen of een bepaalde computer
op IP-niveau bereikbaar is. Dit commando stuurt zogenaamde ICMP echo request
pakketten naar de bestemming, waarop als alles goed gaat ICMP echo reply pakketten
terug moeten komen.
Het programma dient vanuit de DOS-shell aangeroepen te worden. Bij het commando
ping www.gtiemens.nl zou het resultaat er als volgt uit kunnen zien:
Pingen naar www.gtiemens.nl [212.78.206.150] met 32 byte gegevens:
Antwoord
Antwoord
Antwoord
Antwoord
van
van
van
van
212.78.206.150:
212.78.206.150:
212.78.206.150:
212.78.206.150:
bytes=32
bytes=32
bytes=32
bytes=32
tijd=169
tijd=231
tijd=190
tijd=165
ms
ms
ms
ms
TTL=50
TTL=50
TTL=50
TTL=50
Ping-statistieken voor 212.78.206.150:
Pakketten: verzonden = 4, ontvangen = 4, verloren = 0
(0% verlies).De gemiddelde tijd voor het uitvoeren van één bewerking in
milliseconden:
Minimum = 165ms, Maximum = 231ms, Gemiddelde = 188ms
blz. 20
2.6.2 Testen van de IP-routering: tracert
Er is een programma waarmee de reis die pakketten door het Internet maken in beeld
kan worden gebracht. Dit programma heet tracert en dient eveneens vanuit de DOS-shell
aangeroepen te worden.
Bij het commando tracert www.gtiemens.nl, zou het resultaat er als volgt uit kunnen
zien:
Bezig met het traceren van de route naar www.gtiemens.nl [212.78.206.150]
via maximaal 30 hops:
1 222 ms 118 ms
2 124 ms 119 ms
3 134 ms 134 ms
4 180 ms 218 ms
5 144 ms 144 ms
6 160 ms 177 ms
7 140 ms 138 ms
8 128 ms 150 ms
[193.251.132.89]
9 259 ms 261 ms
[193.251.242.46]
10 213 ms 196 ms
[193.251.240.134]
11 181 ms 216 ms
12 174 ms 185 ms
13 156 ms 169 ms
124
118
140
184
140
219
146
140
*
ms
ms
ms
ms
ms
ms
ms
ms
pm31.hobby.nl [212.72.224.5]
l3gw.hobby.nl [212.72.224.1]
level3-gw.hobby.nl [212.72.224.129]
ae-0-52.mp2.Amsterdam1.Level3.net [213.244.165.34]
so-2-0-0.mp1.Frankfurt1.Level3.net [212.187.128.93]
ge-1-2.core1.Frankfurt1.Level3.net [195.122.136.101]
FT-Level3.Level3.net [212.73.240.186]
So1-0-0.FFTCR1.Frankfurt.opentransit.net
P1-0.COPBB2.Copenhagen.opentransit.net
154 ms TelefonicaDeutschland-4.GW.opentransit.net
200 ms pos5-0.sto-1.lycos-europe.net [213.193.31.6]
193 ms rdist1-v113.lan.spray.net [212.78.192.86]
181 ms customers.webc.lyceu.net [212.78.206.150]
De trace is voltooid.
2.6.3 Protocolstatistieken opvragen
Met het commando netstat –s kunt u een aantal laag-niveau protocolstatistieken
opvragen.
Het programma dient vanuit de DOS-shell worden aangeroepen.
Bij het commando netstat –s, zou het resultaat er als volgt uit kunnen zien:
Statistieken voor IPv4
Ontvangen pakketten
Ontvangen headerfouten
Ontvangen adresfouten
Doorgestuurde datagrammen
Onbekende ontvangen protocollen
Geweigerde ontvangen pakketten
Afgeleverde ontvangen pakketten
Uitvoeropdrachten
Routeringsweigeringen
Geweigerde uitvoerpakketten
Ontvangen pakket zonder route
Opnieuw samenvoegen nodig
Opnieuw samenvoegen geslaagd
Opnieuw samenvoegen mislukt
Datagrammen met geslaagde fragmentatie
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
2770
0
26
0
0
16
2754
2422
0
2
0
0
0
0
0
blz. 21
Datagrammen met mislukte fragmentatie
Fragmenten gemaakt
=0
=0
ICMPv4-statistieken
Berichten
Fouten
Doel onbereikbaar
Tijd verstreken
Parameterproblemen
Bron gedoofd
Omleidingen
Echo's
Antwoorden op echo's
Tijdstempels
Antwoorden op tijdstempels
Adresmasks
Antwoorden op adresmasks
Ontvangen
305
0
6
244
0
0
0
4
51
0
0
0
0
Verzonden
332
0
6
0
0
0
0
322
4
0
0
0
0
TCP-statistieken voor IPv4
Actief open
Passief open
Mislukte verbindingspogingen
Opnieuw ingestelde verbindingen
Actieve verbindingen
Ontvangen segmenten
Verzonden segmenten
Opnieuw verzonden segmenten
=28
=4
=0
= 21
=1
= 506
= 419
= 88
UDP-statistieken voor IPv4
Ontvangen datagrammen
Geen poorten
Fouten bij ontvangen
Verzonden datagrammen
=
=
=
=
1543
694
0
1571
3 HTTP-protocol
De communicatie tussen browser en Web-server (Client-server communicatie) verloopt
via het HTTP-protocol (HyperText Transfer Protocol). In situaties waarin vertrouwelijke
informatie (bijvoorbeeld vertrouwelijke documenten of creditcardnummer) over het Web
verstuurd moeten worden, kunt u gebruik maken van de SSL-technologie. Deze zorgt
voor encryptie van het datatransport en voor authenticatie van client en server. Wanneer
http gecombineerd wordt met de SSL-techniek, spreekt men van HTTPS (HTTP Secure).
3.1 Opbouwen van een sessie
Voor een goed begrip van de Webtechnologie is een inzicht in het HTTP-protocol
onontbeerlijk.

De client stuurt een HTTP-commando naar de Web-server. Meestal is dat het
commando GET, wanneer een Webpagina wordt opgevraagd, bijvoorbeeld
http://www.hccnet.nl. Wanneer de browser de homepage wil opvragen, zou de
blz. 22




operatie er als volgt uit zien: GET / HTTP/1.1.
De aanduiding HTTP/1.1 geeft aan welke protocolversie gewenst is.
Na het commando stuurt de browser ook nog een aantal HTTP-headers naar de
Web-browser. Via deze headers wordt de aanvullende informatie over de browser
en over het verzoek doorgegeven aan de Web-server. Een voorbeeld is de UserAgent:-header, die aangeeft wat de gebruikte browser is.
De eerste regel in het antwoord van de Web-server bevat een statuscode. Als de
code is 200, wil dat zeggen dat de operatie succesvol verlopen is.
De volgende regels bevatten HTTP-headers met controle-informatie die door de
Web-server aan de browser wordt meegestuurd. Een voorbeeld is de Server:header, welke aangeeft wat de gebruikte Web-server is. Een ander voorbeeld is
de Content-Type:-header, die aangeeft welke type informatie de Web-server
opstuurt. Dat gaat via een MIME1-type. In veel gevallen zal dat text/html zijn (het
MIME-type voor HTML-documenten), maar een Web-server kan ook heel
andersoortige informatie opsturen: plaatjes, Worddocumenten, multimediainformatie enzovoorts.
De HTTP-headers worden afgesloten door een lege regel. Dan volgt de feitelijk
gevraagde informatie.
Samenvattend:
Een HTTP client-server transactie verloopt als volgt:
 De gebruiker selecteert een hypertext-link
 De browser neemt contact op met de server op TCP (Transmission Control
Protocol) poortnummer 80 en doet een HTTP GET-operatie.
 De server retourneert het gevraagde document (of een foutboodschap).
 De browser presenteert het document.
 De gebruiker selecteert weer een hyperlink
 Enzovoort.
Een belangrijke opmerking hierbij is de volgende. Documenten bevatten geen plaatjes,
maar een verwijzing naar plaatjes (middels de <img scr = …> tag). Een browser die een
document heeft opgehaald en ziet dat er plaatjes in staan, moet deze via aparte GEToperaties ophalen. Voor een HTML-document met 10 plaatjes worden dus 11 GEToperaties gedaan. Iets soortgelijks geldt ook voor Java-applets, ActiveX-controls en
andere objecten.
Naast GET-operaties kent het http-protocol nog een aantal andere operaties. Een ervan
is de POST-operatie. Deze dient voor het versturen van ingevulde formulieren. Het
ingevulde formulier wordt dan als data meegestuurd door de browser aan de webserver.
3.2 http: headers
Alle vragen van een browser en alle antwoorden van een Web-server zijn voorzien van
headers. Deze headers worden genoteerd in RFC 822-formaat en afgesloten met een lege
regel.
Hieronder volgen een aantal headers die een client kan gebruiken in een vraag (request)
aan de server.


1
De If-Modified-Since:-header kan gebruikt worden om een conditionele GET te
doen, d.w.z. het document wordt alleen opgehaald als het veranderd is na een
bepaald tijdstip. De belangrijkste toepassing van deze header is caching van
documenten in browsers en proxy-servers.
De User-Agent:-header bevat een aanduiding van de gebruikte browser.
MIME = Multipurpose Internet Mail Extensions
blz. 23

De Referer:-header bevat de URL van de pagina van waaruit werd verwezen naar
het huidige document. Dat kan nuttig zijn om te bestuderen via welke externe
ingangen Webpagina’s bezocht worden.
De server kan in zijn antwoord (response) onder andere de volgende headers gebruiken.





De Content-Type:-header geeft aan wat het MIME-type is van het geretourneerde
document.
De Content-Length:-header geeft aan hoe groot (in bytes) het document is
(waarbij de headers-bytes niet meetellen).
De Last-Modified:-header geeft aan wanneer het document voor het laatst
veranderd is. Deze informatie kan in een later stadium gebruikt worden bij een
GET die met If-Modified-Since: conditioneel is gemaakt.
De Expires:-header geeft aan wanneer de data in het document ongeldig wordt.
Dit is bedoeld voor het beïnvloeden van de caching in browsers en proxy-servers.
De Server:-header geeft aan wat de gebruikte Web-server is, bijvoorbeeld Apache
of IIS.
De eerste regel van het antwoord van de server geeft de statuscode weer. Deze code
geeft aan of het verzoek wel of niet succesvol afgehandeld kon worden en wat de
oorzaak is van eventuele problemen.
In onderstaand overzicht zijn de belangrijkste statuscodes samengevat.
Statuscode
200
204
301
304
401
403
404
500
503
Betekenis
Operatie succesvol uitgevoerd
Operatie succesvol uitgevoerd, client krijgt geen nieuwe pagina.
URL van het document is veranderd (Nieuwe URL in Location:-header)
Client deed een If-Modified-Since en het document is onveranderd.
Client is niet geautoriseerd voor gevraagde operatie.
Gevraagde operatie is verboden.
Gevraagde document bestaat niet.
Interne fout opgetreden in server (mogelijk configuratiefout).
Server niet in momenteel niet in staat verzoek af te handelen, mogelijk
door te hoge belasting.
blz. 24