Évolutivité du serveur - HTML 5 websockets vs Comet
De nombreuses implémentations Comet comme Caplin fournissent des solutions évolutives sur serveur.
Voici l'une des statistiques du site Caplin :
Une seule instance de Caplin liberator peut prendre en charge jusqu'à 100 000 clients recevant chacun 1 message par seconde avec une latence moyenne de moins de 7 ms.
Comment cela se compare-t-il aux Websockets HTML5 sur n'importe quel serveur Web? Quelqu'un peut-il me pointer vers des statistiques Websockets HTML 5?
Divulgation - Je travaille pour Caplin.
Il y a un peu de désinformation sur cette page donc j'aimerais essayer de la rendre plus claire ..
Je pense que nous pourrions diviser les méthodes dont nous parlons en trois camps ..
- Interrogation HTTP Comet - y compris l'interrogation longue
- Comet HTTP streaming - les messages du serveur au client utilisent une seule socket persistante sans surcharge d'en-tête HTTP après la configuration initiale
- Comet WebSocket - socket bidirectionnel unique
Je les vois tous comme Comet, car Comet n'est qu'un paradigme, mais depuis que WebSocket est arrivé, certaines personnes veulent le traiter comme s'il était différent ou remplace Comet - mais c'est juste une autre technique - et à moins que vous ne soyez heureux de ne prendre en charge que les derniers navigateurs alors vous ne pouvez pas simplement compter sur WebSocket.
En ce qui concerne les performances, la plupart des tests de performance se concentrent sur les messages du serveur au client - nombre d'utilisateurs, nombre de messages par seconde et latence de ces messages. Pour ce scénario, il n'y a pas de différence fondamentale entre HTTP Streaming et WebSocket - les deux écrivent des messages sur une socket ouverte avec peu ou pas d'en-tête ou de surcharge.
Une longue interrogation peut donner une bonne latence si la fréquence des messages est faible. Cependant, si vous avez deux messages (du serveur au client) en succession rapide, le second n'arrivera pas au client jusqu'à ce qu'une nouvelle demande soit faite après la réception du premier message.
Je pense que quelqu'un a abordé HTTP KeepAlive. Cela peut évidemment améliorer l'interrogation longue - vous avez toujours les frais généraux de l'aller-retour et des en-têtes, mais pas toujours la création du socket.
Où WebSocket devrait améliorer le streaming HTTP dans les scénarios où il y a plus de messages client à serveur. Relier ces scénarios au monde réel crée des configurations un peu plus arbitraires, par rapport à la simple "compréhension de l'envoi de nombreux messages à de nombreux clients" que tout le monde peut comprendre. Par exemple, dans une application de trading, la création d'un scénario dans lequel vous incluez des utilisateurs exécutant des transactions (c'est-à-dire des messages client-serveur) est facile, mais les résultats sont un peu moins significatifs que les scénarios serveur-client de base. Les traders n'essaient pas de faire 100 trades/sec - vous vous retrouvez donc avec des résultats comme '10000 utilisateurs reçoivent 100 messages/sec tout en envoyant un message client toutes les 5 minutes'. La partie la plus intéressante pour le message client-serveur est la latence, car le nombre de messages requis est généralement insignifiant par rapport aux messages serveur-client.
Un autre point que quelqu'un a mentionné ci-dessus, à propos des clients 64k, vous n'avez rien à faire d'intelligent pour prendre en charge plus de 64k sockets sur un serveur - autre que la configuration des descripteurs de fichiers numériques, etc. Si vous essayez d'établir une connexion 64k à partir d'une seule machine cliente , c'est totalement différent car ils ont besoin d'un numéro de port pour chacun - du côté du serveur, c'est bien, c'est-à-dire de l'écoute, et vous pouvez aller au-dessus de 64k sockets bien.
En théorie, WebSockets peut évoluer bien mieux que HTTP, mais il existe également des mises en garde et des moyens de les résoudre.
La complexité du traitement de l'en-tête d'établissement de liaison entre HTTP et WebSockets est à peu près la même. La prise de contact HTTP (et WebSocket initiale) peut facilement dépasser 1 Ko de données (en raison des cookies, etc.). La différence importante est que la prise de contact HTTP se produit à nouveau chaque message. Une fois qu'une connexion WebSocket est établie, la surcharge par message n'est que de 2 à 14 octets.
Les excellents liens de référence Jetty publiés dans la réponse de @David Titarenco ( 1 , 2 ) montrent que les WebSockets peuvent facilement atteindre plus d'un ordre de magnitude meilleure latence par rapport à Comet.
Voir cette réponse pour plus d'informations sur la mise à l'échelle de WebSockets vs HTTP.
Mises en garde :
Les connexions WebSocket sont de longue durée contrairement aux connexions HTTP qui sont de courte durée. Cela réduit considérablement les frais généraux (pas de création et de gestion de socket pour chaque demande/réponse), mais cela signifie que pour faire évoluer un serveur au-dessus de 64 000 hôtes clients simultanés distincts, vous devrez utiliser des astuces comme plusieurs adresses IP sur le même serveur.
En raison de problèmes de sécurité avec les intermédiaires Web, les messages WebSocket du navigateur au serveur ont toutes les données utiles XOR masquées. Cela ajoute une certaine utilisation du processeur au serveur pour décoder les messages. Cependant, XOR est l'une des opérations les plus efficaces de la plupart des architectures de processeur et il existe souvent une assistance matérielle disponible. Les messages du serveur au navigateur ne sont pas masqués et puisque de nombreuses utilisations de WebSockets ne nécessitent pas de grandes quantités de données envoyées du navigateur au serveur, ce n'est pas un gros problème.
Il est difficile de savoir comment cela se compare à quoi que ce soit, car nous ne savons pas quelle est la taille (moyenne) de la charge utile. Sous le capot (comme dans la façon dont le serveur est implémenté), le streaming HTTP et les websockets sont pratiquement identiques - à part la poignée de main initiale qui est plus compliquée lorsque cela est fait avec HTTP évidemment.
Si vous avez écrit votre propre serveur websocket en C (ala Caplin), vous pourriez probablement atteindre ces chiffres sans trop de difficulté. La plupart des implémentations Websocket sont effectuées via des packages de serveurs existants (comme Jetty), de sorte que la comparaison ne serait pas vraiment juste.
Quelques repères :
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
http://webtide.intalio.com/2011/08/prelim-cometd-websocket-benchmarks/
Cependant, si vous regardez les références de la bibliothèque d'événements C, comme libev et libevent, les chiffres semblent beaucoup plus sexy:
http://libev.schmorp.de/bench.html
En ignorant toute forme d'interrogation, qui, comme expliqué ailleurs, peut introduire une latence lorsque le taux de mise à jour est élevé, les trois techniques les plus courantes pour le streaming JavaScript sont:
- WebSocket
- Streaming Comet XHR/XDR
- Comet Forever IFrame
WebSocket est de loin la solution la plus propre, mais il y a toujours des problèmes en termes de navigateur et d'infrastructure réseau qui ne la prennent pas en charge. Le plus tôt on peut s'y fier, mieux c'est.
XHR/XDR et Forever IFrame sont tous deux parfaits pour transmettre des données aux clients à partir du serveur, mais nécessitent divers piratages pour qu'ils fonctionnent de manière cohérente sur tous les navigateurs. D'après mon expérience, ces approches Comet sont toujours légèrement plus lentes que WebSockets, notamment parce qu'il y a beaucoup plus de code JavaScript côté client requis pour le faire fonctionner - du point de vue du serveur, cependant, l'envoi de données via le câble se fait à la même vitesse.
Voici encore plus graphiques de référence WebSocket , cette fois pour notre produit my-Channels Nirvana .
Passer les graphiques de multidiffusion et de données binaires jusqu'au dernier graphique de la page (taux de mise à jour élevé de JavaScript)
En résumé - Les résultats montrent que Nirvana WebSocket fournit 50 événements/sec à 2 500 000 utilisateurs avec une latence de 800 microsecondes. À 5 000 utilisateurs (total de 250 000 événements/s diffusés en continu), la latence est de 2 millisecondes.