een korte basis cursus internet

			Tips Home
		*Sambar Server Tips en Trucs !*

IP, een korte basis cursus internet .
De basis van het Internet wordt gevormd door het Internet Protocol (IP). In de hierop volgende basis cursus komen de volgende onderwerpen aan de orde:
Inleiding.
Per onderdeel dat in de opvolgende hoofdstukken beschreven wordt, zijn komplete boeken geschreven. Het is dan ook niet de bedoeling alle facetten te belichten, maar een basis idee te geven hoe IP werkt en wat je er mee kunt. Dit zal wellicht ook een beter idee geven over waarom iets niet werkt.

Het OSI model.
Als we kijken naar de basis van communicatie protocollen en willen begrijpen hoe IP werkt, dan zullen we een begrip moeten hebben hoe protocollen opgebouwd zijn.
Kijken we naar de basis, dan vinden we een aantal lagen terug in de manier waarop applicaties over netwerken (maar ook binnen computers) met elkaar communiceren. Dit noemen we het OSI (Open Systems Interconnect) model. Hierbij onderscheiden we de volgende lagen:
Het OSI Model

laag 7, de applicatie laag

laag 6, de presentatie laag

laag 5, de sessie laag

laag 4, de transport laag

laag 3, de netwerk laag

laag 2, de MAC (Media Access Controll) laag

laag 1, de fysieke laag

Laag 1, het laagste nivo, kunnen we ons het best voorstellen als de fysieke hardware, met de electrische signalen, die er voor zorgen dat we hardware aan elkaar kunnen knopen. Denk hierbij bijvoorbeeld aan ethernet, tokenring, FDDI, PPP dialup verbindingen, etc.... . Als je een tokenring adapter op een ethernet netwerk probeert aan te sluiten werkt dat gewoon niet, en een ethernetkaart kun je ook niet als modem gebruiken.
Laag 2 is de Media Access Control laag, met andere woorden de laag die ervoor zorgt dat je PC maar ook bijvoorbeeld een UNIX computer via je netwerk kaart met andere stations op het netwerk kan praten.
Op laag 3 komen we het IP protocol tegen en op laag 4 de subset TCP . De overige lagen laten we hier even buiten beschouwing.
In de volgende hoofdstukken gaan we uit van een ethernet netwerk, om de systematiek en de werking van het IP protocol uit te leggen. Het leuke van het IP protocol is echter dat er voor dit protocol op alle mogelijke platformen en netwerken drivers (stukjes programma's die de communicatie mogelijk maken) te vinden zijn.

IP, adressering en netwerk klassen.
Het volgende wat we nodig hebben als voorbereiding om te communiceren is een IP adres. Het IP adres is opgebouwd uit een viertal bytes (= 32 bits) , en wordt dotted (= met puntjes tussen de bytes (= 8 bits)) decimaal uitgeschreven. Dit betekend dat er in principe 10.1.1.1 is bijvoorbeeld een IP adres, maar ook 145.82.5.254. Willen we iets meer van deze adressen weten, dan zullen we op bit niveau verder moeten denken.
Bij de uitgifte van adressen is de basis gelegd van een drietal typen netwerken, de zgn klasse A, B en C netwerken.
De netwerktypen uitgeschreven op bit niveau

1 2 3 4 Bits 12345678 90123456 78901234 56789012 Klasse A 0nnnnnnn hhhhhhhh hhhhhhhh hhhhhhhh Klasse B 10nnnnnn nnnnnnnn hhhhhhhh hhhhhhhh Klasse C 110nnnnn nnnnnnnn nnnnnnnn hhhhhhhh Klasse D 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx Klasse E 11110yyy yyyyyyyy yyyyyyyy yyyyyyyy nnn = het toegewezen netwerk deel van het nummer hhh = het vrij te gebruiken host deel xxx = speciale adressen t.b.v. multicasting yyy = gereserveerde experimental adressen Een paar voorbeelden van IP adressen 10.1.1.1 00001010 00000001 00000001 00000001 = Klasse A 145.82.5.254 10010001 01010010 00000101 11111110 = Klasse B

Uit het bovenstaande schema kun je aflezen dat het adres 10.1.1.1 een klasse A adres is, immers het begint binair met een nul en dat adres 145.82.5.254 een klasse B adres is omdat het met 10 begint. Het kennen van deze adresranges is belangrijk omdat routers (hierover later meer) met deze grenzen rekening houden in hun route tabellen.
Hoe komen we aan zo'n IP adres?
Als we onze werkstation of onze server aan willen sluiten op een bestaand netwerk, dan is het eenvoudig. We kunnen dan een adres vragen aan de beheerder van het netwerk waarop we willen aansluiten. Tegenwoordig worden dergelijke adressen veelal automatisch toegewezen. Sluiten we onze pc bijvoorbeeld via een provider aan op het internet, dan zorgt het ppp protocol bij het aanloggen op het provider netwerk dat we automatisch een adres toegewezen krijgen.
Willen we zelf een netwerk bouwen, dan hebben we een tweetal opties:

We willen een nummerplan gebruiken waarmee we direkt het internet opkunnen en/of in de toekomst kunnen connecteren aan andere netwerken. We hebben dan een officieel geregistreerd netwerkadres nodig. Binnen de huidige policy, dienen dergelijke adressen bij je ISP (Internet Service Provider) aangevraagd te worden. Kijk voor meer info op http://www.iana.org/ipadress/ip-addresses.htm . Door een gebrek aan adressen, zal dit moeilijk worden als je meer als enkele tientallen adressen nodig hebt.
Willen we niet direkt koppelen aan het internet of kunnen we niet voldoende adressen krijgen, dan kunnen we gebruik maken van zogenaamde private adressen. Dit zijn adressen die gereserveerd zijn voor gebruik binnen het eigen netwerk. We kunnen hiermee niet naar buiten communiceren, maar we voorkomen in ieder geval dat we eventueel konflikten krijgen doordat we naar een extern adres willen, dat we intern gebruiken. Hiervoor zijn de volgende adressen ter beschikking gesteld:
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Kijk voor meer info in rfc1918 o.a. te vinden op de volgende URL http://www.netwerkinformatie.com/rfc/rfc1918.txt
Ook met dergelijke adressen zijn er oplossingen te vinden uiteindelijk te connecteren naar het internet. Ze bieden in bepaalde gevallen zelfs voordelen op beveiligingsniveau.

Het gebruik van netwerkmaskers en Default gateways wordt verder besproken in het hoofdstuk "Routering, hoe werkt dat". Nu volgt eerst de basis.

De lagen 1 en 2.
Zoals we in het OSI model hebben kunnen zien, hebben we eerst een stukje "fysieke" hardware nodig om te kunnen communiceren. Dit kan een modem zijn een ethernetkaart interface (onder diverse operatingsystemen is het ook mogelijk net te doen of je een stuk hardware geïnstalleerd hebt (emuleren wordt dat genoemd). Voor de verdere uitleg gaan we uit van een ethernet, omdat dit een soort netwerk verbinding is die zeer veel gebruikt wordt en omdat we hierop mooi de gehele problematiek van het IP protocol kunnen laten zien.

Schematische weergave versturen data over ethernet
We gaan er vanuit dat station A met de server C wil communiceren. Het eerste wat er gebeurt is, is dat de stations op de tekening van een netwerk kaart en de benodigde driver software zijn voorzien. Voor het gemak gaan we er hier nog vanuit dat ons netwerk verder nergens op aangesloten is / hoeft te worden.
Wat gebeurt er nu als station A met de server C op IP niveau wil communiceren?
Op ethernet niveau hebben heeft de driversoftware, waar de pakketjes als eerste doorheen moeten, geen notie van IP adressen. Hier worden mac-adressen gebruikt. Mac-adressen zijn adressen die op ethernet bestaan uit 6 bytes, die voor de afwisseling hexidecimaal uitgeschreven worden. 00.0f.12.34.aa.bb is bijvoorbeeld een adres. Deze adressen zijn gecodeerd in de hardware en in principe wereldwijd uniek (er zijn tegenwoordig helaas fabrikanten die nummers hergebruiken). Stations zijn hierdoor op een eenduidige wijze te identificeren. Op broadcast netwerken (pakketjes op het segment worden naar alle adapters gestuurd) worden deze adressen gebruikt door de adapters om te herkennen met welk pakktje ze wel iets moeten doen en welke pakketjes genegeerd kunnen worden.
Wil station A nu pakketjes gaan sturen naar de server C, dan moet hij zien te achterhalen wat het mac-adres is van server C. Dit doen ze met het zgn. ARP (Adres Resolution Protocol) protocol. Station A zal hiertoe een pakketje sturen, met een speciaal destination (=bestemmings) mac-adres "ff.ff.ff.ff.ff.ff" en als source (zijn eigen) mac-adres het eigen adapter adres. Tevens wordt het gezochte IP adres meegestuurd. Alle stations dienen dergelijke requests te bekijken en te vergelijken met het eigen IP adres. Server C zal dit adres herkennen en een zgn ARP-response frame sturen met zijn eigen mac-adres en ip-adres. Station A zal deze data lokaal in zijn eigen ARP tabel opslaan, zodat hij die informatie in het vervolg niet meer hoeft op te zoeken. Vervolgens kan station data naar server C gaan sturen. Normaalgesproken beschikt C reeds over en ARP entry in de ARP tabel en kan deze een response direkt adresseren
Hieronder vindt je een voorbeeld van een ARP request en response frame

ARP: Request, Target IP: 172.31.249.249 FRAME: Base frame properties FRAME: Time of capture = Jun 14, 2000 15:25:50.44 FRAME: Time delta from previous physical frame: 224 milliseconds FRAME: Frame number: 63 FRAME: Total frame length: 60 bytes FRAME: Capture frame length: 60 bytes FRAME: Frame data: Number of data bytes remaining = 60 (0x003C) ETHERNET: ETYPE = 0x0806 : Protocol = ARP: Address Resolution Protocol ETHERNET: Destination address : FFFFFFFFFFFF ETHERNET: .......1 = Group address ETHERNET: ......1. = Locally administered address ETHERNET: Source address : 00600848E10F ETHERNET: .......0 = No routing information present ETHERNET: ......0. = Universally administered address ETHERNET: Frame Length : 60 (0x003C) ETHERNET: Ethernet Type : 0x0806 (ARP: Address Resolution Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 46 (0x002E) ARP_RARP: ARP: Request, Target IP: 172.31.249.249 ARP_RARP: Hardware Address Space = 1 (0x1) ARP_RARP: Protocol Address Space = 2048 (0x800) ARP_RARP: Hardware Address Length = 6 (0x6) ARP_RARP: Protocol Address Length = 4 (0x4) ARP_RARP: Opcode = 1 (0x1) ARP_RARP: Sender's Hardware Address = 00600848E10F ARP_RARP: Sender's Protocol Address = 172.31.0.36 ARP_RARP: Target's Hardware Address = 000000000000 ARP_RARP: Target's Protocol Address = 172.31.249.249 ARP_RARP: Frame Padding

ARP: Reply, Target IP: 172.31.0.36 Target Hdwr Addr: 00600848E10F FRAME: Base frame properties FRAME: Time of capture = Jun 14, 2000 15:25:50.46 FRAME: Time delta from previous physical frame: 2 milliseconds FRAME: Frame number: 64 FRAME: Total frame length: 60 bytes FRAME: Capture frame length: 60 bytes FRAME: Frame data: Number of data bytes remaining = 60 (0x003C) ETHERNET: ETYPE = 0x0806 : Protocol = ARP: Address Resolution Protocol ETHERNET: Destination address : 00600848E10F ETHERNET: .......0 = Individual address ETHERNET: ......0. = Universally administered address ETHERNET: Source address : 003080F27F76 ETHERNET: .......0 = No routing information present ETHERNET: ......0. = Universally administered address ETHERNET: Frame Length : 60 (0x003C) ETHERNET: Ethernet Type : 0x0806 (ARP: Address Resolution Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 46 (0x002E) ARP_RARP: ARP: Reply, Target IP: 172.31.0.36 Target Hdwr Addr: 00600848E10F ARP_RARP: Hardware Address Space = 1 (0x1) ARP_RARP: Protocol Address Space = 2048 (0x800) ARP_RARP: Hardware Address Length = 6 (0x6) ARP_RARP: Protocol Address Length = 4 (0x4) ARP_RARP: Opcode = 2 (0x2) ARP_RARP: Sender's Hardware Address = 003080F27F76 ARP_RARP: Sender's Protocol Address = 172.31.249.249 ARP_RARP: Target's Hardware Address = 00600848E10F ARP_RARP: Target's Protocol Address = 172.31.0.36 ARP_RARP: Frame Padding

De entries in een ARP tabel worden normaal gesproken 900 seconden bewaard, waarna indien de communicatie nog steeds actief is er weer een ARP uitgevoerd moet worden.

Routering, hoe werkt dat
Als afstanden of het aantal stations te groot worden is het beter een router functie in het netwerk te plaatsen. Daarnaast kunnen routers het verkeer ook over andere typen netwerken transporteren (wang verbindingen bijvoorbeeld) met een andere DLC laag. Een meer uitgebreide uitleg over de routeringsfunctie en wanneer we die kunnen inzetten valt hier buiten de scope van het verhaal. Hier zullen we ons primair focussen op hoe een router zijn beslissingen neemt zodat we begrijpen wat de verschillende instellingen doen.
Hoe kan een station een server vinden die zich achter een router bevindt?
Om deze vraag te beantwoorden, moeten we begrijpen hoe het samenspel tussen routers en werkstations en servers verloopt. Een van de functies van een router is er voor zorgen dat de broadcasts (o.a. voor ARP requests) zich niet door het hele netwerk kunnen verspreiden. Je kunt je voorstellen dat je PC geen tijd meer over zou houden voor normale zaken indien hij de ARP requests van alle stations op het hele internet (miljoenen pc's dus) voor zijn kiezen zou krijgen. Zo werkt het gelukkig ook niet bij een routeerbaar protocol.
Bij een routeerbaar protocol als IP hoeft een station slechts het mac-adres zijn lokale partners (op zijn eigen stukje ethernet = segment) op te zoeken en te onthouden. Bevindt degene die hij zoekt zich achter een router, dan hoeft het lokale station zijn data slechts af te leveren bij zijn "lokale" default gateway. Hij zal dus nog wel 1 ARP query uit moeten voeren om zijn default gateway te vinden. Dit samenspel vindt je schematisch terug in de volgende tekening.

Schematische weergave routering tussen 2 ethernet segmenten

Je begrijpt nu waarom je een default gateway nodig hebt om bijvoorbeeld bij de www.netwerkinformatie.com server te kunnen komen.
Hoe weet een station nu of zijn partner zich lokaal op zijn segment bevindt?
Hiervoor dient er op het station naast zijn IP-adres een netwerkmasker (een betere naam is subnetmasker) geconfigureerd te worden. Hoe werkt dit nu?
Stel we hebben te maken met werkstation 145.82.13.254, die opzoek is naar server 145.82.15.23. Bevinden deze zich op het zelfde segment?

Schematische weergave routering tussen 2 ethernet segmenten
De adressen lijken vrij aardig op elkaar, dus het zou kunnen. Toch kun je hier nog geen antwoord op geven, want je kent het subnetmaskers niet die op de werkstations gedefinieerd is. Stel het masker is voor beide stations 255.255.255.0, bevinden ze zich dan op het zelfde subnet?
Ook het subnetmasker bestaan net als het IP-adres uit een reeks binaire eenen en nullen. De positie (hoeveelheid) van de eenen bepalen het netwerk deel van het adres en het stuk van het IP-adres dat nog overblijft, de nullen laten zien welke ruimte er voor hosts (=stations) beschikbaar is op dat deel van het netwerk, verder subnet genoemd.
Nu gaan we bepalen of de bovengenoemde adressen zich op het zelfde subnet bevinden. Hiertoe dienen we de adressen en het masker binair uit te schrijven (de IP-stack vergelijkt dit immers ook op IP niveau).
Subnetmasker 255.255.255.0 11111111 11111111 11111111 00000000 De ip adressen Station A 145.82.13.254 10010001 01010010 00001101 11111110 Station B 145.82.15.23 10010001 01010010 00001111 00010111 Het bepalen van de subnetten waarop de stations zich bevinden Station A 145.82.13.254 10010001 01010010 00001101 00000000 Station B 145.82.15.23 10010001 01010010 00001111 00000000 Terug gerekend naar een decimale notering ip-adres netwerk subnet Station A 145.82.13.254 145.82.0.0 145.82.13.0 Station B 145.82.15.23 145.82.0.0 145.82.15.0
We zien dus dat de beide stations zich wel op het zelfde (klasse B) netwerk bevinden, maar ook dat de beide stations zich op verschillende subnetten bevinden. Station A moet dus verkeer via zijn default gateway naar station B sturen. Het bovenstaande voorbeeld was op het blote oog ook nog wel te herleiden, aangezien het hostdeel precies op de punt begon.
Stel dat het masker 255.255.248.0 zou zijn? Liggen de beide stations dan op het zelfde subnet. We gaan de zaak weer uitschrijven.
Subnetmasker 255.255.248.0 11111111 11111111 11111000 00000000 De ip adressen Station A 145.82.13.254 10010001 01010010 00001101 11111110 Station B 145.82.15.23 10010001 01010010 00001111 00010111 Het bepalen van de subnetten waarop de stations zich bevinden Station A 145.82.13.254 10010001 01010010 00001000 00000000 Station B 145.82.15.23 10010001 01010010 00001000 00000000 Het bepalen van het laatste adres, het zgn. local broadcast adres Station A 145.82.13.254 10010001 01010010 00001111 11111111 Station B 145.82.15.23 10010001 01010010 00001111 11111111 Terug gerekend naar een decimale notering ip-adres netwerk subnet broadcast addr Station A 145.82.13.254 145.82.0.0 145.82.8.0 145.82.15.255 Station B 145.82.15.23 145.82.0.0 145.82.8.0 145.82.15.255
Nu liggen de beide werkstations wel op het zelfde subnet. Je ziet nu ook duidelijker het nut van het binair uitschrijven van adressen om bijvoorbeeld het netwerk te bepalen en het laatste adres in dat netwerk, het broadcast adres. Het broadcast adres wordt gebruikt om bijvoorbeeld testframes, zgn. ping pakketjes, naar alle stations op dat subnet te sturen. Voor werkstations kunnen de adressen 145.82.8.1 tot en met 145.82.15.254 gebruikt worden, ruim 2000 adressen. Het volgende subnet (als we het zelfde masker zouden gebruiken, loopt van 145.82.16.0 tot en met 145.82.31.255
Hoe weet de defaultgateway (de router) nu waar hij de pakketjes van station A voor station B naar toe moet sturen?
In tegenstelling tot de overige IP-stations, beschikt een router over tabellen (de router tabellen), waar per (sub)netwerk staat opgenomen waar hij de data voor dat specifieke (sub)netwerk naar toe moet sturen (naar welk ip-adres). We gaan in de het volgende voorbeeld weer uit van het eerst gekozen subnetmasker 255.255.255.0.

De router zal hierbij de volgende stappen doorlopen:

Is het pakketje voor mij bestemd? Ook een router heeft IP-adressen en je kunt bijvoorbeeld snmp berichten naar een router sturen om bepaalde beheers informatie op te vragen. Hij kent zijn eigen interface adressen en kan dus bepalen of het pakketje voor hem zelf bestemd is. Is dit niet het geval dan gaat hij verder met de volgende stap.
Ken ik het netwerk lokaal? Is dit het geval, dan zal de router kijken of hij een ARP entry heeft voor station B in zijn ARP tabel. Is dit niet het geval, dan zal er een ARP request verstuurd worden voor het mac-adres van station B, waarna na een reply, de data verstuurd kan worden richting station B. Wat station B verder met de data doet (en of de data aankomt, dat weet de router niet, hij levert slechts een zgn. best-effort dienst.
Kent de router het netwerk echter niet lokaal, dan gaat hij verder met de volgende stap.
Heb ik een route naar het betreffende netwerk? In het eenvoudigste geval is in de configuratie van router A ingebracht (met een "route add ....." commando o.i.d.) dat het netwerk 145.82.15.0 zich ergens achter ip-node 2.1 bevindt. Kent hij het netwerk en heeft hij de laag 2 (mac) info al, dan kan hij het pakketje direkt doorsturen. In het geval van een seriële verbinding is de laag 2 verbinding in principe reeds bij het opzetten van de verbinding gemaakt.

Indien er geen specifieke route aanwezig is, is er wellicht een default route aanwezig. Deze route wordt gebruikt voor alle bestemmingen waarvoor op een andere manier geen route te vinden is.
Lukt ook dit niet, dan zal de router naar het werkstation een zgn. ICMP pakketje sturen met de informatie "netwerk unreachable", wat zoveel betekend, ik kan het netwerk niet vinden en heb het pakketje in de bittenbak gegooid.

Vervolgens worden deze stappan ook door de opvolgende routers doorlopen, totdat het netwerk gevonden is waarop station B zich bevindt.
Router A zal de data naar router B sturen, die de data weer doorstuurt naar router D. Router C krijgt het pakketje normaal gesproken nooit te zien, immers dan zou het pakketje een omweg maken.
Herroutering en de opbouw van route tabellen.
Stel nu dat de verbinding tussen router B en D uitvalt. Indien routes met de hand gedefinieerd zouden zijn, ziet router B dat hij het pakketje niet verder kan sturen richting D, hij weet echter niet dat er een alternatieve verbinding bestaat via router C. Dat is hem immers nooit vertelt.
Dit probleem is op te lossen door de routers "dynamisch" route informatie te laten uitwisselen d.m.v. een routing protocol. Dit heeft als bijkomend voordeel dat op het moment dat er een netwerk (lees interface met een ip-add en masker) aan een router wordt toegevoegd, dit niet meer op alle individuele routers gedefinieerd hoeft te worden. Afhankelijk van het gebruikte protocol kunnen vaste (overal de zelfde (bijv RIP)) of variabele (met per subnet verschillende hoeveelheden hosts (bijv OSPF)) gedefinieerd worden.

Het gebruik van DNS.
In het bovenstaande voorbeeld zijn we er steeds vanuit gegaan dat station A wist welk IP-adres station B heeft. Dit werkt als je slechts een beperkte hoeveelheid stations hebt die naar station B hoeven. Immers wil je station B verplaatsen naar een ander subnet, dan zul je alle stations die naar station B willen hiervan op de hoogte moeten stellen en zo nodig moeten herconfigureren. Misschien lukt je dat ook nog wel.
Stel station B zou in werkelijkheid de www.netwerkinformatie.com server zijn. Ik heb er geen idee van wie er allemaal een bookmark naar mijn site gemaakt hebben, dus ik kan ze ook niet informeren. Om dit probleem te voorkomen is het Domain Name System (= DNS) opgezet, waarbij een vertaalslag gemaakt wordt van namen naar IP-adressen.
Hoe werkt dit?
Aan de werkstation kant is het verhaal tamelijk eenvoudig. Door het opnemen van het IP-adres van een of meerdere dns servers, zal het werkstation automatisch het betreffende IP-adres bij de naam gaan zoeken, eerst bij de eerste DNS server en als deze niet reageert bij de tweede, totdat hij alle geconfigureerde DNS servers heeft gehad. Wil je dus gebruik maken van het World Wide Web (WWW), dan moet je een DNS server geconfigureerd hebben.

Hosts, werkstations en services.
In tegenstelling tot veel andere netwerkoperating systemen, is er bij de implementatie van IP nooit een groot verschil geweest tussen werkstations en servers. In principe wordt ieder station een host genoemd. Of die host als server of als werkstation of als beide gebruikt wordt, is aan de beheerder / gebruiker. Mede doordat het internet gebaseerd is op open standaarden, en er door vele duizenden mensen programma's geschreven zijn op alle mogelijke platformen, zowel commercieel als niet commercieel, heeft dit protocol zo'n enorme vlucht kunnen nemen. Momenteel zijn we zover dat er voor praktisch alle platformen en toepassingen IP implementaties beschikbaar zijn.

Hoe werkt dat nu?
We introduceren hier weer even het oude concept van server en werkstation. De server is de gene die de service aanbiedt, het werkstation de gene die de service wil afnemen. Dit is even tamelijk zwart-wit gesteld, in de praktijk is de scheidslijn lang niet altijd zo duidelijk te trekken. Stel ik wil een webserver en ftp server beschikbaar stellen (zodat mensen bij mij kunnen surfen en files kunnen downloaden). Hoe kan mijn "server" nou weten of iemand iets wil downloaden via FTP of komt browsen via WWW?
Protocol nummers
Kijken we naar het IP protocol, dan komen we een aantal lagen tegen. Het eerste wat je tegen komt is een source en destination IP adres. Het destination adres wordt gebruikt om het pakket te routeren, het source adres wordt door de andere partij gebruikt om het pakket weer terug te kunnen sturen. Vervolgens komen we het protocol nummer tegen.
Binnen het IP protocol zijn een aantal specifieke protocollen gedefinieerd, waarvan de protocollen tcp(6), udp(17) en icmp(1) de bekendsten zijn. (kijk op http://www.iana.org/numbers.htm voor een uptodate overzicht.
De veschillende protocollen hebben zo hun eigen eigenschappen. Zo is het ICMP protocol een puur lowlevel protocol, bedoeld voor het troubleshooten en opvragen van netwerk parameters. TCP en UDP zijn de protocollen waar we hier iets dieper opin zullen gaan.
We beginnen met UDP. Dit is het eenvoudigste protocol, omdat het een zogenaamde connectionless service levert. Connectionless wil zeggen dat het protocol geen idee heeft of het eerste, dan wel het laatste pakketje van een sessie verstuurd wordt en ook niet hoeft bij te houden of alle pakketjes wel goed bij de ontvangende kant aangekomen zijn. Dit laat het protocol allemaal over aan de hoger liggende lagen (denk nog eens terug aan het OSI model). Willen applicaties dus zeker weten of alle pakketjes netjes aangekomen zijn, dan moeten ze dit zelf controleren (vragen aan de partner aan de andere kant). Typisch toepassingen voor dit protocol zijn het uploaden van configuratie files naar devices die mogelijk onvoldoende resources hebben voor een TCP implementatie, het sturen van systeem berichten (TCP zou in dergelijke gevallen te traag dan wel te veel overhead opleveren als er slechts 1 pakketje verstuurt hoeft te worden) en een nieuwe toepassing is het gebruik bij telefonie over IP (hier heeft hertransmissie immers geen zin, dan maar een kraakje).
TCP biedt een zogenaamde connection oriented verbinding, wat wil zeggen dat het protocol voor de verbinding zorgt en daardoor garanties kan bieden zolang er een verbinding bestaat. TCP zorgt dan ook voor de nodige hertransmissie, doordat de andere zijde zgn ACK (acknowledgement) pakketjes stuurt. Daarnaast kent TCP zgn flowcontrol mechanismen, waardoor het kan anticiperen op de beschikbare bandbreedte. Als verbindingen namelijk overbelast raken, zullen er op de tussenliggende netwerken vertragingen optreden of zelfs pakketten weggegooid worden. Als bepaalde pakketten trager dan wel helemaal niet aankomen, kan de zendende kant gas terug nemen, waardoor de tussenliggende netwerken minder belast zullen worden. Als alle stations zich hier netjes aan houden, houdt de congestie (het verstopt raken van het netwerk) vanzelf op en kan er daarna langzaam weer meer data verstuurd worden.
Poortnummers.
Vervolgens worden binnen de protocollen poortnummers op de verschillende services adresseerbaar ge maakt. Deze poortnummers (ook wel sockets genoemd) worden gebruikt door de protocolstack om te bepalen naar welk programma de data gerouteerd moet worden. Programma's die luisteren op dergelijke poorten (deze worden ook wel deamons genoemd) moeten aan de TCP stack vertellen dat zij de data die op bijvoorbeeld poort 80 (= www) binnen komt doorgestuurd moet worden naar de webserver. Poort 21 daarentegen is in principe gereserveerd voor FTP verkeer. Deze poorten kun je in principe als beheerder vrij kiezen, echter voor de meeste protocolen zijn er in principe poorten gereserveerd. De cliëntapplicaties zullen deze poorten gebruiken als er verder niets anders opgegeven wordt. Kijk voor een lijst van deze poortnummers op
http://www.iana.org/assignments/port-numbers

Aan de cliëntkant wordt tijdens het opzetten van een sessie een dynamische poort geopend (geregistreerd in de TCP stack), waarop voor die specifiek gestarte sessie (in combinatie met het service poortnummer) geluisterd wordt. Met de hulp van de IP adressen, protocol nummers en poort nummers zullen per sessie unieke combinaties ontstaan, waardoor het gelijktijdig starten van eventueel meerdere sessie naar verschillende services mogelijk is.

Schematische weergave van een aantal gelijktijdige TCP sessies

Bridges, switches, routers en hubs.
In het stukje "Routeren, hoe werkt dat" hebben we kunnen zien dat een router beslissingen neemt op basis van het IP adres. De onderliggende informatie (de mac adressen) wordt bij het doorsturen verwijderd en vervolgens voor het nieuwe netwerk opnieuw opgebouwd. Dit is een relatief processor intensieve bewerking. Deze functie is nuttig in grote netwerken waar bijvoorbeeld de hoeveelheid broadcasts problemen veroorzaakt of indien er binnen netwerken verschillende typen verbindingen (met ieder hun eigen soort laag 2 informatie) gebruikt worden.
Hebben we echter zoals we in de volgende tekening kunnen zien een netwerk met meerdere gebruikers en enkele servers, dan kunnen we ons voorstellen dat er meerdere werkstations zijn die gelijk tijdig data van verschillende servers proberen op te halen. Dit noemen we colission domains.

Een voorbeeld van een zgn collision domain.
We zien in de bovenstaande tekening de data als het ware tegen elkaar botsen. Indien dit incidenteel gebeurt, dan is dit niet zo erg, immers de stations zullen enkele milliseconden wachten en het dan nogmaals proberen. Zijn de netwerken echter zwaar belast, dan zal de snelheid die op de werkstations ervaren wordt dramatisch dalen. Door het opdelen van de netwerken in twee gescheiden netwerken, waarbij de verschillende groepen gebruikers zoveel mogelijk bij hun server geplaatst worden. Indien er dan toch nog een incidentele communicatie behoefte tussen de netwerken is, dan kan men een bridge tussen de netwerken plaatsen. Een bridge is in feite niets meer als een apparaat dat bij houdt aan welke kant een macadres zit. In het volgend voorbeeld wordt de switch en de bridge functie schematisch weergegeven.

Een schematische weergave van de bridge en de router functie.
Wat opvalt is dat op een gebridged segment de werkstation straffeloos van links naar rechts geschoven mogen worden. Aan beide zijden zit immers het zelfde IP subnet. Bij routers werkt dit niet. Je kunt je voorstellen dat dit in eenvoudige configuraties (vroeger was er niet veel connectiviteit nodig) en bij weinig servers wel werkt. Het betekend ook dat goed bijgehouden moet worden wie naar welke server moet.
Tegenwoordig zijn er echter kastjes te koop, switches noemen ze dat, die per poort een bridge functie vervullen. Door een dergelijk device in het hart van je netwerk te plaatsen, kunnen gebruikers eenvoudiger over de segmenten (collision domeinen) verdeeld worden en kan iedere server zijn eigen dedicated poort krijgen, waardoor een betere performance gehaald kan worden. In de onderstaande tekening zie je een eenvoudig netwerk met een viertal servers en enkele tientallen werkstations.

Een voorbeeld van een zgn switched ethernet.
Ook voor een dergelijk switched ethernet geldt dat door de switch slechts mac adressen bijgehouden worden. Dus ook hier kunnen de stations verhuist worden zonder dat zij hun IP adres hoeven aan te passen.
Tot slot. Binnen de huidige markt vinden we meer en meer zogenaamde level 3 switches, die feitelijk geen bridging functie vervullen maar routeren. Afhankelijk van de invulling van de leverancier komen we hier echter ook halve routers tegen, die i.p.v. mac adressen bij IP de IP adressen cachen.
Tot zover de inleidende cursus IP.