2012-11-07 24 views
9

Recentemente ho scoperto che gli eventi Server-Sent sono un'alternativa molto più semplice ai WebSockets per eseguire push dal server. La maggior parte dei luoghi che li confronta (come here, here e here) dicono che se non si ha bisogno di comunicazioni full duplex tra client e server, allora WebSockets è eccessivo e SSE è abbastanza buono.Lato negativo dell'utilizzo di eventi inviati dal server per comunicazioni client-server bidirezionali (anziché WebSockets)

La mia domanda è quale sarebbe il lato negativo dell'utilizzo di SSE quando si ha bisogno di comunicazioni bidirezionali (come una chat, ad esempio), utilizzando regolari richieste Ajax per l'invio di messaggi dal client e il flusso del server per la ricezione? Considerando che devo fare poca o nessuna configurazione sul lato server per usare SSE, sembra essere un'opzione molto più accattivante.

risposta

14

SSE Vantaggi oltre WebSockets:

  • Non sono richieste particolari web server o proxy Web modifiche necessarie.
  • definire gli eventi personalizzati (in caso contrario, client API è fondamentalmente lo stesso)
  • più facile integrazione di meccanismi di autenticazione esistenti (OAuth, OpenID, ecc)

SSE Svantaggi rispetto al WebSockets:

  • Canale di comunicazione unidirezionale (da server a client). Il client al server richiede un canale separato.
  • supporto del browser è più limitata (nessun supporto nativo IE mentre WebSockets è supportato in IE 10): WebSockets, SSE
  • Si basa sul client per verificare l'origine (forse più vulnerabile agli attacchi XSS di WebSockets)
  • Nessun supporto nativo per i tipi binari (WebSockets supporta i frame grezzi usando ArrayBuffer e Blob).
  • Richiede un completo web server a tutti gli effetti, anche se l'endpoint SSE non è al servizio del contenuto web statico (un server WebSocket autonomo può essere abbastanza semplice)
  • SSE con AJAX per la comunicazione bidirezionale avrà una latenza di andata e ritorno molto più alto e maggiore larghezza di banda client-> server rispetto all'utilizzo di una connessione WebSocket. Ciò è dovuto al sovraccarico dell'installazione della connessione per ogni richiesta client -> server AJAX. Inoltre, server-> la latenza del client può avere picchi con SSE poiché in molte configurazioni la connessione a lungo termine verrà chiusa (spesso ogni 30 secondi) e dovrà essere riaperta causando un picco temporaneo anche in server-> latenza del client .

Riferimenti:

+2

Ottimi punti, ma non sono abbastanza d'accordo sulla complessità di un server standalone. Il protocollo SSE è semplice: molto più semplice di WebSockets (nessuna stretta di mano, framing, masking, binary). In entrambi i casi è necessario analizzare le intestazioni HTTP (-like). È possibile implementare il server SSE in uno script bash :) – Kornel

+0

@porneL, hai ragione, un server SSE di base potrebbe essere abbastanza semplice da implementare (anche se mi piacerebbe vedere la tua versione di bash), ma lo è anche un server WebSocket di base. Ma a prescindere, il mio punto non era che i server WebSocket sono più semplici, ma che SSE di solito assume un server web mentre WebSockets non lo fa (sebbene sia certamente progettato per integrarsi facilmente con l'infrastruttura web esistente). – kanaka

2

Le richieste Ajax sono enormi rispetto ai piccoli messaggi WebSocket. Le richieste HTTP standard (Ajax) includono molte intestazioni tra cui i cookie con ogni richiesta mentre i messaggi WebSocket sono solo pochi byte.

La cosa buona con la richiesta HTTP (Ajax) è che sono più facili da memorizzare nella cache se questo è un vantaggio per il tuo problema.

+0

Per la comunicazione bidirezionale, essendo in grado di memorizzare nella cache richieste AJAX non sta per essere utile . Se si utilizza AJAX per caricare in modo asincrono immagini o altri dati statici, la memorizzazione nella cache sarebbe utile, ma ciò vale per server-> comunicazione client e non aiuta con client-> server, che è ciò per cui AJAX viene utilizzato in questo scenario. – kanaka