SSE vs WebSocket: quale opzione real-time usare | We.Inc
Server-sent events vs WebSocket: EventSource e WebSocket a confronto, riconnessione, dati binari, limiti di connessione, un aiuto alla scelta e server Node minimi per entrambi.
I server-sent events inviano in streaming testo dal server al browser tramite una normale risposta HTTP, e l'API EventSource si riconnette da sola. Un WebSocket trasforma la connessione in un canale bidirezionale che trasporta testo o dati binari in entrambe le direzioni. Usa SSE per feed, notifiche e avanzamento; usa i WebSocket quando il browser deve inviare spesso messaggi di ritorno.
Fianco a fianco
Caratteristica
Server-sent events
WebSocket
Direzione
Solo dal server al client
In entrambe le direzioni contemporaneamente
API del browser
EventSource
WebSocket
Protocollo
HTTP semplice, text/event-stream
HTTP Upgrade, poi ws:// o wss://
Dati
Solo testo UTF-8
Testo o binario
Riconnessione
Automatica, riprende con Last-Event-ID
La scrivi tu
Connessioni aperte su HTTP/1
6 per browser per dominio
Limiti separati, fissati da ogni browser
Non sai quale dei due serve alla tua funzionalità? Spunta le affermazioni vere per il tuo caso nell'aiuto qui sotto. Applica le stesse regole della tabella qui sopra e ti dice quale API è adatta e perché.
Spunta ogni affermazione che descrive la tua funzionalità.
Leggi la raccomandazione e la motivazione che fornisce.
Copia il codice client e server corrispondente dalle sezioni più in basso.
Sostituisci l'URL e i nomi degli eventi con i tuoi ed esegui il server con Node.
Su uno stream SSE invia una riga di commento, i due punti seguiti da un testo, ogni 15-30 secondi così i proxy inattivi non lo interrompono.
Dai un id a ogni evento SSE. Quando il browser si riconnette rimanda quel valore nell'header Last-Event-ID, e il tuo server può reinviare ciò che è andato perso.
Servi SSE su HTTP/2 quando puoi, perché il limite di sei connessioni di HTTP/1 è condiviso tra tutte le schede aperte sul tuo sito.
Con i WebSocket, controlla bufferedAmount prima di inviare grandi raffiche di dati; l'API in sé non ha backpressure.
Domande frequenti
Con SSE il browser può inviare dati al server?
Non sullo stream stesso. Lo stream di eventi va solo dal server al client, quindi il browser invia i suoi messaggi con normali richieste fetch. Per un traffico in stile chat in entrambe le direzioni, un WebSocket è la soluzione più pulita.
Come impedisco a EventSource di riconnettersi?
Chiama close() sul client. Dal lato server, lo standard HTML stabilisce che una risposta 204 No Content dice al client di smettere di riconnettersi.
Posso inviare un header Authorization con EventSource?
No. Il costruttore accetta solo un URL e un oggetto di opzioni la cui unica impostazione è withCredentials. Usa un cookie, un token di breve durata nell'URL oppure un lettore basato su fetch se ti servono header personalizzati.
SSE è superato ora che esistono i WebSocket?
No. Il formato text/event-stream resta una buona scelta per i feed unidirezionali perché passa attraverso normali server HTTP, proxy e autenticazione senza alcun cambio di protocollo.
Quale dei due usa meno risorse del server?
Entrambi mantengono una connessione di lunga durata per client, quindi la differenza è piccola. Conta di più se il tuo hosting consente in generale risposte di lunga durata o upgrade di protocollo, quindi controlla prima i suoi limiti sulla durata delle richieste.
Come funzionano i server-sent events
Il server risponde a una normale GET con Content-Type text/event-stream e tiene aperta la risposta. Ogni messaggio è composto da poche righe come event:, data: e id:, chiuse da una riga vuota. Più righe data: in un messaggio vengono unite con un a capo.
L'EventSource del browser analizza quello stream, emette un evento message per i messaggi senza nome e un evento con nome per gli altri, e si riconnette da solo dopo un'interruzione. Una riga retry: imposta l'attesa in millisecondi prima di riprovare.
Come funzionano i WebSocket
Il client inizia con una richiesta HTTP che contiene un header Upgrade, e il server risponde 101 Switching Protocols. Da quel momento la connessione trasporta frame WebSocket, non HTTP, e ciascuna delle due parti può inviare in qualsiasi momento.
Questa libertà ha un costo. Scrivi tu la logica di riconnessione, il formato dei messaggi, spesso JSON con un campo type, e l'heartbeat. Anche un proxy che non inoltra l'header Upgrade blocca la connessione prima che inizi.
Una regola rapida
Se il browser soprattutto ascolta, scegli SSE. Risultati in diretta, log di build, stato degli ordini, notifiche e testo in streaming rientrano tutti qui.
Se il browser parla quanto ascolta, o i dati sono binari, scegli un WebSocket. Giochi multiplayer, editor collaborativi e chat room rientrano tutti lì.
Server-sent events: codice minimo
Server SSE in Node puro
Non serve nessuna libreria. La risposta resta aperta; ogni scrittura è un evento, e la riga di commento impedisce ai proxy inattivi di chiuderla.
EventSource nel browser
addEventListener usa il nome dell'evento dello stream. La riconnessione avviene senza alcun codice da parte tua.
WebSocket: codice minimo
Server WebSocket con il pacchetto ws
Installalo con npm install ws. Questo esempio rimanda ogni messaggio in maiuscolo al client che lo ha inviato.
WebSocket nel browser, con una semplice riconnessione
A differenza di EventSource, niente si riconnette per te, quindi questo codice attende un momento dopo la chiusura e apre un nuovo socket.
Il browser invia molti messaggi di ritorno, diversi al secondo o più
I dati sono binari, come blocchi audio o buffer dello stato di gioco
I client devono recuperare gli eventi persi dopo una connessione caduta
Il traffico passa attraverso proxy o hosting che gestiscono solo HTTP semplice
I server-sent events sono adatti. Nulla di ciò che hai spuntato richiede un canale bidirezionale, ed EventSource ti offre gratis riconnessione e ripresa.
Un WebSocket è adatto. Ti servono messaggi frequenti dal browser o dati binari, che uno stream di eventi non può trasportare.