SSE vs WebSocket: welke realtime-optie gebruikt u | We.Inc
Server-sent events vs WebSockets: EventSource en WebSocket naast elkaar, herverbinden, binaire data, verbindingslimieten, een keuzehulp en minimale Node-servers voor beide.
Server-sent events streamen tekst van server naar browser via een gewone HTTP-response, en de EventSource API verbindt zelf opnieuw. Een WebSocket zet de verbinding om in een tweerichtingskanaal dat tekst of binaire data in beide richtingen vervoert. Gebruik SSE voor feeds, meldingen en voortgang; gebruik WebSockets als de browser vaak berichten terug moet sturen.
Naast elkaar
Kenmerk
Server-sent events
WebSocket
Richting
Alleen van server naar client
Beide kanten tegelijk
Browser-API
EventSource
WebSocket
Protocol
Gewoon HTTP, text/event-stream
HTTP Upgrade, daarna ws:// of wss://
Data
Alleen UTF-8-tekst
Tekst of binair
Herverbinden
Automatisch, hervat met Last-Event-ID
Schrijft u zelf
Open verbindingen op HTTP/1
6 per browser per domein
Aparte limieten, per browser bepaald
Weet u niet welke uw functie nodig heeft? Vink in de hulp hieronder de uitspraken aan die erop van toepassing zijn. Die past dezelfde regels toe als de tabel hierboven en zegt welke API past en waarom.
Vink elke uitspraak aan die uw functie beschrijft.
Lees de aanbeveling en de reden die erbij staat.
Kopieer de bijbehorende client- en servercode uit de secties verderop.
Vervang de URL en eventnamen door die van uzelf en draai de server met Node.
Stuur elke 15 tot 30 seconden een commentregel, een dubbele punt gevolgd door tekst, op een SSE-stream, zodat inactieve proxy's hem niet afkappen.
Geef elk SSE-event een id. Als de browser opnieuw verbindt, stuurt hij die waarde terug in de header Last-Event-ID, en uw server kan opnieuw afspelen wat gemist is.
Lever SSE waar mogelijk via HTTP/2, want de limiet van zes verbindingen van HTTP/1 wordt gedeeld door alle tabbladen die op uw site open staan.
Let bij WebSockets op bufferedAmount voordat u grote hoeveelheden tegelijk verstuurt; de API zelf heeft geen backpressure.
Veelgestelde vragen
Kan de browser met SSE data naar de server sturen?
Niet via de stream zelf. De event stream loopt alleen van server naar client, dus de browser stuurt zijn berichten met gewone fetch-requests. Voor chatachtig verkeer in beide richtingen past een WebSocket beter.
Hoe voorkom ik dat EventSource opnieuw verbindt?
Roep close() aan op de client. Vanaf de server zegt de HTML-standaard dat een response 204 No Content de client vertelt te stoppen met opnieuw verbinden.
Kan ik een Authorization-header meesturen met EventSource?
Nee. De constructor neemt alleen een URL en een options-object met als enige instelling withCredentials. Gebruik een cookie, een kortlevend token in de URL, of een lezer op basis van fetch als u eigen headers nodig hebt.
Is SSE achterhaald nu WebSockets bestaan?
Nee. Het formaat text/event-stream is nog steeds een goede keuze voor feeds in één richting, omdat het via normale HTTP-servers, proxy's en authenticatie loopt zonder protocolwissel.
Welke gebruikt minder serverbronnen?
Beide houden per client één langlevende verbinding open, dus het verschil is klein. Belangrijker is of uw host überhaupt langlevende responses of protocolupgrades toestaat, dus controleer eerst de limieten op de duur van requests.
Hoe server-sent events werken
De server beantwoordt een normale GET met Content-Type text/event-stream en houdt de response open. Elk bericht bestaat uit een paar regels zoals event:, data: en id:, afgesloten met een lege regel. Meerdere data:-regels in één bericht worden met regeleinden samengevoegd.
De EventSource van de browser parset die stream, vuurt een message-event af voor berichten zonder naam en een event met naam voor de rest, en verbindt na een onderbreking zelf opnieuw. Een retry:-regel stelt de wachttijd in milliseconden in voordat hij het opnieuw probeert.
Hoe WebSockets werken
De client begint met een HTTP-request met een Upgrade-header, en de server antwoordt 101 Switching Protocols. Vanaf dat moment vervoert de verbinding WebSocket-frames in plaats van HTTP, en beide kanten kunnen op elk moment versturen.
Die vrijheid heeft een prijs. U schrijft uw eigen herverbindingslogica, uw eigen berichtformaat, vaak JSON met een type-field, en uw eigen heartbeat. Een proxy die de Upgrade-header niet doorgeeft, stopt de verbinding bovendien al voordat die begint.
Een snelle vuistregel
Luistert de browser vooral, kies dan SSE. Live scores, buildlogs, bestelstatus, meldingen en gestreamde tekst passen allemaal.
Praat de browser evenveel als hij luistert, of is de data binair, kies dan een WebSocket. Multiplayergames, gezamenlijke editors en chatrooms passen daar allemaal.
Server-sent events: minimale code
SSE-server in gewoon Node
Geen library nodig. De response blijft open; elke write is één event, en de commentregel voorkomt dat inactieve proxy's hem sluiten.
EventSource in de browser
addEventListener gebruikt de eventnaam uit de stream. Herverbinden gebeurt zonder enige code van uzelf.
WebSocket: minimale code
WebSocket-server met het pakket ws
Installeer met npm install ws. Dit stuurt elk bericht in hoofdletters terug naar de client die het stuurde.
WebSocket in de browser, met eenvoudig herverbinden
Anders dan bij EventSource verbindt niets vanzelf opnieuw, dus dit wacht even na close en opent een nieuwe socket.
De browser stuurt veel berichten terug, meerdere per seconde of meer
De data is binair, zoals audiofragmenten of buffers met gamestatus
Clients moeten gemiste events inhalen na een verbroken verbinding
Verkeer gaat via proxy's of hosting die alleen gewoon HTTP aankunnen
Server-sent events passen. Niets wat u aanvinkte heeft een tweerichtingskanaal nodig, en EventSource geeft u gratis herverbinden en hervatten.
Een WebSocket past. U hebt vaak berichten van de browser of binaire data nodig, en die kan een event stream niet vervoeren.