WebSocket vs. eventi server inviati / EventSource

839

Sia WebSocket che Server-Sent Events sono in grado di inviare dati ai browser. Per me sembrano essere tecnologie concorrenti. Qual'è la differenza tra loro? Quando sceglieresti l'uno rispetto all'altro?

html  browser  websocket  server-sent-events 
— Mads Mobæk
fonte
2
Non sono sicuro di come li vedi come concorrenti. Uno è sincrono e potrebbe / sarebbe usato per lo xfer di dati quasi in tempo reale, mentre l'altro è asincrono e servirebbe a uno scopo completamente diverso (invio efficace di messaggi tipo toast da un'app lato server).
— Brian Driscoll,
54
WebSocket è bidirezionale, può inviare dati al server.
— Andre Backlund
13
Una cosa che mi piace davvero di SSE è che è facile risolvere i problemi ... basta aprire una richiesta al server SSE usando curl. Dal momento che è solo un formato di testo su HTTP, è facile vedere cosa sta succedendo.
— Sam,
7
@BrianDriscoll - asincrono / sincrono - quale è quale? Per quanto posso capire entrambi abilitare i trasferimenti asincroni?
— Dave Everitt,
5
SSE non funziona su IE, websocket funziona
— Tyler Gillies il

Risposte:

979

Websocket e SSE (Server Sent Events) sono entrambi in grado di inviare dati ai browser, tuttavia non sono tecnologie concorrenti.

Le connessioni WebSocket possono sia inviare dati al browser sia ricevere dati dal browser. Un buon esempio di un'applicazione che potrebbe utilizzare websocket è un'applicazione di chat.

Le connessioni SSE possono solo inviare dati al browser. Le quotazioni di borsa online o la cronologia dei feed o i feed di Twitter sono buoni esempi di un'applicazione che potrebbe beneficiare di SSE.

In pratica poiché tutto ciò che può essere fatto con SSE può essere fatto anche con Websocket, Websocket sta ricevendo molta più attenzione e amore e molti più browser supportano Websocket rispetto a SSE.

Tuttavia, può essere eccessivo per alcuni tipi di applicazione e il back-end potrebbe essere più semplice da implementare con un protocollo come SSE.

Inoltre SSE può essere riempito con il polyfill nei browser più vecchi che non lo supportano in modo nativo usando solo JavaScript. Alcune implementazioni dei polyfill SSE sono disponibili nella pagina github di Modernizr .

Trabocchetti:

  • SSE soffre di una limitazione al numero massimo di connessioni aperte, che può essere particolarmente doloroso quando si aprono varie schede poiché il limite è per browser e impostato su un numero molto basso (6). Il problema è stato contrassegnato come "Non risolto" in Chrome e Firefox . Questo limite è per browser + dominio, quindi ciò significa che puoi aprire 6 connessioni SSE su tutte le schede www.example1.come altre 6 connessioni SSE www.example2.com(grazie a Phate).
  • Solo WS può trasmettere sia dati binari che UTF-8, SSE è limitato a UTF-8. (Grazie a Chado Nihi).
  • Alcuni firewall aziendali con ispezione dei pacchetti hanno difficoltà a gestire WebSocket (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).

HTML5Rocks ha alcune buone informazioni su SSE. Da quella pagina:

Eventi inviati dal server vs. WebSocket

Perché dovresti scegliere Server-Sent Events over WebSocket? Buona domanda.

Uno dei motivi per cui gli SSE sono stati tenuti all'ombra è perché le API successive come WebSocket forniscono un protocollo più ricco per eseguire comunicazioni bidirezionali e full duplex. Avere un canale a due vie è più attraente per cose come giochi, app di messaggistica e per i casi in cui hai bisogno di aggiornamenti quasi in tempo reale in entrambe le direzioni. Tuttavia, in alcuni scenari i dati non devono essere inviati dal client. Hai semplicemente bisogno di aggiornamenti da alcune azioni del server. Alcuni esempi potrebbero essere gli aggiornamenti dello stato degli amici, i ticker delle azioni, i feed di notizie o altri meccanismi automatici di push dei dati (ad esempio l'aggiornamento di un database SQL Web sul lato client o un archivio oggetti IndexedDB). Se devi inviare dati a un server, XMLHttpRequest è sempre un amico.

Gli SSE vengono inviati tramite HTTP tradizionale. Ciò significa che non richiedono un protocollo speciale o un'implementazione del server per funzionare. D'altra parte, i WebSocket richiedono connessioni full duplex e nuovi server Web Socket per gestire il protocollo. Inoltre, gli Eventi Server-Sent hanno una varietà di funzionalità che WebSocket manca in base alla progettazione, come la riconnessione automatica, gli ID evento e la possibilità di inviare eventi arbitrari.

Riepilogo TLDR:

Vantaggi di SSE rispetto ai websocket:

  • Trasportato su HTTP semplice anziché su un protocollo personalizzato
  • Può essere poli-riempito con javascript per "backport" SSE su browser che non lo supportano ancora.
  • Supporto integrato per ricollegamento e ID evento
  • Protocollo più semplice
  • Nessun problema con i firewall aziendali che effettuano l'ispezione dei pacchetti

Vantaggi di Websocket su SSE:

  • Tempo reale, comunicazione bidirezionale.
  • Supporto nativo in più browser

Casi d'uso ideali di SSE:

  • Streaming ticker stock
  • aggiornamento feed Twitter
  • Notifiche al browser

Gotcha SSE:

  • Nessun supporto binario
  • Limite massimo di connessioni aperte
— Alex Recarey
fonte
131
La chat è perfettamente realizzabile con SSE: puoi utilizzare il normale POST per inviare messaggi al server. I WebSocket sarebbero necessari solo se stai implementando la chat su Google Wave.
— Kornel,
135
È vero che la chat e altre applicazioni in tempo reale possono essere eseguite con SSE. Tuttavia, ciò richiede che le risposte POST siano "fuori banda", vale a dire che questo non è controllato dal protocollo SSE e non sembra un buon esempio per una spiegazione di base sulle differenze tra SSE e Websocket. È possibile implementare la chat con il polling HTTP di base del server ogni secondo e INVIARE nuove risposte. Questo non significa che sia il modo migliore / più elegante per farlo.
— Alex Recarey,
14
Penso che la soluzione di pomeL sia un ottimo compromesso per la maggior parte dei casi, poiché JS può sempre "spingere" le cose sul server con un POST AJAX. In base alla mia esperienza, il problema principale è stato in genere la necessità per JS di effettuare il polling per nuove informazioni, ma SSE se ne occupa. : D
— Jacob Pritchett
12
@MattDiPasquale Wave ha inviato ogni chiave singolarmente durante la digitazione anziché il messaggio completo in una sola volta. 200 byte di overhead POST per 1 sequenza di tasti sarebbero dispendiosi rispetto a circa 6 per WebSocket.
— Kornel,
9
Sembra un po 'strano dire che non sono tecnologie concorrenti, e quindi procedere a descrivere che entrambi possono essere utilizzati per ottenere soluzioni simili. Direi che li rende in competizione.
— Alex,
115

Secondo caniuse.com:

È possibile utilizzare un polyfill solo client per estendere il supporto di SSE a molti altri browser. Ciò è meno probabile con WebSocket. Alcuni polyfill di EventSource:

Se è necessario supportare tutti i browser, prendere in considerazione l'utilizzo di una libreria come web-socket-js , SignalR o socket.io che supportano più trasporti come WebSocket, SSE, Forever Frame e polling lungo AJAX. Questi spesso richiedono anche modifiche sul lato server.

Ulteriori informazioni su SSE da:

Ulteriori informazioni su WebSocket da:

Altre differenze:

  • WebSocket supporta dati binari arbitrari, SSE utilizza solo UTF-8
— Drew Noakes
fonte
3
Vorrei sottolineare nel 2016> il 95% degli utenti globali supporta nativamente WebSocket. Tutti i browser e i dispositivi supportano WebSocket da oltre 4 anni. Socket.IO riporterà al polling AJAX lungo e gestirà le complessità dell'emulazione di WebSocket se non è supportato, il che rende il supporto al 100%. Se stai usando qualcosa di diverso da WebSocket nel 2016, stai utilizzando una tecnologia obsoleta.
— Nick Steele,
3
@NickSteele Questa è una dichiarazione hype di cazzate. Affidarsi a standard più vecchi va perfettamente bene se soddisfano il tuo caso d'uso e non significa che nulla sia obsoleto. È solo uno standard diverso. Esempio: XHR può ancora fare un sacco di cose che l'API Fetch non può fare, quindi non è obsoleta. È diverso. Ho usato WS in passato, ma so per esperienza che si possono colpire ostacoli sotto forma di firewall aziendali a rumore che bloccano le richieste quando non capiscono WS. SSE è super efficiente per quello che fa, è banalmente comprensibile e implementabile e facile da eseguire il debug. Per il nostro flusso di dati unidirezionale, è perfetto.
— Oligofren,
@oligofren Non c'è bisogno di imprecare. Se qualcosa è progettato per sostituire la versione precedente, ed è accettato dal settore e migliore in ogni modo, per definizione, il vecchio metodo è obsoleto. Proprio come l'iPhone originale è obsoleto, così come XHR. XHR è uscito prima di Firefox, Chrome, il primo iPhone, prima di YouTube, Netflix, Facebook e persino MySpace. Quando XHR uscì, Windows 98 era il miglior sistema operativo, AOL era il miglior provider e JSON non esisteva nemmeno. WebSocket ha sostituito XHR quasi un decennio fa. Se colpisci gli snag usando WS, anche ciò che ha causato lo snag è obsoleto. Non ci sono scuse per ritardare così lontano.
— Nick Steele,
4
Sostituisci BS con hyperbole quindi :-) WS non è un sostituto per XHR / HTTP non più di quanto lo siano i droni per le auto da consegna. Sono diversi casi d'uso. WS non è HTTP e ha diversi punti deboli. Si finirebbe per reimplementare HTTP (male) nello spazio utente se si provasse. Inoltre, stai insinuando cose alle quali non vengono dati fatti: WS è semplicemente un protocollo bidirezionale che supporta il push del server. Non ho mai visto documenti di design menzionare che è stato sviluppato come sostituto di qualcosa. Fonte? L'età in sé non è un fattore. Quando ti viene data la scelta, scegli l'implementazione più semplice verificando tutti i tuoi requisiti.
— oligofren,
1
Solo due anni fa (2017) stavo eseguendo il debug di dump di heap dei processi Node JS in cui il codice Socket.io stava causando un'enorme frammentazione della memoria nel processo IIS, finendo per parlare direttamente con il team Node di Azure. La complessità totale non è gratuita. Se riesci a cavartela con un semplice script a 20 righe come dipendenza dal server, pur potendo servire 100.000 client, ci proverei. Adoro WS per quello che fa, però, ma guarda cosa ti serve prima di scegliere una soluzione.
— oligofren,
16

Opera, Chrome, Safari supporta SSE, Chrome, Safari supporta SSE all'interno di SharedWorker Firefox supporta XMLHttpRequest readyState interattivo, così possiamo rendere EventSource polyfil per Firefox

— yaffle
fonte
8

Websocket VS SSE

Web Socket: è un protocollo che fornisce un canale di comunicazione full duplex su una singola connessione TCP. Ad esempio una comunicazione a due vie tra il server e il browser Poiché il protocollo è più complicato, il server e il browser devono fare affidamento sulla libreria di websocket che èsocket.io

Example - Online chat application.

SSE (Server-Sent Event) - In caso di evento server inviato la comunicazione viene effettuata solo dal server al browser e il browser non può inviare alcun dato al server. Questo tipo di comunicazione viene utilizzato principalmente quando è necessario solo mostrare i dati aggiornati, quindi il server invia il messaggio ogni volta che i dati vengono aggiornati. Ad esempio una comunicazione unidirezionale tra il server e il browser. Questo protocollo è meno complicato, quindi non è necessario fare affidamento sulla libreria esterna che JAVASCRIPT stesso fornisce l' EventSourceinterfaccia per ricevere i messaggi inviati dal server.

Example - Online stock quotes or cricket score website.
— Gaurav Tiwari
fonte
4

Una cosa da notare:
ho avuto problemi con i websocket e i firewall aziendali. (L'uso di HTTPS aiuta ma non sempre.)

Vedi https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94

Io presumo non ci sono così tanti problemi con Eventi Server-Sent. Ma non lo so.

Detto questo, i WebSocket sono molto divertenti. Ho un piccolo gioco Web che utilizza websocket (tramite Socket.IO) ( http://minibman.com )

— Drew LeSueur
fonte
1
Ho anche avuto problemi con i firewall aziendali.
— Oligofren,
1
Un problema che ho riscontrato con Server-Sent Events è che alcuni proxy / firewall potrebbero bloccarlo perché non ha un'intestazione Content-Length
— Drew LeSueur
2

Ecco un discorso sulle differenze tra socket Web ed eventi inviati dal server. Da Java EE 7 un'API WebSocket fa già parte delle specifiche e sembra che gli eventi inviati dal server verranno rilasciati nella prossima versione dell'edizione enterprise.

— Patrick Leitermann
fonte
-3

Il limite massimo di connessione non è un problema con http2 + sse.

È stato un problema su http 1

— user1948585
fonte
Http2 consente a più richieste sullo stesso dominio di essere trattate come flussi. Questa tecnica si chiama multiplexing. Ciò consente di risparmiare i limiti di connessione del browser per dominio, motivo per cui le persone eseguono lo sharding del dominio con Http1.
— user1948585
1
Anche i flussi HTTP / 2 hanno un numero limitato, questo protegge i server dall'essere bombardati da un singolo browser e costringe i browser a limitare il loro multiplexing a un numero limitato di flussi - che, nel nostro caso, è uguale alle connessioni HTTP / 1.1. che ti riporta al limite di connessione SSE.
— Myst,
Presumo che la connessione websocket consumi anche le risorse del server. samsaffron.com/archive/2015/12/29/websockets-caution-required . È sempre utile avere la possibilità di configurare tutto ciò che la tasca consente.
— user1948585
è probabile che SSE consumerà risorse simili sulla maggior parte dei server (se non più risorse a causa dello stack HTTP ancora presente e dei suoi limiti).
— Myst,
1
Questa risposta è corretta Il limite di 6 connessioni HTTP non esiste più quando si utilizza HTTP / 2. Prova: codepen.io/dunglas/pen/yLYxdxK?editors=1010 Con HTTP / 2, dipende dal server e il client può negoziare il numero massimo di stream simultanei (100 per impostazione predefinita).
— Kévin Dunglas,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.