web-dev-qa-db-fra.com

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

WebSockets et événements envoyés par le serveur sont capables de transmettre des données aux navigateurs. Pour moi, elles semblent être des technologies concurrentes. Quelle est la différence entre eux? Quand choisiriez-vous l'un par rapport à l'autre?

html5websocketserver-sent-events
739
Mads Mobæk

Les Websockets et SSE (événements envoyés par le serveur) sont tous deux capables de transmettre des données aux navigateurs, mais ne constituent pas des technologies concurrentes.

Les connexions Websockets peuvent à la fois envoyer des données au navigateur et recevoir des données du navigateur. Une application de discussion est un bon exemple d'application pouvant utiliser des websockets.

Les connexions SSE peuvent uniquement transmettre des données au navigateur. Les cours de bourse en ligne, ou les mises à jour chronologiques ou des flux de twitters sont de bons exemples d'application qui pourraient tirer parti de SSE.

En pratique, puisque tout ce qui peut être fait avec SSE peut également être fait avec Websockets, Websockets attire beaucoup plus d’attention et d’amour, et beaucoup plus de navigateurs prennent en charge Websockets que SSE.

Cependant, il peut être excessif pour certains types d’application, et le backend pourrait être plus facile à implémenter avec un protocole tel que SSE.

De plus, SSE peut être intégré dans les navigateurs plus anciens qui ne le prennent pas en charge de manière native en utilisant uniquement JavaScript. Certaines implémentations de SSE polyfills peuvent être trouvées sur le page Modernizr github .

Les pièges:

  • SSE souffre d'une limitation du nombre maximal de connexions ouvertes, ce qui peut être particulièrement pénible lors de l'ouverture de différents onglets, car la limite est fixée à par navigateur et définie sur un nombre très faible (6). . Le problème a été marqué comme "ne résoudra pas" dans Chrome et Firefox
  • Seul WS peut transmettre les données binaires et UTF-8. SSE est limité à UTF-8. (Merci à Chado Nihi).
  • Certains pare-feu d'entreprise avec inspection de paquets rencontrent des difficultés pour gérer les WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).

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

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

Pourquoi choisiriez-vous les événements envoyés par le serveur plutôt que WebSockets? Bonne question.

L'une des raisons pour lesquelles les SSE ont été laissés dans l'ombre est due au fait que les API ultérieures telles que WebSockets fournissent un protocole plus riche pour la 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 quasi réel dans les deux sens. Cependant, dans certains scénarios, il n'est pas nécessaire que les données soient envoyées par le client. Vous avez simplement besoin de mises à jour à partir d'une action du serveur. Quelques exemples sont les mises à jour de statut d'amis, les tickers boursiers, les flux de nouvelles ou d'autres mécanismes automatisés d'envoi de données (par exemple, la mise à jour d'une base de données Web SQL ou d'un magasin d'objets IndexedDB côté client). Si vous devez envoyer des données à un serveur, XMLHttpRequest est toujours un ami.

Les SSE sont envoyés via HTTP traditionnel. Cela signifie qu'ils ne nécessitent pas de protocole spécial ni d'implémentation de serveur pour fonctionner. Les WebSockets, d’autre part, nécessitent des connexions en duplex intégral et de nouveaux serveurs Web Socket pour gérer le protocole. En outre, les événements envoyés par le serveur disposent de nombreuses fonctionnalités dont WebSockets n'est pas conçue, telles que la reconnexion automatique, les ID d'événement et la possibilité d'envoyer des événements arbitraires.

Résumé TLDR:

Avantages de SSE sur Websockets:

  • Transporté via HTTP simple au lieu d'un protocole personnalisé
  • Peut être poly-rempli avec javascript pour "backport" SSE aux navigateurs qui ne le supportent pas encore.
  • Prise en charge intégrée pour la reconnexion et l'id d'événement
  • Protocole plus simple
  • Aucun problème avec les pare-feu d'entreprise effectuant l'inspection des paquets

Avantages de Websockets par rapport à SSE:

  • Communication en temps réel et bidirectionnelle.
  • Prise en charge native dans plusieurs navigateurs

Cas d'utilisation idéaux du SSE:

  • Stock ticker en streaming
  • Mise à jour du flux Twitter
  • Notifications au navigateur

SSE piège:

  • Pas de support binaire
  • Nombre maximal de connexions ouvertes
872
Alex Recarey

Selon caniuse.com:

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

Si vous avez besoin de supporter tous les navigateurs, pensez à utiliser une bibliothèque comme web-socket-js , SignalR ou socket.io qui supporte plusieurs transports. tels que WebSockets, SSE, Forever Frame et AJAX longue interrogation. Celles-ci nécessitent souvent des modifications côté serveur.

En savoir plus sur SSE de:

En savoir plus sur WebSockets auprès de:

Autres différences:

  • WebSockets prend en charge les données binaires arbitraires, SSE utilise uniquement le format UTF-8.
99
Drew Noakes

Opera, Chrome, Safari prend en charge SSE, Chrome, Safari prend en charge SSE dans SharedWorker Firefox prend en charge XMLHttpRequest readyState interactive, afin que nous puissions créer EventSource polyfil pour Firefox.

15
Yaffle

Websocket VS SSE

Web Sockets - C'est un protocole qui fournit un canal de communication en duplex intégral via une seule connexion TCP. Par exemple, une communication bidirectionnelle entre le serveur et le navigateur. Comme le protocole est plus compliqué, le serveur et le navigateur doivent s’appuyer sur la bibliothèque de Websocket qui est socket.io

Example - Online chat application.

SSE (Server-Sent Event)) - Dans le cas d'un événement envoyé par le serveur, la communication est effectuée d'un serveur à l'autre et le navigateur ne peut envoyer aucune donnée au serveur. Ce type de communication est principalement utilisé lorsque le besoin consiste uniquement à afficher les données mises à jour, puis le serveur envoie le message chaque fois que les données sont mises à jour. Par exemple, une communication à sens unique entre le serveur et le navigateur. Ce protocole est moins compliqué, il n’est donc pas nécessaire 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.
6
Gaurav Tiwari

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

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

Je suppose qu'il n'y a pas autant de problèmes liés aux événements envoyés par le serveur. Mais je ne sais pas.

Cela dit, les WebSockets sont très amusantes. J'ai un petit jeu Web qui utilise des websockets (via Socket.IO) ( http://minibman.com )

4
Drew LeSueur

Here est un exposé sur les différences entre les sockets Web et les événements envoyés par le serveur. Puisque Java EE 7 a WebSocket , l'API 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 next de l'entreprise. édition.

1
Patrick Leitermann