Een klant stelt een vraag in de chat terwijl een medewerker de voorraad controleert. De medewerker antwoordt, maar de tekst verschijnt pas veel later op het scherm. Het beeld van de website staat ondertussen gewoon stil. De vertraging zit dus niet noodzakelijk in het laden van de pagina. Interactieve webapps moeten ook na het openen gegevens blijven uitwisselen.
Die uitwisseling wordt lastiger wanneer veel bezoekers tegelijk actief zijn. Een snelle verbinding voor één gebruiker zegt weinig over de capaciteit voor duizenden gelijktijdige verbindingen. De toepassing moet berichten ontvangen, beoordelen en doorsturen zonder dat wachtrijen blijven groeien.
Een open verbinding voorkomt herhaald navragen
Een gewone webpagina kan gegevens opvragen met een verzoek aan de server. De server antwoordt en de browser toont het resultaat. Een toepassing die voortdurend nieuwe informatie nodig heeft, kan die vraag regelmatig herhalen. Dat heet polling. Een groot aantal bezoekers kan daardoor veel verzoeken veroorzaken, ook wanneer er niets veranderd is.
WebSockets bieden een andere werkwijze. De browser en de server houden een verbinding open waarover beide berichten kunnen sturen. Een nieuwe chatreactie hoeft dan niet te wachten op de volgende geplande vraag van de browser. Die werkwijze is geschikt voor gegevens die tijdens het bezoek blijven veranderen.
Een webapp met live casino Nederland brengt bijvoorbeeld livebeelden en interactieve functies samen op een scherm. De techniek voor de videostream hoeft daarbij niet dezelfde te zijn als die voor chat of andere berichten. De zichtbare pagina is onvoldoende om vast te stellen welk protocol een specifieke aanbieder gebruikt.
Een webshop met wandkleden heeft weer andere behoeften. De productpagina kan grotendeels gewoon worden geladen. Een eventuele chat of melding over een lopende bestelling kan een afzonderlijk kanaal gebruiken. Een ontwikkelaar hoeft daarom niet de hele website op WebSockets te laten draaien om één interactieve functie toe te voegen.
Een open verbinding maakt een toepassing niet automatisch snel.
De server kan nog steeds tijd nodig hebben om een bericht te verwerken of gegevens uit een database te halen. De browser kan het ontvangen bericht vervolgens te laat weergeven omdat andere code de uitvoering bezighoudt. De meting moet daarom de volledige reis van een handeling volgen, van invoer tot zichtbare bevestiging.
Veel bezoekers vragen om gerichte distributie
Een server die iedere wijziging naar iedere bezoeker stuurt, verstuurt veel onnodige gegevens. Een chatbericht hoort alleen bij het betreffende gesprek. Een voorraadmelding kan beperkt blijven tot de bekeken producten. De toepassing kan daarvoor werken met kanalen of abonnementen. De gebruiker ontvangt dan alleen gebeurtenissen waarvoor hij is aangemeld en waarvoor hij toegang heeft.
Een voorbeeld maakt de belasting concreet. Stel dat een toepassing 5.000 verbonden bezoekers heeft en twintig updates per seconde verstuurt. Verzending van elke update naar iedereen levert 100.000 afzonderlijke berichtleveringen per seconde op. Alleen versturen naar de honderd betrokken bezoekers beperkt dat tot 2.000. Dit is een rekenvoorbeeld, geen uitspraak over de capaciteit van een bepaald systeem.
Een groeiende dienst kan de verbindingen over meerdere servers verdelen. Die servers moeten dan wel informatie kunnen uitwisselen. Een chatbericht dat op server A binnenkomt, moet ook de juiste ontvanger op server B kunnen bereiken. Een gedeeld berichtensysteem kan die verspreiding verzorgen. De inrichting daarvan hangt af van de gewenste leveringszekerheid en de hoeveelheid verkeer.
Een ontwerper maakt daarbij onderscheid tussen berichten die bewaard moeten blijven en tijdelijke updates. Een verzonden bestelling mag niet stilzwijgend verdwijnen. De aanwijzing dat iemand op dat moment aan het typen is, kan na een korte onderbreking juist achterhaald zijn. Alle berichten op dezelfde manier behandelen verspilt capaciteit of geeft onvoldoende zekerheid.
De ontvanger moet de berichten kunnen bijhouden
Een verbinding kan meer berichten afleveren dan de browser direct kan verwerken. De wachtrij groeit dan, terwijl het scherm steeds oudere informatie laat zien. Een ouder toestel kan daar eerder tegenaan lopen dan een krachtige laptop. Extra servers aan de andere kant verhelpen dat probleem niet vanzelf.
De MDN documentatie over WebSockets wijst erop dat de gewone WebSocket interface geen ingebouwde backpressure biedt. De toepassing moet dus zelf rekening houden met een ontvanger die het verkeer niet bijhoudt. Een ontwikkelaar kan bijvoorbeeld tijdelijke updates samenvoegen, de frequentie beperken of een verbinding met een te grote achterstand gecontroleerd opnieuw laten beginnen.
Drie soorten berichten vragen om verschillende keuzes
- Een nieuw chatbericht moet in de juiste volgorde in het gesprek terechtkomen.
- Een actuele status kan vaak worden vervangen door de meest recente waarde.
- Een bevestiging van een handeling moet herkenbaar gekoppeld zijn aan die specifieke handeling.
De browser hoeft ook niet ieder ontvangen bericht onmiddellijk als afzonderlijke wijziging te tekenen. Meerdere updates kunnen in één schermverversing worden verwerkt. Die aanpak is alleen geschikt wanneer de toepassing geen noodzakelijke tussenstappen weglaat. De inhoud van het bericht bepaalt welke verwerking verantwoord is.
Een verbroken verbinding hoort bij het ontwerp
Een telefoon wisselt van wifi naar mobiel internet. Een laptop gaat dicht en komt later uit de slaapstand. De toepassing moet zulke onderbrekingen verwachten. Een nieuwe verbinding herstelt niet automatisch de berichten die tijdens de onderbreking zijn gemist.
Een toepassing kan berichten een volgnummer geven en bijhouden welk nummer de gebruiker heeft ontvangen. De server kan ontbrekende berichten opnieuw leveren wanneer de opslag en de gekozen inrichting dat ondersteunen. Een andere mogelijkheid is het ophalen van de volledige actuele toestand. De gebruiker ziet dan bijvoorbeeld opnieuw de huidige bestelling, in plaats van iedere tussentijdse statuswijziging.
Een herstelde verbinding vraagt opnieuw om controle van de toegangsrechten. De server mag niet aannemen dat een eerder toegelaten gebruiker nog steeds toegang heeft tot hetzelfde gesprek of account. Een beëindigde sessie moet ook voor het berichtenkanaal gevolgen hebben. Een melding in de browser dat iemand is uitgelogd, sluit een achterliggende verbinding niet vanzelf af. De toepassing moet die afspraak zelf uitvoeren en testen.
Alle browsers tegelijk opnieuw laten verbinden kan na een storing een nieuwe piek veroorzaken. Een wachttijd die geleidelijk oploopt en per gebruiker iets varieert, spreidt die verzoeken.
Een belastingstest moet daarom ook een onderbreking bevatten. De tester laat een groep verbindingen wegvallen en controleert de heraansluiting, de ontbrekende berichten en eventuele dubbele handelingen. De uitkomst moet laten zien dat de toepassing niet alleen snel reageert wanneer alles werkt, maar ook een begrijpelijke status geeft terwijl de verbinding wordt hersteld.
