Het nieuwe internet mist meer gebruik van Websockets en WebRTC bovenop stateless HTTP. Zo, dat is eruit. En ja, dat was vrij technisch. Maar lees gerust verder, want ik ga het eerst eenvoudig uitleggen voordat ik technisch afsluit met een oplossing waarvan ik hoop dat programmeurs, bedrijven en politici mogelijk iets meepikken.
Waar komt een website eigenlijk vandaan?
Laten we bij het begin beginnen. Maar als je alles van het internet al weet, ga dan gerust verder vanaf de kop "Zijn er al oplossingen beschikbaar?"
Afijn. Het internet is overal, van koelkasten tot Smart-TVs, en van tablets tot horloges. Innovatie op dit gebied is er dan ook volop. Toch zijn sommige technologieën nog niet volledig omarmd, en dat belemmert wat het zou kunnen zijn, of misschien wel zou moeten zijn.
Wat weinig mensen weten is dat elke pagina die je bekijkt vanaf een zogenaamde server komt, en hoe dat dan eigenlijk werkt.
Het web is stateless: standaard onthoudt het niets
Het internet gebruiken kan zo simpel zijn als het bezoeken van een nieuwswebsite of webwinkel. Je ziet een pagina met informatie. Die komt vanaf een server. Dat is simpelweg een computer die dag en nacht aan staat. Een server ziet er echter niet uit zoals je laptop- of desktop-computer die je thuis hebt. Een server heeft bijvoorbeeld geen muis, toetsenbord en beeldscherm zoals een typische desktop-computer. De computerkast van een server is een lade, net als je besteklade in de keuken.
De hoogte van zo'n lade drukken we vaak uit in "U" wat voor "Unit" staat. Een gangbare hoogte voor een serverlade is "1U". Dat komt neer op 44,45 millimeter. Afijn. Er zijn veel van dit soort servers nodig voor al die websites in de wereld. Daarom zijn er kasten uitgevonden die we "racks" noemen. Die kasten bieden soms wel ruimte voor 48U. Dat zijn dus 48 servers in 1 kast ofwel rack. En van die racks staan er dan weer vele in een suite. En van die suites staan er dan weer vele van in een datacenter. Een datacenter is een gebouw speciaal voor servers. Er kunnen wel duizenden 1U servers in zo'n gebouw zijn ondergebracht op deze manier.
Veel van die servers zijn zogenaamde webservers. Een webserver is een server die gespecialiseerd is in het leveren van het "web" zoals wij deze kennen. Websites. Als je een webadres intikt op je computer of telefoon, dan komt jouw apparaat via slimme routes (DNS) uiteindelijk uit bij één van deze webservers ergens in een datacenter. En die server formuleert een antwoord die weer helemaal terug bij jou aankomt.
In het geval van webservers komt dat antwoord over het algemeen in een vorm van tekst. Vaak een combinatie van drie computertalen. Te weten; HTML, CSS en Javascript. Je internetprogramma, ook wel bekend als browser, weet prima raad met dat antwoord. Die kan elk van die drie talen begrijpen en omtoveren in de webpagina die jij uiteindelijk te zien krijgt op je apparaat.
Het belang van sessies voor webservers
Een webserver is een simpele machine. Als je naar een webpagina vraagt, dan geeft het antwoord. Jouw apparaat vertaald die codetekst om naar een mooie pagina die je begrijpt en kent.
Als je vervolgens een link aanklikt op die pagina, dan kom je op een nieuwe pagina. Het hele proces begint dan van vooraf aan weer opnieuw. Het nieuwe adres komt in de balk van je browser, je browser volgt routes door kabels, en je komt uiteindelijk weer uit bij een server die een antwoord geeft.
De server weet niets van jou of je apparaat. Het weet niet eens dat je net nog op de hompage was en dat je daar op een link hebt geklikt. Jouw vraag naar de tweede pagina is voor de webserver alsof een willekeurige andere persoon gewoon toevallig om die pagina vroeg.
Minimalisatie van onnodige dataoverdracht
En toen kwamen er sessies. Sessies hebben een enorme impact gehad op het internet. Sessies zijn technisch en lastig om veilig te doen als developer, maar de werking is doodeenvoudig. Sessies kunnen bestaan omdat cookies bestaan. Daar heb je vast al eens van gehoord. Cookies zijn kleine tekstbestanden die op je apparaat worden opgeslagen.
Webservers die sessies gebruiken, die vertellen je apparaat bij het openen van een pagina om ook even een cookie te plaatsen als deze al niet bestond op je apparaat. Die cookie is een tekstbestand en bevat bijvoorbeeld een unieke code. Een zogenaamde sessiecode. En je apparaat zal deze cookie met code bij elk bezoek aan dezelfde website ook weer meesturen naar de webserver.
Omdat de webserver nu niet alleen de vraagt krijgt naar een pagina, maar ook een sessiecode die als cookie op jouw apparaat was opgeslagen, kan de webserver je herkennen. Het weet nu dat je er eerder ook al was. Je hebt immers al eens een sessiecode gehad.
Doormiddel van sessiecodes in cookies kun je inloggen. Want als je inlogt op de homepage en dan naar een andere pagina gaat, dan zal je browser de sessiecode meesturen naar de server. De server heeft onthouden dat je ingelogd was, en zal op de nieuwe pagina óók laten zien dat je nog altijd ingelogd bent.
Een ander voorbeeld is het winkelwagentje. Als je iets aan je winkelwagen toevoegt, dan onthoudt de server dat je dit deed. En als je een andere pagina bezoekt en je sessiecode weer meegaat naar de server, dan weet de server dat hij op de nieuwe pagina in de winkelmand weer dezelfde spulletjes moet laten zien.
Richting volledig realtime communicatie
Maar naast je winkelwagen, en je accountpagina, is de rest van de pagina nog altijd voor iedereen hetzelfde. Het is hetzelfde antwoord van code, die je browser omtovert in de pagina die je ziet. En daar zit een hoop verspilling.
Stel een webwinkel heeft 10 producten. En jij bezoekt die pagina. Dan komt de code voor alle 10 producten van de webserver naar jouw computer.
Als de eigenaar van de webwinkel op dat moment een 11de product toevoegt, dan gebeurt er op jouw apparaat niks. Toen jij de pagina opvroeg waren er immers nog maar 10. De pagina op jouw beeld is dus een momentopname van toen je hem opende. Een soort foto van enkele minuten geleden.
Als je nu de pagina ververst, dan komt de volledig nieuwe code van de webserver naar je apparaat. En omdat er inmiddels 11 producten zijn, zie je er nu 11. En alle code voor alle 11 kwamen tijdens het verversen naar jou toe.
Wat natuurlijk veel efficiënter is, is om alleen het 11de product te krijgen. Die eerdere 10 wist je apparaat namelijk al van. Dus die code was niet meer nodig.
Een dieper begrip en gebruik van realtime mogelijkheden
Maar wat als de eigenaar niet een 11de product toevoegt, maar bijvoorbeeld de prijs van het 10de product wijzigt? In het huidige internet zie je die prijswijziging pas wanneer je de pagina vernieuwt. En je krijgt dan de code van de webserver voor alle 10 producten, waarbij alleen de prijs van het laatste product anders is.
Opnieuw verspilling. Want je apparaat kende al alle informatie van die producten. Het wist alleen niet dat de prijs van het 10de product was gewijzigd.
Conceptueel is het dus logischer om alleen de gewijzigde gegevens tussen jouw computer en de webserver uit te wisselen. Of het nu een 11de product is, of alleen de nieuwe prijs van het 10de product.
Hoewel een webtechniek genaamd "XMLHttpRequest" of soms afgekort tot "XHR" hierbij helpt, is het nog niet perfect. Met XHR kan een deel van de pagina worden bijgewerkt, terwijl de rest van de code hetzelfde blijft en dus niet opnieuw over het netwerk hoeft te worden verzonden.
Maar met XHR moet je apparaat de server vragen om een stukje nieuwe informatie. Het is eenrichtingsverkeer. En dit gebeurt vaak op basis van een aftellend klokje op jouw apparaat. Dit klokje begint bijvoorbeeld elke 10 seconden opnieuw af te tellen van 10 naar 0. En elke keer als het op 0 is, vraagt het de server om nieuwe informatie. Niet de hele pagina, maar wel een deel. En dan begint het aftellen weer vanaf 10. Deze techniek heet "long polling".
Zijn er al oplossingen beschikbaar?
Long polling is niet efficiënt. Het gebeurt bijvoorbeeld altijd elke 10 seconden, of er nu iets is veranderd of niet. En hoewel het maar een deel van de informatie aan de webserver vraagt, kan het dus zijn dat het urenlang elke 10 seconden de server vraagt om de meest actuele informatie terwijl er niets is gewijzigd. Dit is vooral vervelend voor mobiele apparaten, die hierdoor onnodig de batterij leegmaken.
Om die reden is er al tijden een nieuw concept. In plaats van dat je apparaat altijd de server om antwoord vraagt, of het nu bij het openen van de pagina is of terwijl je op die pagina bent met long-polling, is het veel slimmer als de server gewoon je apparaat laat weten wanneer er iets is veranderd. En tot die tijd hoeft je apparaat niets te doen of te vragen aan de webserver.
Twee technieken die hierbij helpen zijn Websockets en WebRTC. De eerste legt een verbinding tussen je apparaat en de webserver die in twee richtingen werkt, bidirectioneel dus, in tegenstelling tot het eenrichtingsverkeer eerder. En met WebRTC kan zelfs een bidirectionele verbinding worden gemaakt tussen jou en een heel ander apparaat, zonder dat de webserver er nog tussen zit. Dit laatste is vooral handig voor chat, spraak of video tussen twee internetgebruikers. Rechtstreeks. Zo wordt de server niet langer onnodig als tussenpersoon gebruikt.
Het cruciale laatste duwtje ontbreekt
Met bidirectioneel verkeer kan informatie dus op je apparaat aankomen zodra er iets is veranderd. En alleen de data die is veranderd. Dit is efficiënt en bespaart niet alleen onnodig verkeer maar ook energie aan beide kanten.
Dat klinkt alsof het opgelost is, toch? Niet helemaal. Helaas. Hoewel XHR inmiddels goed wordt ondersteund en veel wordt gebruikt, zijn Websockets en WebRTC dat nog niet. Hier zijn verschillende redenen voor, zowel technisch, bureaucratisch als commercieel.
De meeste webservers ter wereld gebruiken PHP. En PHP biedt standaard geen websockets aan. PHP is hiermee wel uit te breiden, maar dat gebeurt voornamelijk in interne proefopstellingen waar je als ontwikkelaar alle zeggenschap hebt. In de praktijk bieden hostingbedrijven amper tot geen PHP-extensie voor websockets aan.
Is NodeJS geen oplossing?
Dan is er nog NodeJS-hosting, een alternatief voor PHP-hosting. Het kan zelfs samen worden gebruikt, waarbij NodeJS als reverse-proxy voor PHP fungeert, terwijl NodeJS ook voor Websocket-communicatie zorgt. Maar dit wordt zelden aangeboden en kan soms erg prijzig zijn in vergelijking. Daarnaast zijn de populaire websitesystemen vaak niet gemaakt voor NodeJS. Een tweede server met NodeJS ernaast gebruiken betekent tevens onnodige kosten én doet ook de efficiëntie teniet omdat deze NodeJS-server nu "via de achterdeur" met de PHP-server moet communiceren. Vaak op een verzoek- of long-polling-basis. Dit ondermijnt precies het voordeel van het hele concept.
Naast de techniek is het ook belangrijk dat ontwikkelaars anders leren denken. Waar het web al decennia lang op de huidige stateless manier werkt, is deze manier van werken en denken totaal anders. Veel programmeurs zullen zelfs meteen zeggen: "Websockets? Dat is toch voor chat of zo?" Terwijl de bidirectionele methode die de webserver laat "pushen" veel verder kan gaan dan dat. Sterker nog, het kan de communicatie via netwerken wereldwijd ongekend drastisch verminderen én daarmee ook de energie die hiermee verloren gaat. Het kan wereldwijd letterlijk duizelingwekkend veel geld besparen, een veelvoud van miljarden in de globale IT-industrie. Maar alleen al de besparing aan energie kan een ongekende impact hebben op de wereld en de toekomst van IT.
Bidirectioneel met push is de toekomst
Een bidirectioneel internet, waarbij elke webserver alles naar de client kan pushen, is alsof we van kolenlocomotieven overstappen op groen opgewekte waterstoftreinen als het aankomt op energie. En alsof we overstappen van middeleeuws aderlaten naar moderne neurochirurgie als het aankomt op technologie. Het is eigenlijk best gek dat het nog niet beter wordt omarmd.