Pregunta WebSockets frente a eventos enviados por el servidor / EventSource


Ambos WebSockets y Eventos enviados por el servidor son capaces de enviar datos a los navegadores. Para mí, parecen ser tecnologías competitivas. ¿Cuál es la diferencia entre ellos? ¿Cuándo elegirías uno sobre el otro?


622
2018-03-04 15:07


origen


Respuestas:


Websockets y SSE (eventos enviados por el servidor) son capaces de enviar datos a los navegadores, sin embargo, no son tecnologías competitivas.

Las conexiones de Websockets pueden enviar datos al navegador y recibir datos del navegador. Un buen ejemplo de una aplicación que podría usar websockets es una aplicación de chat.

Las conexiones SSE solo pueden enviar datos al navegador. Las cotizaciones bursátiles en línea o los twitters que actualizan la línea de tiempo o el feed son buenos ejemplos de una aplicación que podría beneficiarse de la SSE.

En la práctica, ya que todo lo que se puede hacer con SSE también se puede hacer con Websockets, Websockets recibe cada vez más atención y amor, y muchos navegadores más soportan Websockets que SSE.

Sin embargo, puede ser excesivo para algunos tipos de aplicaciones, y el back-end podría ser más fácil de implementar con un protocolo como SSE.

Además, SSE se puede rellenar en navegadores más antiguos que no lo admiten de forma nativa utilizando solo JavaScript. Algunas implementaciones de polyfills SSE se pueden encontrar en Página de modernizr github.

Gotchas:

  • SSE adolece de una limitación para la cantidad máxima de conexiones abiertas, lo que puede ser especialmente doloroso al abrir varias pestañas, ya que el límite es por navegador y establecer a un número muy bajo (6). El problema se marcó como "No se solucionará" en Cromo y Firefox
  • Solo WS puede transmitir datos binarios y UTF-8, SSE está limitado a UTF-8. (Gracias a Chado Nihi).

HTML5Rocks tiene buena información sobre SSE. Desde esa página:

Eventos enviados por el servidor vs. WebSockets

¿Por qué elegirías Eventos enviados por el servidor sobre WebSockets? Buena pregunta.

Una razón por la cual las SSEs se han mantenido a la sombra es porque las API posteriores, como WebSockets, proporcionan un protocolo más rico para realizar una comunicación bidireccional de dúplex completo. Tener un canal bidireccional es más atractivo para cosas como juegos, aplicaciones de mensajería y para casos en los que necesita actualizaciones casi en tiempo real en ambas direcciones. Sin embargo, en algunos casos, los datos no necesitan ser enviados por el cliente. Simplemente necesita actualizaciones de alguna acción del servidor. Algunos ejemplos serían las actualizaciones de estado de los amigos, los tickers de acciones, los feeds de noticias u otros mecanismos automáticos de envío de datos (por ejemplo, la actualización de una base de datos Web SQL del lado del cliente o un almacén de objetos IndexedDB). Si necesita enviar datos a un servidor, XMLHttpRequest siempre es un amigo.

Las SSE se envían a través de HTTP tradicional. Eso significa que no requieren un protocolo especial o implementación de servidor para funcionar. WebSockets, por otro lado, requieren conexiones full-duplex y nuevos servidores Web Socket para manejar el protocolo. Además, los eventos enviados por el servidor tienen una variedad de características que los WebSockets carecen por diseño, como la reconexión automática, identificaciones de eventos y la capacidad de enviar eventos arbitrarios.


Resumen de TLDR:

Ventajas de SSE sobre Websockets:

  • Transportado sobre HTTP simple en lugar de un protocolo personalizado
  • Puede rellenarse con javascript para "respaldar" SSE a navegadores que aún no lo admiten.
  • Soporte integrado para reconexión y evento-id
  • Protocolo simple

Ventajas de Websockets sobre SSE:

  • Tiempo real, comunicación bidireccional.
  • Soporte nativo en más navegadores

Casos de uso ideal de SSE:

  • Transferencia de cotizaciones bursátiles
  • actualización de feed de Twitter
  • Notificaciones al navegador

Errores de SSE:

  • Sin soporte binario
  • Límite máximo de conexiones abiertas

716
2018-03-16 13:40



De acuerdo con caniuse.com:

Puede usar un polyfill solo para clientes para extender el soporte de SSE a muchos otros navegadores. Esto es menos probable con WebSockets. Algunos polyfills de EventSource:

Si necesita admitir todos los navegadores, considere usar una biblioteca como web-socket-js, SignalR o socket.io que admiten múltiples transportes como WebSockets, SSE, Forever Frame y AJAX Long Polling. A menudo también requieren modificaciones en el lado del servidor.

Obtenga más información sobre SSE de:

Conozca más sobre WebSockets desde:

Otras diferencias

  • WebSockets admite datos binarios arbitrarios, SSE solo usa UTF-8

87
2018-01-23 11:38



Opera, Chrome, Safari admite SSE, Chrome, Safari admite SSE dentro de SharedWorker Firefox es compatible con XMLHttpRequest readyState interactive, por lo que podemos hacer que EventSource polyfil for Firefox


13
2018-03-11 18:49




Websocket VS SSE


Web Sockets - Es un protocolo que proporciona un canal de comunicación full-duplex a través de una única conexión TCP.     Por ejemplo, una comunicación bidireccional entre el servidor y el navegador Dado que el protocolo es más complicado, el servidor y el navegador deben confiar en la biblioteca de websocket cual es socket.io

Example - Online chat application.

SSE (Evento enviado por el servidor) -  En el caso del evento enviado por el servidor, la comunicación se lleva a cabo del servidor al navegador solamente y el navegador no puede enviar datos al servidor. Este tipo de comunicación se usa principalmente cuando la necesidad es solo mostrar los datos actualizados, el servidor envía el mensaje cada vez que se actualizan los datos.     Por ejemplo, una comunicación unidireccional entre el servidor y el navegador. Este protocolo es menos complicado, por lo que no es necesario confiar en la biblioteca externa JAVASCRIPT proporciona el EventSource interfaz para recibir los mensajes enviados por el servidor.

Example - Online stock quotes or cricket score website.

4
2018-05-01 17:58



Una cosa a tener en cuenta:
He tenido problemas con websockets y firewalls corporativos. (Usar HTTPS ayuda, pero no siempre).

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

yo asumir no hay tantos problemas con los eventos enviados por el servidor. Pero no sé

Dicho esto, los WebSockets son muy divertidos. Tengo un pequeño juego web que usa websockets (a través de Socket.IO) (http://minibman.com)


3
2018-04-19 03:04



aquí es una charla sobre las diferencias entre los sockets web y los eventos enviados por el servidor. Desde Java EE 7 a WebSocket API ya es parte de la especificación y parece que los eventos enviados por el servidor se lanzarán en el siguiente versión de la edición empresarial.


0
2017-07-12 07:17



WebSocket y SSE son ambas alternativas a la arquitectura web de solicitud-respuesta tradicional, pero no son exactamente tecnologías competitivas. Una arquitectura WebSocket consiste en un socket que se abre entre el cliente y el servidor para la comunicación full-duplex (bidireccional). En lugar de enviar un mensaje GET y esperar una respuesta del servidor, el cliente simplemente escucha el socket, recibe actualizaciones del servidor y usa los datos para iniciar o soportar varias interacciones. Un cliente también puede usar el zócalo para comunicarse con el servidor, por ejemplo, enviando un mensaje ACK cuando se haya recibido con éxito una actualización.

SSE es un estándar más simple, desarrollado como una extensión de HTML5. Mientras que SSE habilita los mensajes asíncronos del servidor al cliente, el cliente no puede enviar mensajes al servidor. El modelo de comunicación semidúplex de SSE se adapta mejor a las aplicaciones en las que el cliente simplemente necesita recibir actualizaciones de transmisión desde el servidor. Una ventaja de SSE sobre WebSocket es que funciona a través de HTTP, sin requerir componentes adicionales.

Para una aplicación web multipropósito que requiere una amplia comunicación entre el cliente y el servidor, WebSocket es la opción obvia. SSE es más adecuado para aplicaciones que desean transmitir datos asincrónicos al cliente desde el servidor, pero no requieren una respuesta.

Fuente


0
2018-06-29 21:11



El límite máximo de conexión no es un problema con http2 + sse.

Fue un problema en http 1


-4
2017-11-22 20:26