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
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.