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


Tous les deux WebSockets et Événements envoyés par le serveur sont capables de pousser les 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 par rapport à l'autre?


622
2018-03-04 15:07


origine


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'application qui pourrait utiliser websockets est une application de chat.

Les connexions SSE peuvent uniquement envoyer des données au navigateur. Les cotations boursières en ligne ou les twitters qui mettent à jour la chronologie ou le flux sont de bons exemples d'une application qui pourrait bénéficier de SSE.

Dans la pratique, tout ce qui peut être fait avec SSE peut également être fait avec Websockets, Websockets reçoit beaucoup plus d'attention et d'amour, et beaucoup plus de navigateurs supportent 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 copié dans des navigateurs plus anciens qui ne le supportent pas nativement en utilisant seulement JavaScript. Certaines implémentations de polyfills SSE peuvent être trouvées sur le Modernizr github page.

Gotchas:

  • SSE souffre d'une limitation au nombre maximum de connexions ouvertes, ce qui peut être particulièrement douloureux lors de l'ouverture de divers onglets car la limite est par navigateur et mis à un nombre très bas (6). Le problème a été marqué comme "Ne réparera pas" dans Chrome et Firefox
  • Seul WS peut transmettre les 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 par rapport aux WebSockets

Pourquoi choisiriez-vous les événements Server-Sent sur WebSockets? Bonne question.

L'une des raisons pour lesquelles les SSE ont été conservées dans l'ombre est que les API ultérieures telles que WebSockets fournissent un protocole plus riche pour effectuer une communication bidirectionnelle bidirectionnelle simultanée. 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 directions. 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 de certaines actions du serveur. Quelques exemples seraient les mises à jour d'état des amis, les tickers boursiers, les fils de nouvelles ou d'autres mécanismes de poussée de données automatisés (par exemple la mise à jour d'une base de données Web SQL ou 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 n'ont pas besoin d'un protocole spécial ou d'une implémentation de serveur pour fonctionner. D'autre part, les WebSockets nécessitent des connexions full-duplex et de nouveaux serveurs Web Socket pour gérer le protocole. En outre, les événements envoyés par le serveur présentent diverses fonctionnalités dont WebSockets ne dispose pas, 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é sur HTTP simple au lieu d'un protocole personnalisé
  • Peut être rempli de javascript pour "backport" 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 sur SSE:

  • Temps réel, communication bidirectionnelle.
  • Prise en charge native dans plusieurs navigateurs

Cas d'utilisation idéaux de SSE:

  • Ticker boursier en streaming
  • mise à jour du flux Twitter
  • Notifications au navigateur

SSE gotchas:

  • Pas de support binaire
  • Limite maximale des connexions ouvertes

716
2018-03-16 13:40



Selon caniuse.com:

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

  • EventSource par Remy Sharp sans autres dépendances de bibliothèque (IE7 +)
  • jQuery.EventSource par Rick Waldron
  • EventSource par Yaffle (remplace l'implémentation native, en normalisant le comportement entre les navigateurs)

Si vous avez besoin de supporter tous les navigateurs, pensez à utiliser une bibliothèque comme web-socket-js, SignalR ou socket.io qui supportent plusieurs transports tels que WebSockets, SSE, Forever Frame et AJAX long polling. Cela nécessite souvent des modifications du côté serveur.

En savoir plus sur SSE à partir de:

En savoir plus sur WebSockets à partir de:

Autres différences

  • WebSockets prend en charge les données binaires arbitraires, SSE utilise uniquement UTF-8

87
2018-01-23 11:38



Opera, Chrome, Safari prend en charge SSE, Chrome, Safari prend en charge SSE dans SharedWorker Firefox supporte XMLHttpRequest readyState interactif, de sorte que nous pouvons faire polyfil EventSource pour Firefox


13
2018-03-11 18:49




Websocket VS SSE


Supports Web - 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 Puisque le protocole est plus compliqué, le serveur et le navigateur doivent s'appuyer sur la bibliothèque de websocket lequel 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 le navigateur uniquement et le navigateur ne peut envoyer aucune donnée 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 à sens unique 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 le EventSource interface pour recevoir les messages envoyés par le serveur.

Example - Online stock quotes or cricket score website.

4
2018-05-01 17:58



Une chose à noter:
J'ai eu des problèmes avec les websockets et les firewalls d'entreprise. (Utiliser 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

je assumer 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 est très amusant. J'ai un petit jeu en ligne qui utilise des websockets (via Socket.IO) (http://minibman.com)


3
2018-04-19 03:04



Ici est une discussion sur les différences entre les sockets Web et les événements envoyés par le serveur. Depuis Java EE 7 a WebSocket 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 le prochain version de l'édition d'entreprise.


0
2017-07-12 07:17



WebSocket et SSE sont deux alternatives à l'architecture web traditionnelle de demande-réponse, mais elles ne sont pas exactement des technologies concurrentes. Une architecture WebSocket est constituée d'un socket ouvert entre le client et le serveur pour une communication bidirectionnelle bidirectionnelle. Au lieu d'envoyer un message GET et d'attendre une réponse du serveur, le client écoute simplement le socket, reçoit les mises à jour du serveur et utilise les données pour lancer ou prendre en charge diverses interactions. 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 une norme plus simple, développée en tant qu'extension de HTML5. Alors que SSE active les messages asynchrones du serveur vers le 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 continu du 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 souhaitent diffuser des données asynchrones au client à partir du serveur, mais ne nécessitent pas de réponse en retour.

La source


0
2018-06-29 21:11



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

C'était un problème sur http 1


-4
2017-11-22 20:26