IT - The Journey

Ok, jij bezoekt nu deze webpagina over IT, Information Technology. Maar hoeveel IT komt er bij kijken om jouw te voorzien van deze informatie? Op deze pagina probeer ik een zo gedetaileerd mogelijk beeld te geven van het exacte websitebezoek wat je nu uitvoert op deze pagina. Met daarbij toegelicht wat dit te maken heeft met IT.

Laten we beginnen met het begin. Je kijkt nu naar een scherm, dus leest deze webpagina op een apparaat, voor dit voorbeeld een PC. Je PC bevat naast een beeldscherm ook een kast met diverse hardware-componenten: van processoren tot werkgeheugen en andere elektronische circuitborden. Daarnaast bevat je PC diverse aansluitmogelijkheden voor additionele apparatuur. Denk hierbij bijvoorbeeld aan een muis en toetsenbord of andere randapparatuur. Elk ook weer bestaand uit vele elektronische hoogstandjes.

Deze componenten in je computer worden aangestuurd door een centraal besturingssysteem, bijvoorbeeld Windows. Op dit besturingssysteem draait je web browser als applicatie. De handelingen die jij uitvoert in je web browser worden door het besturingssyteem in je computer vertaald naar digitale functies. Wanneer de centrale processor deze functies niet zelf kan uitvoeren, spreekt hij hiervoor via hardware drivers extra componenten aan. In het geval van het bezoeken van een website, zal deze website niet op de eigen PC staan, maar ergens op internet. Om het internet te kunnen bereiken spreekt de processor een network interface aan. Op je computer kan dat bijvoorbeeld een RJ-45-poort zijn, of een wifi-chipset.

Op naar het internet!

Je web browser vraagt een webpagina op aan de hand van functies uit het HTTP-protocol. Het formuleert een GET-verzoek op basis van een URI, waarin staat bij welke authority (lees: web server) je de webpagina wilt opvragen en je geeft een locatie op. Binnen een web browser wordt de authority meestal opgegeven in de vorm van een domeinnaam (bijv. bestpractise.net). De locatie bestaat vaak uit één of meer door slashes gescheiden woorden, bijv. /it/it_journey. Maar hoe weet jouw browser of computer hoe hij bij de genoemde web server uitkomt?

    :authority: bestpractise.net
    :method: GET
    :path: /it/it_journey
    :scheme: http

Het HTTP GET-verzoek wordt gericht aan bestpractise.net. Deze domeinnaam is bij een eerste bezoek nog niet bekend op je computer. En aangezien alle adressering op het internet door middel van IP-adressen gaat, zal eerst het juiste IP-adres voor deze domeinnaam opgezocht moeten worden. Hiervoor kan jouw computer terecht bij zijn DNS-servers. In de meeste situaties krijg je de DNS-servers automatisch toegewezen via het configuratieprotocol DHCP. Je computer vraagt aan de DNS-server wat het juiste IP-adres is voor de domeinnaam bestpractise.net.

DNS-servers bevinden zich vaak buiten het directe bereik van een thuiscomputer. Thuiscomputers zijn via een lokaal (soms draadloos) netwerk verbonden met het internet. Om dit DNS-verzoek bij de DNS-server te krijgen zullen dus nog een aantal stappen gezet moeten worden. Volgens het OSI-model wordt allereerst dit netwerkverzoek voorzien van de juiste enveloppen, met daarop de juiste adressering. In de fysieke wereld hebben we de maken met straatnamen, plaatsen, provincies, landen en continenten. Zo heb je ook in de digitale wereld te maken met andere handelswijzen wanneer je je pakket bepaalde grenzen wilt laten passeren.

Weet iemand de weg naar...?!

Je thuisnetwerk kun je vergelijken met je eigen straat. Binnen je straat weet je de meeste huizen te vinden, zonder verder op straatnaambordjes te kijken of grote kruispunten over te steken. In de digitale wereld wordt voor het rondkijken in de straat ARP gebruikt. Door middel van ARP kun je vragen wie er bij je in de buurt woont, en een ander antwoord met zijn adres. In het geval van je thuisnetwerk gaat dit om een hardware adres, ook wel MAC-adres. MAC-adressen worden gebruik voor adressering van lokale pakketten. Maar hadden we net niet gezegd dat de DNS-servers zich buiten het directe bereik van je thuiscomputer bevinden?!

Om buiten je eigen thuisnetwerk te kunnen treden heeft ieder netwerkapparaat een ''network gateway'' opgegeven. Dit is een apparaat wat jouw netwerk verbindt met een ander netwerk. In de fysieke wereld zie je dit aan het eind van je straat terug als een kruispunt. Dit verbindt jouw straat met een volgende. En als je steeds volgende straten ook weer verbind met nog een volgende krijg je vanzelf een wereldwijd netwerk van straten en kruispunten. Op internet werkt dat niet anders, alleen heten de digitale kruispunten routers. In jouw computer staat 'het einde van de straat' aangegeven als gateway, wat in de praktijk meestal je internetrouter in de meterkast is.

We hebben het IP-adres van de DNS-server (via DHCP gekregen), waar we nog steeds de domeinnaam bestpractise.net willen opvragen. Ook hebben we een route naar internet, want je PC heeft een gateway. Volgens het OSI-model wordt het DNS-verzoek ingepakt in een TCP/IP-pakket en voorzien van een adreslabel. Dit pakket is voor de DNS-server. Het pakketje wordt vervolgens door je netwerk interface geadresseerd aan je gateway en daarna omgezet in elektrische pulsen. Via een UTP-kabel of draadloze radioverbinding wordt deze pulsen verstuurd.

De wijde wereld in

Je gateway (die router in je meterkast) ontvangt deze signalen en weet met zijn netwerk interface hier weer een pakketje van de vormen. De interface herkent het (MAC)adreslabel en neemt het pakketje aan. Hij maakt de digitale vracht open en vindt binnenin een TCP/IP-pakket met een adreslabel voor de DNS-server. Deze server kent hij als router zelf ook niet. Dus herhaalt het inpakproces zich en adresseert jouw router het pakket opnieuw met een MAC-adres, maar deze keer van zijn gateway. Je komt zo weer een kruispunt verder en beland aan bij je Internet Service Provider (bijv. Ziggo). Jouw ISP is via verschillende Internet Exchanges aangesloten op andere netwerken van andere providers. En op deze manier kun je de hele wereld rondreizen.

Via jouw ISP kom je terecht bij de DNS-server. We willen namelijk de locatie van de web server weten. Wij vragen de DNS-server naar de gegevens voor de domeinnaam bestpractise.net. De DNS-server zoekt de juiste DNS zonefile erbij en gaat binnen de zonefile opzoek naar een Address-record (A-record). Hij geeft het gevonden IP-adres terug en op digitaal niveau keert het antwoord op jouw DNS-verzoek terug via de omgekeerde weg. De DNS-server stuurt via zijn gateway naar zijn Internet Service Provider. Via alle knooppunten kom je uiteindelijk weer uit bij de router in jouw meterkast, die het doorstuurt naar je PC. We've got em! We hebben het IP-adres van de web server!

Naar de web server!

De browser had al een HTTP-GET-verzoek klaar staan voor de web server. Hierin werd verzocht welke webpagina we willen bezoeken. Omdat we net via de DNS-server het juiste IP-adres hebben gekregen, wordt ook dit HTTP GET-verzoek ingepakt in een TCP/IP-pakketje. Adreslabel er op, gericht aan de webserver, en versturen maar. Op een vergelijkbare wijze als bij een DNS-verzoek wordt via je ISP het internet bereikt en vindt jouw TCP/IP-pakketje zijn weg naar het juiste datacenter. Datacenters zijn de digitale industrietereinen en eke grote stad heeft ze. Je treft hier vaak (tien)duizenden fysieke servers aan die steeds via routers aan internet zijn verbonden. Via de betreffende routers kom je aan bij een hostingplatform. Deze bestaan in vele soorten en maten, maar in het geval van website hosting is dit meestal een virtualisatieplatform als VMware vSphere of CloudStack. Dit virtualisatieplatform bestaat uit vele fysieke apparaten, waaronder de hypervisors, die samen hele clusters aan virtuele machines draaien. Eén van die virtuele machines is de web server waar jij je HTTP GET-verzoek wilde aanbieden.

De virtuele machine ontvangt het TCP/IP-pakketje wat via zijn besturingssysteem verder wordt uitgepakt. Als eerste wordt het adreslabel dubbelgecheckt op basis van de actieve firewall-regels. Is dit pakketje daadwerkelijk voor deze server bedoeld? En staat deze server toe dat pakketjes van deze verzender door mogen? Hierbij wordt tevens gekeken naar de TCP/IP Destination Port welke is opgegeven op het adreslabel. Als websitebezoeker geef je die vrijwel nooit op, maar onderwater vult jouw web browser hier al poortnummer 80 of 443. De eerste voor een standaard verbinding, en poort 443 wanneer de web browser gebruik wil maken van een versleutelde verbinding. Wanneer het pakket op basis van de firewall-regels wordt goedgekeurd wordt het verder in behandeling genomen. Wordt het afgekeurd dan wordt het pakket verwijderd, al dan niet met een retourberichtje richting de afzender.

Mooi, het pakketje mag door! Het besturingssysteem kijkt nu welke netwerk sockets er zijn geregistreerd voor de opgegeven TCP/IP Destination Port. In het geval van dit HTTP GET-verzoek gaat het om poort 80 of 443. Er blijkt zich een Apache HTTPD web server geregistreerd te hebben op deze poort. Het TCP/IP-pakket wordt de doos gehaald en het HTTP GET-verzoek wordt doorgestuurd naar de Apache HTTPD web server. Apache HTTPD kijkt in de HTTP-headers van dit verzoek om te bepalen aan wie het geadreseerd was. En treft hier het volgende aan:

Accept: text/html,application/xhtml+xml
Host: bestpractise.net
User-Agent: Mozilla/5.0

In zijn eigen configuratie gaat Apache HTTPD opzoek naar configuratie met de ServerName die gelijk is aan de opgevraagde Host 'bestpractise.net'. Op een web server die meerdere websites draait zijn er verschillende Virtual Hosts aangemaakt. De juiste configuratie wordt gevonden en Apache HTTPD vraagt de bestanden op welke onder DocumentRoot zijn opgegeven bij deze Virtual Host. In dit geval staat de DocumentRoot /var/www/sites/bestpractise.net opgegeven. Apache HTTPD vraagt via het besturingssysteem aan het filesystem om deze locatie op te zoeken en alle bestanden terug te geven. Deze bestanden blijken op een tweede virtuele hard disk te staan. Via het besturingssysteem, de virtuele hardware en de hypervisor worden de bestanden opgehaald vanaf een storage platform. Zodra alle bestanden zijn teruggegeven aan Apache HTTPD, gaat deze het bestand dat is opgegeven als DirectoryIndex in behandeling nemen. Het blijkt een bestand met de naam index.php.

Website rendering

In de configuratie van Apache HTTPD staat aangegeven dat de web server bestanden die eindigen op .php moet doorsturen naar de PHP-handler. Dit is een extra applicatie die op basis van programmacode van een programmeur extra (interactieve) handeling kan uitvoeren, voordat de webpagina wordt teruggestuurd naar de bezoeker. In de praktijk gaat het dan vaak om het op de achtegrond dynamisch opbouwen van een website aan de hand van berichten, comments, externe content, etc. De PHP-handler behandeld alle programmacode in het index.php bestand en bouwt als resultaat een bestand op volgens HTML-opmaak. Dit HTML-bestand wordt teruggegeven aan Apache HTTPD. Die weet welke bezoeker dit verzoek had ingediend en zet deze webpagina op transport richting de websitebezoeker. Via het besturingssysteem wordt de website weer keurig ingepakt in een TCP/IP-pakketje en via de networkstack teruggezonden naar de bezoeker:

1. Apache HTTPD adreseert in een HTTP response, aan het thuis IP
2. Besturingssysteem van de web server maakt er een TCP/IP pakket van, geadresseerd aan jouw huisadres.
3. Via het virtualisatieplatform in het datacenter en alle routers komt het aan in jouw meterkast.
4. Aangekomen op jouw PC wordt het doorgestuurd naar jouw web browser.

Je web browser heeft antwoord binnengekregen op zijn HTTP GET-verzoek! De website is binnen! Althans, een eerste indexpagina is binnen. In de broncode van deze indexpagina vindt je web browser nog diverse andere hyperlinks die ook als onderdeel van deze website worden aangegeven. Denk hierbij aan CSS-stylesheets, diverse afbeeldingen, fonts en browser scripts. Ook dat zijn allemaal bestanden die helemaal aan de overkant op de web server staan.

Zo snel als hij kan bouwt je web browser ook voor al deze andere bestanden nieuwe HTTP GET-verzoeken op. Dit kunnen er zomaar 10-50 stuks voor één enkele webpagina zijn. Voor elk van deze bestanden wordt bovenstaande traject van HTTP GET-verzoeken helemaal opnieuw uitgevoerd. Wanneer alle benodigde bestanden zijn binnenkomen bij je web browser zal deze op basis van de broncodes de bedoelde website gaan intekenen op je scherm. Content blokken en teksten er in vanuit HTML. Aangevuld met verschillende afbeeldingen. Hierna wordt de styling afgemaakt met alle regels die opgenomen staan in de CSS-stylesheets. En als laatste worden meegezonden browser scripts (meestal JavaScript) uitgevoerd voor de laatste dynamische wijzigingen. Zodra je web browser de hele website pixel voor pixel heeft ingetekend in het werkgeheugen van je computer, wordt deze via de video chipset omgezet in digitale HDMI-instructies en in elektische signalen doorgestuurd naar je beeldscherm. Je beeldscherm bouwt aan de hand van alle pixels de website op je scherm op. Op een HD-scherm (1920x1080) gaat dat al om ruim 2 miljoen afzonderlijke pixels.

Nog een keer!

Bij ieder nieuwe website bezoek vindt op de achtergrond het hele bovenstaande verhaal plaats. Pakketjes, routers, protocollen, redening; hethele verhaal in een fractie van een seconde!

PS. Echte techneuten weten dat bovenstaande slechts een illustratieve samenvatting is. In werkelijkheid gebeuren er in die ene seconde nog heel veel meer technische handelingen.