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 ?
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 :
www.example1.com et 6 autres connexions SSE à www.example2.com (merci Phate).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.
Avantages de SSE par rapport à Websockets :
Avantages de Websockets par rapport à SSE :
Les cas d'utilisation idéaux de l'ESS :
Gênes de l'ESS :
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.
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.
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
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 :
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.
@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.
@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.
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 )
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.
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 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.
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.16 votes
@BrianDriscoll - asynchrone/synchrone - lequel est lequel ? D'après ce que je comprends, les deux permettent des transferts asynchrones ?
6 votes
SSE ne fonctionne pas sur IE, websockets le fait
0 votes
@SSE est trivialement patché sur IE avec moins de 50 LOC. Ce point est discutable.
0 votes
@oligofren avez-vous une référence ?
3 votes
@cellepo Voir la page de MDN sur SSE . Il répertorie plusieurs polyfills. Celui de Remy Sharp compte 186 lignes, que l'on pourrait réduire à l'essentiel, mais oui, 50 lignes, c'est un peu moins... ;)
0 votes
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 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.