Het begrip 'netwerkprotocollen' is erg ruim. Meestal bedoelt men er zowat alles mee dat een netwerk laat functioneren op softwareniveau. Nadat je een netwerk geconstrueerd hebt door allerlei hardware met kabels aan elkaar te koppelen, zorgt software er immers voor dat er data over dat netwerk gestuurd kan worden. Het netwerk heeft zelf ook al een organisatie - bijvoorbeeld Ethernet - die eigenlijk met software te maken heeft, maar omdat dat in de hardware ingebouwd zit staan we daar verder nooit bij stil. Zoals we in vorige hoofdstukken van deze reeks zagen, zorgt een Ethernet netwerk er zelf al voor dat data in mooie pakketjes (de Ethernet-frames) ingepakt wordt en verzonden doorheen de kabeling met behulp van een collisiedetectiemechanisme. Hoewel het dus mogelijk is om rechtstreeks hiervan gebruik te maken om data over het netwerk te sturen, heeft dat een aantal nadelen op een hoger niveau. Zo zou je netwerkaansturing alleen maar geschikt zijn voor een Ethernet netwerk, niet voor Token Ring of iets anders. Routeren naar een ander netwerk zou zo goed als onmogelijk zijn. Bovendien zou je alleen rauwe data kunnen versturen, er zou geen organisatie in die data zitten om aan te geven dat die bij bepaalde applicaties hoort of een bepaald doel heeft. Daarvoor dienen de hogere netwerkprotocollen. Die zijn onafhankelijk van de netwerktopologie en -organisatie, wat wil zeggen dat ze voor zowel Ethernet als Token Ring als een hele hoop andere hetzelfde zijn. Ze functioneren dus binnen de OSI-lagen 3 en 4 (netwerk- en transportlaag). De hogere netwerkprotocollen zullen data in bij dat protocol horende pakketten indelen, waarbij ieder pakket voorzien zal zijn van adressen voor zender en ontvanger, maar ook van inlichtingen in verband met het doel van de data. Hogere netwerkprotocollen laten dus toe data te identificeren als bedoeld voor een bepaald doel of een bepaalde applicatie. In dit deel zullen we ons verder alleen bezighouden met TCP/IP, in het volgende deel behandelen we IPX en daarna SMB/NetBEUI/NetBIOS. Er zijn uiteraard nog veel meer netwerkprotocollen mogelijk en in gebruik, maar deze drie zijn de bij pc's meest gebruikelijke. Voorbeelden van andere zijn SNA (in gebruik bij IBM minicomputers en mainframes), Appletalk (in gebruik bij Apple Macintosh) en andere.
TCP/IP TCP/IP is het netwerkprotocol van de Unix-wereld en omdat het internet oorspronkelijk groeide uit de koppeling van Unix-machines, is TCP/IP dus ook het netwerkprotocol voor het internet. We zagen in de eerste paar hoofdstukken van deze reeks al dat TCP/IP niet exact voldoet aan het OSI-lagenmodel. Vaak delen we TCP wel in bij de transportlaag en IP bij de netwerklaag, maar de waarheid is dat bij TCP/IP het onderscheid vaak vervaagt en een en ander in elkaar overvloeit. Zoals je je wellicht herinnert zorgt de netwerklaag voor het transport, de adressering en de routering doorheen een netwerk, terwijl de transportlaag zorgt voor de data-onafhankelijke eind-naar-eindtransmissie voor de hogere lagen. Bij TCP/IP kun je zeggen dat IP instaat voor transport, adressering en routering en dat TCP de eind-naar-eindtransmissies verzorgt, maar zo simpel is het niet altijd. TCP heeft bijvoorbeeld nog een 'broertje' dat UDP heet en ook voor eind-naar-eindtransmissies zorgt. We zullen daarom eerst beginnen met de basis van alles: IP of het Internet Protocol.
IP-adres In de wereld van het Internet Protocol heeft ieder netwerkstation een uniek adres: het ip-adres. De hele wereld werkt momenteel met de IP v4 specificatie en die definieert een ip-adres van 4 bytes lang, waarbij dat adres een net en een 'host' of eindstation aangeeft. Om te weten waar de netidentificatie eindigt en waar de hostidentificatie begint, zijn in de IP v4 specificatie ip-adressen ingedeeld in vijf klassen: van A tot E. Hierbij dient klasse D echter voor multicasting en klasse E is voor toekomstig gebruik, dus die gaan we even buiten beschouwing laten. Een klasse A ip-adres geeft in de eerste byte het net aan en de drie volgende bytes specifiëren het netwerkstation (de host) in dat net. Dit is bedoeld voor een net met een enorm groot aantal stations: met drie bytes kun je immers meer dan 16,7 miljoen stations nummeren. In feite moet bij klasse A het eerste bit altijd 0 zijn, omdat we dan hieraan kunnen zien met welke klasse van ip-adres we te maken hebben. Dat betekent dus dat je met klasse A slechts 7 bits over hebt voor de netidentificatie; je kunt dus 126 netten hebben. Het klasse B ip-adres heeft als eerste drie bits altijd '10' en gebruikt 14 bits voor de identificatie van het net (16382 mogelijke netten) en 16 bits voor de host (65534 mogelijke hosts). Tenslotte hebben we klasse C, dat het meest gebruikt wordt: hierbij zijn de eerste vier bits altijd '110', zodat je 21 bits overhoudt voor de netwerkidentificatie (meer dan 2 miljoen mogelijke netten) en 8 bits voor de host (254 mogelijke hosts). Overigens zijn bij klasse D de eerste vijf bits gereserveerd en altijd '1110', terwijl bij klasse E daarvoor de eerste zes bits dienen en op '11110' staan. Je kunt dus weten met welke klasse van ip-adres je te maken hebt door de positie van de eerste nul-bit op te zoeken: de positie geeft de klasse aan (van 1 tot 5). Nu is een vier bytes (32 bits) lang getal geen makkie om te onthouden en dus zocht men naar een methode om dat te vergemakkelijken. Dat werd dan de 'dotted decimal' notatie: je schrijft de decimale waarde van elk van de vier bytes met een punt tussen elk getal. Een ip-adres met hexadecimale waarde C207F901 heeft met dat eerste hexcijfer 'C' (binair 1100) de eerste nul-bit op de derde positie en het gaat dus om een klasse C adres dat we gemakkelijkshalve noteren als 194.7.249.1. Klasse C wil zeggen dat het laatste getal het eindstation aangeeft en de eerste drie het net specifiëren. Waarom de splitsing tussen net en host? Dat heeft te maken met de vereiste dat alle ip-adressen uniek horen te zijn. Een net-id kies je niet zelf: dat wordt je toegewezen door een hiërarchische hogere beheerder (zoals een internet provider en die krijgt zijn reeks van net-id's toegewezen door InterNIC (www.internic.net) die alles in verband met ip-adressen op internet beheert. Het host-id kun je wel zelf kiezen, tenminste als je zelf dat subnet beheert. In een bedrijf zal dat meestal de netwerkbeheerder zijn en als je je pc thuis aan internet koppelt dan kiest je internet provider het host-id voor je. In veel gevallen kan zo'n host-id automatisch toegewezen worden met behulp van zogenaamde configuratieprotocols zoals DHCP, BOOTP of RARP. Op deze komen we later nog terug.
Speciale ip-adressen Een host-id of net-id (of subnet) waarvan alle bits gelijk zijn aan 0 betekent 'deze host' of 'dit net'. Vaak kan het gebruikt worden als een soort van joker als je niet het volledige ip-adres kent. Zo kun je 194.7.249.0 interpreteren als 'eender welke host in net 194.7.249'. Dit is vooral handig om routes vast te leggen. Een route van 0.0.0.0 naar 194.7.249.2 zou bijvoorbeeld betekenen dat pakketten voor eender welk ip-adres altijd naar adres 194.7.249.2 gerouteerd moeten worden. We komen later terug op routeren binnen internet. Zijn alle bits van een host- of net-id daarentegen gelijk aan 1, dan betekent dat 'alle hosts' of 'alle nettten'. Omdat je dan meer dan één ip-adres tegelijk aanspreekt, heet zoiets 'broadcast' (letterlijk: uitzending, zoals een tv-uitzending naar meerdere televisies tegelijk gaat). Een heel speciaal ip-adres is het zogenaamde 'loopback'-adres 127.0.0.1. Aan de nul-bit op de meest linkse positie kun je zien dat dit een klasse A adres is: het net-id is dus niet 127 maar 7 en alle andere bits horen in feite bij het host-id. In feite verwijst 127.0.0.0 naar een loopback-netwerk: alle transmissies verlaten dat netwerk nooit en in het geval van een loopback host blijft alle communicatie binnen die host. Een pc hoeft dus niet verbonden te zijn met een LAN of een internet provider om TCP/IP te kunnen gebruiken: je kunt alles doen met het loopback-adres 127.0.0.1, maar het werkt allemaal alleen binnen je eigen pc. Je moet dus zelf voor alle functionaliteit (client en server) zorgen. Daarmee bedoelen we: als je wil surfen naar 127.0.0.1 kan dat, maar dan moet je wel eerst zorgen voor een webserver op je pc. In de meeste systemen koppelt men de domeinnaam 'localhost.' vast aan dat adres 127.0.0.1. Nu was er ook nog behoefte om een lokaal privénetwerk te kunnen opzetten dat geen publieke ip-adressen nodig heeft, maar ook geen schade kan aanrichten als het toch nog op internet aangesloten mocht worden. Daarvoor werd er een zogenaamd privénet gecreeërd voor iedere klasse van ip-adressen. Voor klasse A mag je alle adressen van het type 10.0.0.0 (dat is net 0 en daarin alle host-ids beginnend met 00A0...) vrij gebruiken. Voor klasse B gaat het om 172.16.0.0 tot en met 172.31.255.255. Tenslotte werd 192.168.0.0 gereserveerd voor klasse C. Deze gereservereerde netten voor privégebruik werden en worden dus nooit toegewezen aan aanvragers van een publiek ip-adres. Ze zijn per definitie niet routeerbaar, dus zelfs als een host of een net zich met deze adressen op internet aanmeldt zal dat niet voorbij de eerste router geraken.
IP v6 Met IP v4 hebben we slechts 32 bits adresruimte en hoewel meer dan 4 miljard adressen meer lijkt dan we ooit nodig zullen hebben, is dat helaas niet het geval. Dat is voornamelijk te wijten aan het toewijzen van hele netten aan bedrijven en allerlei instanties. Hoewel er in het verleden al allerlei maatregelen genomen werden om wildgroei op dit vlak zoveel mogelijk in te perken (zoals dynamische adrestoewijzing en waar mogelijk gebruik maken van privé-adressen), is de algemene consensus toch dat een en ander in de nabije toekomst problematisch dreigt te worden en dat het een goed idee is om alvast uit te kijken naar een oplossing. Die oplossing heeft IP v6. Hierbij definieert men een adresruimte van 128 bits, waarmee meer dan 3,4 * 1038 (een 3 gevolgd door 38 nullen) adressen mogelijk zijn. In een later deel uit deze serie zullen we veel uitgebreider terugkomen op IP v6.
TCP Het IP-protocol zorgt voor het inpakken van data in pakketten met ip-adressen voor zender en ontvanger, maar met de rauwe data alleen zijn we natuurlijk niet veel. We moeten ook een manier hebben om in zo'n pakket aan te geven waar het bij hoort. Daar dient TCP (Transmission Control Protocol) voor: zoals de naam het al zegt, moet dat protocol de transmissie in goede banen leiden. De hoofdbedoeling hiervan is het mogelijk te maken dat meerdere applicaties tegelijk transmissies kunnen uitvoeren tussen twee stations. De meest eenvoudige uitleg over TCP is, dat het een poortnummer bij elk ip-pakket plakt. Dat poortnummer geeft aan bij welke applicatie het hoort. Let wel: meer dan datastromen met eenzelfde poortnummer bij elkaar houden zit er niet in. Hoewel bepaalde poorten vast bij bepaalde applicaties horen, moeten die applicaties zelf natuurlijk ook nog werk verrichten. Een TCP-poort is een 2 bytes grote waarde, wat betekent dat er 65536 mogelijke waarden zijn. De overgrote meerderheid daarvan is niet aan een welbepaalde applicatie geklonken, maar voor poortnummers onder 1000 is dat meestal wel het geval. Heel bekende poorten zijn: 21 voor ftp, 23 voor telnet, 27 voor smtp, 53 voor domeinnaamvertalingen, 67 voor dhcp-servers, 68 voor dhcp-clients, 80 voor http en 110 voor pop3. Er zijn er natuurlijk nog heel wat meer gedefinieerd, maar die gaan we hier niet allemaal opsommen. Je kunt bij veel applicaties trouwens ook configureren welke poort ze moeten gebruiken. Als je echter standaardfuncties op andere dan de bekende poorten definieert, kan het algemene publiek er niet meer mee werken. Daarmee bedoelen we: als je een webserver bijvoorbeeld op poort 2080 doet werken, kan alleen maar iemand die die poort kent er naartoe surfen. TCP doet nog meer dan alleen data per poort bijeenharken. Het doet ook aan datastroom- en foutenbeheer en zorgt er zo voor dat de datatransmissie betrouwbaar is. Men noemt TCP een verbindingsgeöriënteerd protocol, wat wil zeggen dat applicaties eerst een client-serververbinding moeten opbouwen voordat ze kunnen werken. Overigens mag je het woord 'datatransmissie' hier niet verwarren met het verzenden van ip-pakketten, omdat het IP (internetprotocol) immers zelf daarvoor verantwoordelijk is.
UDP UDP staat voor 'User Datagram Protocol' en is veel eenvoudiger van opzet. Ook hier wordt met poorten gewerkt en meestal koppelt men applicaties aan dezelfde poortnummers als bij TCP. UDP is een verbindingsloos protocol en vereist dus niet dat een verbinding opgebouwd en betrouwbaar gehouden wordt. Het gaat er vanuit dat data gewoon verzonden kan worden en dan zonder meer ter bestemming aankomt. UDP kent dus geen datastroom- en foutenbeheer en zorgt dus ook niet voor een betrouwbare transmissie. Bij lokale en betrouwbare netwerkverbindingen is het dus in principe mogelijk om met UDP een iets hogere snelheid te halen dan via TCP. Omdat moderne applicaties er echter bij voorkeur niet vanuit mogen gaan dat ze nooit via het internet zullen moeten werken, werken meer en meer applicaties standaard met TCP.
« Ga terug
