Eén verbinding, beide richtingen

Met long polling kan de server antwoorden zodra er nieuws is, maar elk antwoord beëindigt een verzoek. Met Server-Sent Events kan de server blijven schrijven, maar alleen de server. Het scorebord heeft beide tegelijk nodig: kijkers die elke wijziging horen op het moment dat die gebeurt, en een scorebijhouder die scores stuurt wanneer een vraag is nagekeken. Een WebSocket is de verbinding die precies daarvoor is gebouwd. Deze les somt op wat hij biedt, en de rest van de cursus bouwt hem.

Vier dingen die een WebSocket biedt

1. Eén verbinding die open blijft. Een kijker maakt één keer verbinding, aan het begin van de avond, en houdt dezelfde TCP-verbinding tot de quiz afloopt. Voor het volgende stukje nieuws is geen nieuw verzoek nodig.

2. Beide kanten mogen op elk moment sturen. Dit heet full duplex. De server stuurt een scorewijziging op het moment dat die gebeurt, zonder te wachten tot erom gevraagd wordt, en een client stuurt wanneer hij iets te zeggen heeft, zonder op de server te wachten. Geen van beide berichten is een antwoord op het andere.

3. Data komt aan als hele berichten. Je weet uit Networks with Python dat TCP een stroom bytes zonder grenzen is: twee berichten die na elkaar worden verstuurd, kunnen aan elkaar geplakt of in stukken aankomen. Daarom verpakt een WebSocket elk bericht in een frame, ongeveer zoals je protocol met lengteprefix in die cursus een lengte voor elk bericht zette. De lezer krijgt Owls 12 als één bericht, nooit Ow en daarna ls 12. Hoofdstuk 3 haalt die frames byte voor byte uit elkaar.

4. Hij begint als een HTTP-verzoek. De client opent een verbinding naar dezelfde poorten als HTTP en stuurt eerst een gewoon HTTP-verzoek, zodat alles wat al met HTTP omgaat een vertrouwd begin van een paar bytes ziet. Dat verzoek vraagt de server om de verbinding over te schakelen naar het WebSocket-protocol, en als de server instemt, draagt dezelfde verbinding vanaf dan WebSocket-berichten. Die overschakeling heet de openingshandshake.

Punt 1 en 2 zijn wat long polling en Server-Sent Events je niet samen konden geven. Punt 3 maakt een langlevende verbinding bruikbaar voor berichten, en punt 4 is hoe ze op gang komt zonder dat er iets nieuws tussen client en server nodig is.

Wat een bericht kost

Zodra de verbinding open is, draagt een bericht heel weinig naast zijn eigen bytes. De framing voor een bericht dat de server stuurt, tot 125 bytes lang, is 2 bytes. Een bericht van een client naar een server draagt er 6, omdat clients een maskeersleutel van 4 bytes toevoegen die hoofdstuk 4 uitlegt. De grootste framing die een bericht kan dragen is 14 bytes, voor heel grote berichten van een client.

Vergelijk dat met één lege poll uit les 2: een verzoekregel, een Host-header en een If-None-Match-header heen, en een statusregel en een ETag-header terug, allemaal om te horen dat er niets veranderd is. De verzoekregel GET /scores HTTP/1.1 alleen is al 20 bytes vóór het regeleinde, en de frameheader van een kort bericht is 2. Op een WebSocket hoeft niemand te vragen, dus een minuut zonder nieuws stuurt helemaal geen verzoeken.

Vier technieken naast elkaar

In de afbeelding krijgt elke techniek twee tijdlijnen, de client boven en de server onder, met de tijd naar rechts; een ruit is een scorewijziging. Volg elke ruit naar de pijl die hem naar de client brengt.

De tabel zegt hetzelfde in kolommen:

Door de tabel lijkt de WebSocket elke keer de winnaar, en dat is hij niet. Polling is de eenvoudigste van de vier, en als nieuws zeldzaam is, kosten een paar verzoeken per uur bijna niets. Server-Sent Events passen goed als alleen de server nieuws heeft. Een WebSocket is zijn extra machinerie waard als beide kanten vaak praten.

Een WebSocket begint als een gewoon HTTP-verzoek, en een HTTP-verzoek verwacht één antwoord en is dan klaar. Hoe kan dat verzoek veranderen in een verbinding die nooit eindigt? Dat is het raadsel van hoofdstuk 2, waarin je beide kanten van de openingshandshake zelf schrijft.