Verder Terug Inhoud

13. Hoe werkt het Internet?

Om je te helpen begrijpen hoe het Internet werkt, zullen we datgene bekijken wanneer je een typische Internet operatie uitvoert -- -- een browser richtend op de voorpagina van dit document op z'n thuisbasis op het web bij het Linux Documentatie project. Dit document is

http://metalab.unc.edu/LDP/HOWTO/Fundamentals.html

wat betekent dat het voorkomt in het bestand LDP/HOWTO/Fundamentals.html onder de World Wide Web export-directory van de host metalab.unc.edu.

13.1 Namen en lokaties

Het eerste wat je browser moet doen is een netwerkverbinding tot stand brengen met de computer waarop het document voorkomt. Om dat te kunnen doen, moet het eerst de netwerklokatie van de host metalab.unc.edu traceren (`host' is een afkorting voor `host machine' of `netwerk host'; metalab.unc.edu is een typische hostname). De corresponderende lokatie is in werkelijkheid een nummer dat een IP-adres wordt genoemd (het `IP' deel van deze term wordt later uitgelegd).

Om dit te doen, ondervraagt je browser een programma dat een name-server wordt genoemd. De name-server kan zich op je computer bevinden, maar het is waarschijnlijker dat het draait op een service machine waarmee de jouwe communiceert. Als je je bij een ISP aanmeldt, zal een deel van je setupprocedure bijna zeker inhouden dat je Internet software het IP-adres van een name-server op het netwerk van de ISP bekend wordt gemaakt.

De name-servers op verschillende computers praten met elkaar over alle informatie die nodig is om hostnamen te herleiden, uit te wisselen en up to date te houden (ze in te delen naar IP adressen). Het zou kunnen dat je name-server drie of vier verschillende sites in het netwerk ondervraagt tijdens het herleidingsproces van metalab.unc.edu, maar dit gebeurt gewoonlijk erg snel (in minder dan een seconde).

De name-server zal je browser laten weten dat het IP adres van Metalab 152.2.22.81 is; nu het dit weet, zal je computer in staat zijn om op directe wijze bits met metalab uit te wisselen.

13.2 Packets en routers

Wat de browser wil doen is een commando naar de Webserver op Metalab zenden dat er ongeveer zo uitziet:

GET /LDP/HOWTO/Fundamentals.html HTTP/1.0

Dit is wat er gebeurt. Het commando wordt veranderd tot een pakket, een blok bits zoals een telegram dat met drie belangrijke zaken wordt ingepakt; het bronadres (het IP-adres van je computer), het bestemmingsadres (152.2.22.81), en een service-nummer of poortnummer (80, in dit geval) dat aangeeft dat het een World Wide Web verzoek is.

Je computer seint het pakket over (via een modem verbinding naar je ISP, of lokale netwerk) totdat het bij een gespecialiseerde computer aankomt, die een router wordt genoemd. De router heeft een indeling van het Internet in zijn geheugen -- niet altijd compleet, maar één die je netwerkomgeving volledig beschrijft en weet hoe het bij de routers in andere omgevingen op het Internet moet komen.

Je pakket kan verscheidene routers passeren op weg naar zijn bestemming. Routers zijn slim. Ze kijken hoelang het duurt voor andere routers beantwoorden dat ze een pakket hebben ontvangen. Ze gebruiken die informatie om het verkeer via snelle links te adresseren. Ze gebruiken het om op de hoogte te zijn als andere routers (of een kabel) van het netwerk zijn uitgevallen, en compenseren dit zo mogelijk door het zoeken naar een andere route.

Er is een stedelijke legende die zegt dat het Internet is ontworpen om een nucleaire oorlog te overleven. Dit is niet waar, maar het ontwerp van het Internet is extreem goed in het verkrijgen van betrouwbare performance buiten onconventionele hardware in een onzekere wereld. Dit is te danken aan het feit dat zijn intelligentie via duizende routers in plaats van een paar massieve schakelingen (zoals het telefoon-netwerk) wordt gedistribueerd. Dit betekent dat storingen goed kunnen worden gelokaliseerd en het netwerk ze kan omzeilen.

Zodra je pakket bij zijn bestemmingsmachine aankomt, gebruikt die machine het service-nummer om het pakket aan de webserver door te geven. De webserver weet waarnaar het de reply moet zenden door het bron IP-adres van het pakket te bekijken. Als de webserver dit document retourneert, zal het in een aantal pakketjes worden opgebroken. De grootte van de pakketjes zal overeenkomstig de transmissiemedia in het netwerk en de soort service variëren.

13.3 TCP en IP

Om te begrijpen hoe meerdere-pakket transmissies worden afgehandeld, is het nodig dat je weet dat het Internet in werkelijkheid twee protocollen gebruikt, de één bovenop de ander gestapeld.

Het lagere niveau, IP (Internet Protocol), weet hoe het individuele pakketjes vanaf een bron-adres naar een doel-adres moet krijgen (daarom worden ze IP-adressen genoemd). IP is echter niet betrouwbaar; als een pakketje verdwaalt of zoekraakt, kan het zijn dat de bron- en bestemmingsmachine dit nooit zullen weten. In netwerkjargon, is IP een connectieloos protocol; de zender stuurt gewoon een pakket naar de ontvanger en verwacht geen bevestiging.

Hoe dan ook, IP is snel en goedkoop. Soms is snel, goedkoop en onbetrouwbaar OK. Als je via een netwerk Doom of Quake speelt, stelt iedere kogel een IP-pakketje voor. Als een aantal daarvan verdwaald raken, is dat OK.

Het bovenste niveau, TCP (Transmission Control Protocol), geeft je betrouwbaarheid. Als twee computers een TCP connectie tot stand brengen (wat ze doen door gebruik te maken van IP), weet de ontvanger dat het bevestigingen van de pakketjes die het ziet naar de zender moet terugsturen. Als de zender geen bevestiging te zien krijgt binnen een bepaalde pauzeperiode voor een pakketje, zendt het dat pakketje opnieuw. Verder geeft de zender ieder TCP pakket een opeenvolgend nummer, welke de ontvanger kan gebruiken om je pakketjes weer samen te voegen voor het geval ze niet in de juiste volgorde verschijnen. (Dit kan gebeuren als netwerkkoppelingen gedurende een verbinding worden verbroken of hersteld).

TCP/IP pakketjes bevatten ook een controle-totaal om detectie te activeren van gegevens die door slechte links zijn beschadigd. Dus vanuit het gezichtspunt van iemand die TCP/IP en name-servers gebruikt, lijkt het een betrouwbare manier om stromen bytes tussen hostname/service-nummer paren door te geven. Mensen die zich bezig houden met het schrijven van netwerkprotocollen hoeven zich bijna nooit bezig te houden met het verpakken van informatie in pakketjes, het weer samenvoegen van pakketjes, foutencontrole, controleren van totalen, en herverzending dat op dat niveau plaatsvindt.

13.4 HTTP, een applicatieprotocol

Laten we nu naar ons voorbeeld teruggaan. Web browsers en servers spreken een applicatieprotocol dat bovenop TCP/IP wordt uitgevoerd, door het eenvoudigweg als een manier te gebruiken om reeksen bytes heen en weer door te geven. Dit protocol wordt HTTP (Hyper-Text Transfer Protocol) genoemd en we hebben reeds een commando ervan gezien -- het GET zoals hierboven getoond.

Als het GET commando naar de webserver van metalab.unc.edu met service nummer 80 gaat, zal het naar een server daemon luisterend op poort 80, worden verzonden. De meeste Internetdiensten worden door serverdaemons uitgevoerd die niets anders doen dan poorten in de gaten houden, uitkijken naar en uitvoeren van inkomende commando's.

Als het ontwerp van het Internet over de gehele linie gelijk zou zijn, is het dat alle delen zo eenvoudig en mens-toegankelijk mogelijk zou moeten zijn. HTTP, en daaraan gerelativeerde protocollen (zoals het Simple Mail Transfer Protocol, SMTP, dat wordt gebruikt om elektronische mail tussen hosts te verplaatsen) maken in het algemeen gebruik van eenvoudige afdrukbare-tekst commando's die met een carriage-return/line feed eindigen.

Dit is marginaal inefficient; in een aantal omstandigheden zou je meer snelheid kunnen krijgen door gebruik te maken van een waterdicht-gecodeerd binair protocol. Maar ervaring heeft uitgewezen dat de voordelen van commando's die gemakkelijk door menselijke wezens zijn te beschrijven en begrijpen zwaarder wegen dan enig bijkomstig voordeel in efficiëntie dat je zou kunnen krijgen ten koste van het maken van lastige en onbevattelijke zaken.

Daarom is wat de serverdaemon je terugzendt via TCP/IP ook tekst. Het begin van de response zal er ongeveer zo uitzien (een paar van de headers zijn achtergehouden):

HTTP/1.1 200 OK
Date: Sat, 10 Oct 1998 18:43:35 GMT
Server: Apache/1.2.6 Red Hat
Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT
Content-Length: 2982
Content-Type: text/html

Deze headers zullen worden gevolgd door een lege regel en de tekst van de webpage (waarna de verbinding wordt verbroken). Je browser toont enkel die pagina. De headers geven aan hoe (in het bijzonder vertelt de Content-Type header het dat de geretourneerde gegevens in feite HTML zijn).


Verder Terug Inhoud