1151 votes

WebSockets ou événements envoyés par le serveur/Source d'événement

Ambos WebSockets y Événements envoyés par le serveur sont capables de transmettre des données aux navigateurs. Pour moi, il s'agit de technologies concurrentes. Quelle est la différence entre elles ? Quand choisiriez-vous l'une plutôt que l'autre ?

4 votes

Je ne vois pas comment vous les voyez en concurrence. L'un est synchrone et pourrait/serait utilisé pour le transfert de données en temps quasi réel, tandis que l'autre est asynchrone et servirait un objectif totalement différent (envoyer efficacement des messages de type toast depuis une application côté serveur).

64 votes

WebSockets est bidirectionnel, il peut envoyer des données au serveur.

28 votes

Une chose que j'aime beaucoup à propos de l'ESS, c'est qu'il est facile à dépanner... il suffit d'ouvrir une requête à votre serveur ESS en utilisant curl . Comme il s'agit simplement d'un format texte via HTTP, il est facile de voir ce qui se passe.

1366voto

Alex Recarey Points 4221

Websockets et SSE (Server Sent Events) sont tous deux capables de transmettre des données aux navigateurs, mais ce 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 les websockets est une application de chat.

Les connexions SSE ne peuvent que pousser les données vers le navigateur. Les cours de la bourse en ligne ou la mise à jour de la timeline ou du flux de Twitter sont de bons exemples d'applications qui pourraient bénéficier de l'ESS.

En pratique, comme 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, cela peut être excessif pour certains types d'applications, et le backend pourrait être plus facile à mettre en œuvre avec un protocole tel que SSE.

En outre, l'ESS peut être intégré dans les anciens navigateurs qui ne le prennent pas en charge de manière native, en utilisant uniquement JavaScript. Certaines implémentations de polyfills SSE peuvent être trouvées sur le site Web de la Commission européenne. Page github de Modernizr .

Des problèmes :

  • L'ESS souffre d'une limitation du nombre maximal de connexions ouvertes, ce qui peut être particulièrement pénible lors de l'ouverture de plusieurs onglets, car la limite est de 10 %. par navigateur et réglé sur un nombre très faible (6). Le problème a été marqué comme "Won't fix" dans la base de données de la Commission européenne. Chrome y Firefox . Cette limite est fixée par navigateur + domaine, ce qui signifie que vous pouvez ouvrir 6 connexions SSE sur l'ensemble des onglets pour www.example1.com et 6 autres connexions SSE à www.example2.com (merci Phate).
  • Seul WS peut transmettre à la fois des données binaires et UTF-8, SSE est limité à UTF-8. (Merci à Chado Nihi).
  • Certains pare-feu d'entreprise dotés d'une fonction d'inspection des paquets ont des difficultés à traiter les WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).

HTML5Rocks contient de bonnes informations sur l'ESS. De cette page :

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

Pourquoi préférer les événements envoyés par le serveur aux WebSockets ? Bonne question.

L'une des raisons pour lesquelles les ESS sont restés dans l'ombre est que les API ultérieures, comme les WebSockets, offrent un protocole plus riche pour effectuer une communication bidirectionnelle et en duplex intégral. Un canal bidirectionnel est plus intéressant pour les jeux, les applications de messagerie et les cas où vous avez besoin de mises à jour en temps quasi 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 du serveur. Il peut s'agir, par exemple, de mises à jour du statut d'amis, de tickers d'actions, de flux d'informations ou d'autres mécanismes automatisés de poussée de données (par exemple, la mise à jour d'une base de données SQL Web côté client ou d'un magasin d'objets IndexedDB). Si vous devez envoyer des données à un serveur, XMLHttpRequest est toujours un ami.

Les ESS sont envoyés via le protocole HTTP traditionnel. Cela signifie qu'ils ne nécessitent pas de protocole spécial ou d'implémentation de serveur pour fonctionner. Les WebSockets, en revanche, 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 une variété de caractéristiques que les WebSockets n'ont pas par conception, comme la reconnexion automatique, les ID d'événements et la possibilité d'envoyer des événements arbitraires.


Résumé TLDR :

Avantages de SSE par rapport à Websockets :

  • Transmis par le simple HTTP au lieu d'un protocole personnalisé.
  • Peut être poly-rempli avec du javascript pour "backport" SSE aux navigateurs qui ne le supportent pas encore.
  • Support intégré pour la reconnexion et l'identifiant de l'événement.
  • Un protocole plus simple
  • Pas de problème avec les pare-feu d'entreprise qui inspectent les paquets.

Avantages de Websockets par rapport à SSE :

  • Communication bidirectionnelle en temps réel.
  • Support natif dans plus de navigateurs

Les cas d'utilisation idéaux de l'ESS :

  • Streaming du ticker d'actions
  • mise à jour du flux twitter
  • Notifications au navigateur

Gênes de l'ESS :

  • Pas de support binaire
  • Limite maximale des connexions ouvertes

169 votes

Le chat est parfaitement réalisable avec l'ESS - vous pouvez utiliser le POST normal pour envoyer des messages au serveur. Les WebSockets ne seraient nécessaires que si vous implémentez le chat à la Google Wave.

181 votes

Il est vrai que le chat et d'autres applications en temps réel peuvent être réalisés avec SSE. Cependant, cela nécessite de poster des réponses "hors bande", c'est-à-dire que cela n'est pas contrôlé par le protocole SSE, et ne semble pas être un bon exemple pour une explication de base sur les différences entre SSE et Websockets. Vous pouvez mettre en œuvre le chat avec le protocole HTTP de base en interrogeant le serveur toutes les secondes et en postant de nouvelles réponses. Cela ne signifie pas qu'il s'agisse de la meilleure façon ou de la plus élégante de le faire.

19 votes

Je pense que la solution de pomeL est un excellent compromis pour la plupart des cas, puisque JS peut toujours "pousser" les choses vers le serveur avec un POST AJAX. D'après mon expérience, le principal problème a généralement été la nécessité pour JS d'interroger le serveur pour obtenir de nouvelles informations, mais SSE s'en charge. :D

148voto

Drew Noakes Points 69288

Selon le site caniuse.com :

Vous pouvez utiliser un polyfill réservé au client pour étendre la prise en charge de l'ESS à de nombreux autres navigateurs. Cela est moins probable avec les WebSockets. Certains polyfills EventSource :

Si vous devez prendre en charge tous les navigateurs, envisagez d'utiliser une bibliothèque telle que web-socket-js , SignalR ou socket.io qui prennent en charge de multiples transports tels que WebSockets, SSE, Forever Frame et AJAX long polling. Ces solutions nécessitent souvent des modifications du côté serveur également.

Pour en savoir plus sur l'ESS :

Pour en savoir plus sur les WebSockets :

Autres différences :

  • WebSockets supporte des données binaires arbitraires, SSE n'utilise que l'UTF-8.

3 votes

Je tiens à souligner qu'en 2016, > 95% des utilisateurs mondiaux supportent nativement les WebSockets. Tous les navigateurs et appareils supportent WebSockets depuis plus de 4 ans. Socket.IO se repliera sur AJAX long polling et gérera les complexités de l'émulation de WebSockets pour vous s'il n'est pas supporté, ce qui rend le support à 100%. Si vous utilisez autre chose que WebSockets en 2016, vous utilisez une technologie dépassée.

15 votes

@NickSteele C'est une déclaration à la con. S'appuyer sur des normes plus anciennes est parfaitement acceptable si elles répondent à votre cas d'utilisation et ne signifie pas que quelque chose est dépassé. Il s'agit simplement d'une norme différente. Ex : XHR peut encore faire beaucoup de choses que l'API Fetch ne peut pas faire, donc ce n'est pas dépassé. C'est différent. J'ai utilisé WS dans le passé, mais je sais par expérience que l'on peut rencontrer des obstacles sous la forme de pare-feu d'entreprise bruyants qui bloquent les demandes lorsqu'ils ne comprennent pas WS. SSE est super efficace pour ce qu'il fait, est trivialement compréhensible et implémentable et facile à déboguer. Pour notre flux de données à sens unique, c'est parfait.

0 votes

@oligofren Pas besoin de jurer. Si quelque chose est conçu pour remplacer la version précédente, et qu'il est accepté par l'industrie et meilleur dans tous les domaines, par définition, l'ancienne méthode est dépassée. Tout comme l'iPhone original est dépassé, XHR l'est aussi. XHR est apparu avant Firefox, Chrome, le premier iPhone, avant YouTube, Netflix, Facebook et même MySpace. Lorsque XHR est sorti, Windows 98 était le meilleur système d'exploitation, AOL était le meilleur fournisseur d'accès et JSON n'existait même pas. Les WebSockets ont remplacé XHR il y a presque dix ans. Si vous rencontrez des difficultés en utilisant WS, la cause de ces difficultés est également dépassée. Il n'y a aucune excuse pour prendre autant de retard.

19voto

Yaffle Points 164

Opera, Chrome, Safari supportent le SSE, Chrome, Safari supporte SSE à l'intérieur de SharedWorker. Firefox supporte XMLHttpRequest readyState interactif, nous pouvons donc faire un polyfiltre EventSource pour Firefox.

8voto

Drew LeSueur Points 2507

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

I supposez 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, les WebSockets sont très amusantes. J'ai un petit jeu web qui utilise les websockets (via Socket.IO) ( http://minibman.com )

1 votes

J'ai également eu des problèmes avec les pare-feu d'entreprise.

2 votes

Un problème que j'ai rencontré avec les événements envoyés par le serveur est que certains proxies/pare-feu peuvent les bloquer parce qu'ils n'ont pas d'en-tête Content-Length.

0 votes

De plus, Nginx peut le bloquer si l'en-tête X-Accel-Buffering n'est pas réglé sur no.

4voto

ptk93 Points 701

Ici est un exposé sur les différences entre les web sockets et les événements envoyés par le serveur. Depuis Java EE 7, une 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 le cadre de l'API de l'UE. suivant version de l'édition entreprise.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X