WebSockets vs événements envoyés par le serveur / EventSource
LesWebSockets et événements envoyés par le serveur sont capables de pousser des 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 plutôt que l'autre?
8 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'une application qui pourrait utiliser websockets est une application de chat.
Les connexions SSE peuvent uniquement envoyer des données au navigateur. Cotations boursières en ligne, ou twitters mise à jour timeline ou flux sont de bons exemples d'une application qui pourrait profitez de SSE.
En pratique, puisque tout ce qui peut être fait avec SSE peut aussi l'être 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 exagéré pour certains types d'applications, et le backend pourrait être plus facile à implémenter avec un protocole tel que SSE.
En outre SSE peut être polyfilled dans les navigateurs plus anciens qui ne le supportent pas nativement en utilisant simplement JavaScript. Quelque les implémentations de SSE polyfills peuvent être trouvées sur la page Modernizr github .
Pièges:
- SSE souffre d'une limitation du nombre maximum de connexions ouvertes, ce qui peut être particulièrement douloureux lors de l'ouverture de différents onglets car la limite est par navigateur et définie sur un nombre très faible (6). Le problème a été marqué comme "ne corrigera pas" dans Chrome et Firefox
- seul WS peut transmettre à la fois des 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 contre WebSockets
Pourquoi choisiriez-vous les événements envoyés par le serveur sur les WebSockets? Bonne question.
L'une des raisons pour lesquelles les Sse ont été conservés dans l'ombre est que les API ultérieures comme les WebSockets fournissent un protocole plus riche pour effectuer une 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 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 de serveur. Quelques exemples seraient les mises à jour de statut d'amis, les tickers de stock, les fils de nouvelles ou d'autres mécanismes de push de données automatisés (par exemple, la mise à jour d'une base de données Web SQL côté client ou D'un magasin D'objets IndexedDB). Si vous devez envoyer des données à un serveur, XMLHttpRequest est toujours un ami.
SSEs sont envoyés via HTTP traditionnel. Cela signifie qu'ils ne nécessitent pas de protocole spécial ou d'implémentation de serveur pour fonctionner. WebSockets d'autre part, nécessitent des connexions full-duplex et de nouveaux serveurs de Socket Web pour gérer le protocole. En outre, les événements envoyés par le serveur ont une variété de fonctionnalités que les WebSockets manquent par conception, telles que la reconnexion automatique, Les Id d'événement et la possibilité d'envoyer des événements arbitraires.
TLDR résumé:
Avantages de SSE par rapport aux Websockets:
- transporté sur HTTP simple au lieu d'un protocole personnalisé
- peut être rempli de Javascript pour "rétroporter" 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 par rapport à SSE:
- en temps réel, deux directionnelle communication.
- prise en charge Native dans plus de navigateurs
Cas D'utilisation idéaux de SSE:
- Stock ticker streaming
- mise à jour du flux twitter
- Notifications au navigateur
ESS pièges:
- Aucun support binaire
- limite maximale des connexions ouvertes
Selon caniuse.com:
- % 90 des utilisateurs globaux prennent en charge nativement les WebSockets
- % 84 des utilisateurs globaux prennent en charge nativement les événements envoyés par le serveur
Vous pouvez utiliser un polyfill client uniquement pour étendre la prise en charge de SSE à de nombreux autres navigateurs. C'est moins probable avec les WebSockets. Certains polyfills EventSource:
- EventSource par Remy Sharp sans autres dépendances de bibliothèque (IE7+)
- jQuery.EventSource {[5] } par Rick Waldron
- EventSource par Yaffle (remplace l'implémentation native, normalisant le comportement entre les navigateurs)
Si vous avez besoin de prendre en charge tous les navigateurs, envisagez d'utiliser une bibliothèque comme web-socket-js, SignalR ou socket.io {[5] } qui prennent en charge plusieurs transports tels que WebSockets, SSE, Forever Frame et AJAX long polling. Ceux-ci nécessitent souvent des modifications du côté serveur ainsi.
En savoir plus sur SSE de:
- HTML5 Rocks article
- la spécification du W3C ( version publiée, brouillon de l'éditeur )
En savoir plus sur WebSockets de:
- HTML5 Rocks article
- la spécification W3C (version publiée, brouillon de l'éditeur )
Autres différences:
- WebSockets prend en charge les données binaires arbitraires, SSE utilise uniquement UTF-8
Opera, Chrome, Safari prend en charge SSE, Chrome, Safari prend en charge SSE à L'intérieur de SharedWorker Firefox prend en charge XMLHttpRequest readyState interactive, afin que nous puissions faire EventSource polyfil pour Firefox
Websocket VS ESS
Web Sockets - 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
Depuis le protocole est plus compliqué, le serveur et le navigateur s'appuie sur la bibliothèque de websocket
qui 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 navigateur uniquement et le navigateur ne peut pas envoyer de données 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 unidirectionnelle 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 l'interface EventSource pour recevoir les messages envoyés par le serveur.
Example - Online stock quotes or cricket score website.
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
Jesuppose que 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 sont des tonnes de plaisir. J'ai un petit jeu web qui utilise websockets (via Socket.IO) ( http://minibman.com )
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 API WebSocket 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 suivante de l'édition enterprise.
WebSocket et SSE {[2] } sont deux alternatives à l'architecture web traditionnelle demande-réponse, mais ce ne sont pas exactement des technologies concurrentes. Une architecture WebSocket se compose d'un socket qui est ouvert entre le client et le serveur pour la communication full-duplex (bidirectionnelle). Au lieu d'envoyer un message GET et d'attendre une réponse du serveur, le client écoute simplement le socket, reçoit des mises à jour du serveur et utilise les données pour lancer ou prendre en charge divers interaction. 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 un standard plus simple, développé comme une extension de HTML5. Bien que SSE active les messages asynchrones du serveur au 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 streaming 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 veulent diffuser des données asynchrones au client à partir du serveur, mais ne nécessitent pas de réponse de retour.
La limite de connexion maximale n'est pas un problème avec http2 + sse.
C'était un problème sur http 1