WebSockets vs événements envoyés par le serveur / EventSource

LesWebSockets et événements envoyés par le serveur sont capables de pousser des données vers les navigateurs. Pour moi, ils semblent être des technologies concurrentes. Quelle est la différence entre eux? Quand choisiriez-vous l'un plutôt que l'autre?

632
demandé sur Mads Mobæk 2011-03-04 18:07:32

8 réponses

Websockets et SSE (Server Sent Events) sont tous deux capables de transmettre des données aux navigateurs, mais ils ne sont pas des technologies concurrentes.

Les connexions Websockets peuvent à la fois envoyer des données au navigateur et recevoir des données du navigateur. Un bon exemple d'une application qui pourrait utiliser websockets est une application de chat.

Les connexions SSE peuvent uniquement envoyer des données au navigateur. Cotations boursières en ligne, ou twitters mise à jour timeline ou flux sont de bons exemples d'une application qui pourrait profitez de SSE.

En pratique, puisque tout ce qui peut être fait avec SSE peut aussi l'être avec Websockets, Websockets reçoit beaucoup plus d'attention et d'amour, et beaucoup plus de navigateurs supportent Websockets que SSE.

Cependant, cela peut être exagéré pour certains types d'applications, et le backend pourrait être plus facile à implémenter avec un protocole tel que SSE.

En outre SSE peut être polyfilled dans les navigateurs plus anciens qui ne le supportent pas nativement en utilisant simplement JavaScript. Quelque les implémentations de SSE polyfills peuvent être trouvées sur la page Modernizr github .

Pièges:

  • SSE souffre d'une limitation du nombre maximum de connexions ouvertes, ce qui peut être particulièrement douloureux lors de l'ouverture de différents onglets car la limite est par navigateur et définie sur un nombre très faible (6). Le problème a été marqué comme "ne corrigera pas" dans Chrome et Firefox
  • seul WS peut transmettre à la fois des données binaires et UTF-8, SSE est limité à UTF-8. (Merci à Chado Nihi).

HTML5Rocks A de bonnes informations sur SSE. De cette page:

Événements envoyés par le serveur contre WebSockets

Pourquoi choisiriez-vous les événements envoyés par le serveur sur les WebSockets? Bonne question.

L'une des raisons pour lesquelles les Sse ont été conservés dans l'ombre est que les API ultérieures comme les WebSockets fournissent un protocole plus riche pour effectuer une communication bidirectionnelle en duplex intégral. Avoir un canal bidirectionnel est plus attrayant pour des choses comme les jeux, les applications de messagerie et pour les cas où vous avez besoin de mises à jour en temps réel dans les deux sens. Cependant, dans certains scénarios, les données n'ont pas besoin d'être envoyées par le client. Vous avez simplement besoin de mises à jour à partir d'une action de serveur. Quelques exemples seraient les mises à jour de statut d'amis, les tickers de stock, les fils de nouvelles ou d'autres mécanismes de push de données automatisés (par exemple, la mise à jour d'une base de données Web SQL côté client ou D'un magasin D'objets IndexedDB). Si vous devez envoyer des données à un serveur, XMLHttpRequest est toujours un ami.

SSEs sont envoyés via HTTP traditionnel. Cela signifie qu'ils ne nécessitent pas de protocole spécial ou d'implémentation de serveur pour fonctionner. WebSockets d'autre part, nécessitent des connexions full-duplex et de nouveaux serveurs de Socket Web pour gérer le protocole. En outre, les événements envoyés par le serveur ont une variété de fonctionnalités que les WebSockets manquent par conception, telles que la reconnexion automatique, Les Id d'événement et la possibilité d'envoyer des événements arbitraires.


TLDR résumé:

Avantages de SSE par rapport aux Websockets:

  • transporté sur HTTP simple au lieu d'un protocole personnalisé
  • peut être rempli de Javascript pour "rétroporter" SSE vers les navigateurs qui ne le supportent pas encore.
  • prise en charge intégrée de la reconnexion et de l'ID d'événement
  • protocole plus Simple

Avantages des Websockets par rapport à SSE:

  • en temps réel, deux directionnelle communication.
  • prise en charge Native dans plus de navigateurs

Cas D'utilisation idéaux de SSE:

  • Stock ticker streaming
  • mise à jour du flux twitter
  • Notifications au navigateur

ESS pièges:

  • Aucun support binaire
  • limite maximale des connexions ouvertes
730
répondu Alex Recarey 2017-05-19 21:43:04

Selon caniuse.com:

Vous pouvez utiliser un polyfill client uniquement pour étendre la prise en charge de SSE à de nombreux autres navigateurs. C'est moins probable avec les WebSockets. Certains polyfills EventSource:

Si vous avez besoin de prendre en charge tous les navigateurs, envisagez d'utiliser une bibliothèque comme web-socket-js, SignalR ou socket.io {[5] } qui prennent en charge plusieurs transports tels que WebSockets, SSE, Forever Frame et AJAX long polling. Ceux-ci nécessitent souvent des modifications du côté serveur ainsi.

En savoir plus sur SSE de:

En savoir plus sur WebSockets de:

Autres différences:

  • WebSockets prend en charge les données binaires arbitraires, SSE utilise uniquement UTF-8
89
répondu Drew Noakes 2017-05-23 11:47:31

Opera, Chrome, Safari prend en charge SSE, Chrome, Safari prend en charge SSE à L'intérieur de SharedWorker Firefox prend en charge XMLHttpRequest readyState interactive, afin que nous puissions faire EventSource polyfil pour Firefox

14
répondu Yaffle 2011-03-11 18:49:46

Websocket VS ESS


Web Sockets - c'est un protocole qui fournit un canal de communication full-duplex sur une seule connexion TCP. Par exemple, une communication bidirectionnelle entre le serveur et le navigateur Depuis le protocole est plus compliqué, le serveur et le navigateur s'appuie sur la bibliothèque de websocket qui est socket.io

Example - Online chat application.

SSE (événement envoyé par le serveur) - En cas d'événement envoyé par le serveur la communication est effectuée du serveur vers navigateur uniquement et le navigateur ne peut pas envoyer de données au serveur. Ce type de communication est principalement utilisé lorsque le besoin est seulement d'afficher les données mises à jour, le serveur envoie le message chaque fois que les données sont mises à jour. Par exemple, une communication unidirectionnelle entre le serveur et le navigateur. Ce protocole est moins compliqué, donc pas besoin de s'appuyer sur la bibliothèque externe JAVASCRIPT lui-même fournit l'interface EventSource pour recevoir les messages envoyés par le serveur.

Example - Online stock quotes or cricket score website.
4
répondu Gaurav Tiwari 2017-05-01 17:58:25

Une chose à noter:
J'ai eu des problèmes avec les websockets et les pare-feu d'entreprise. (L'utilisation de HTTPS aide mais pas toujours.)

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

Jesuppose que Il n'y a pas autant de problèmes avec les événements envoyés par le serveur. Mais je ne sais pas.

Cela dit, WebSockets sont des tonnes de plaisir. J'ai un petit jeu web qui utilise websockets (via Socket.IO) ( http://minibman.com )

3
répondu Drew LeSueur 2014-04-19 03:04:05

Ici est un exposé sur les différences entre les sockets web et les événements envoyés par le serveur. Depuis Java EE 7 une API WebSocket fait déjà partie de la spécification et il semble que les événements envoyés par le serveur seront publiés dans la version suivante de l'édition enterprise.

0
répondu Patrick Leitermann 2014-07-12 07:17:14

WebSocket et SSE {[2] } sont deux alternatives à l'architecture web traditionnelle demande-réponse, mais ce ne sont pas exactement des technologies concurrentes. Une architecture WebSocket se compose d'un socket qui est ouvert entre le client et le serveur pour la communication full-duplex (bidirectionnelle). Au lieu d'envoyer un message GET et d'attendre une réponse du serveur, le client écoute simplement le socket, reçoit des mises à jour du serveur et utilise les données pour lancer ou prendre en charge divers interaction. Un client peut également utiliser le socket pour communiquer avec le serveur, par exemple en envoyant un message ACK lorsqu'une mise à jour a été reçue avec succès.

SSE est un standard plus simple, développé comme une extension de HTML5. Bien que SSE active les messages asynchrones du serveur au client, le client ne peut pas envoyer de messages au serveur. Le modèle de communication semi-duplex de SSE est le mieux adapté aux applications où le client a simplement besoin de recevoir des mises à jour en streaming serveur. Un avantage de SSE sur WebSocket est qu'il fonctionne sur HTTP, sans nécessiter de composants supplémentaires.

Pour une application web polyvalente nécessitant une communication étendue entre le client et le serveur, WebSocket est le choix évident. SSE est plus approprié pour les applications qui veulent diffuser des données asynchrones au client à partir du serveur, mais ne nécessitent pas de réponse de retour.

Source

0
répondu Srikrushna Pal 2018-06-29 21:11:05

La limite de connexion maximale n'est pas un problème avec http2 + sse.

C'était un problème sur http 1

-4
répondu user1948585 2017-11-22 20:26:57