Je suis curieux de savoir si quelqu'un a d’informations sur l’évolutivité de HTML WebSockets. Pour tout ce que j’ai lu qu'il semble que chaque client maintiendra une ligne ouverte de communication avec le serveur. Je me demande comment qui met à l’échelle et combien ouvre des connexions de WebSocket qu'un serveur peut gérer. Peut-être laisser ces connexions ouverte n’est pas un problème dans la réalité, mais il se sent comme il est.
Réponses
Trop de publicités?
Dans la plupart des WebSockets sera probablement à l'échelle de mieux que de AJAX/HTML demandes. Toutefois, cela ne signifie pas que les WebSockets est un remplacement pour toutes les utilisations de AJAX/HTML.
Chaque connexion TCP en lui-même consomme très peu de ressources du serveur. Souvent, la configuration de la connexion peut être coûteux, mais le maintien d'une connexion inactive, il est presque gratuit. La première limitation est généralement rencontré est le nombre maximum de descripteurs de fichiers (sockets consommer des descripteurs de fichiers) qui peuvent être ouvertes simultanément. De ce fait souvent par défaut est 1024, mais peut facilement être configuré plus haut.
Jamais essayé la configuration d'un serveur web pour prendre en charge des dizaines de milliers de simultanée AJAX clients? Le changement de ces clients dans les WebSockets clients et ça pourrait être faisable.
Les connexions HTTP, alors qu'ils ne créent pas d'ouvrir des fichiers ou de consommer des numéros de port pour une longue période, sont plus chers, dans à peu près tous les autres:
Chaque connexion HTTP porte beaucoup de bagages qui n'est pas utilisée la plupart du temps: les cookies, type de contenu, conetent de la longueur, de l'agent utilisateur, l'id du serveur, la date de dernière modification, etc. Une fois un WebSockets connexion est établie, que les données requises par l'application doit être envoyé en arrière et en avant.
Généralement, HTTP serveurs sont configurés pour connecter le début et la fin de chaque requête HTTP de prendre de l'espace disque et de temps PROCESSEUR. Il va devenir le standard pour connecter le début et la fin des WebSockets de données, mais alors que les WebSockets de connexion faisant duplex de transfert il n'y aura aucun enregistrement supplémentaire, les frais généraux (sauf par l'application/service s'il est conçu pour le faire).
Généralement, les applications interactives que l'utilisation d'AJAX, soit en continu, sondage ou à utiliser une sorte de long-sondage mécanisme. Les WebSockets est beaucoup plus propre (et donc moins de ressources) façon de faire un event avais un modèle où le serveur et le client en informer les uns les autres quand ils ont quelque chose à signaler au cours de la connexion existante.
La plupart des serveurs web les plus populaires dans la production de disposer d'un pool de processus (ou threads) pour le traitement des requêtes HTTP. Comme la pression augmente la taille de la piscine sera augmenté parce que chaque processus/thread gère une requête HTTP à un moment. Chaque processus/thread utilise plus de mémoire et de créer de nouveaux processus/threads est un peu plus cher que d'en créer de nouvelles connexions de socket (qui ces processus/threads reste encore à faire). Les plus populaires, les WebSockets serveur cadres vont l'événement avais route qui tend à l'échelle et de mieux performer.
Le principal avantage des WebSockets sera plus faible temps de latence des connexions pour des applications web interactives. Il sera mis à l'échelle de mieux et consommer moins de ressources du serveur de HTTP AJAX/long-sondage (en supposant que l'application/serveur est conçu correctement), mais l'OMI réduire la latence est le principal avantage des WebSockets parce qu'il va permettre de nouvelles classes d'applications web qui ne sont pas possibles avec le courant frais généraux et des temps de latence de l'AJAX/long-sondage.
Une fois que les WebSockets norme devient plus finalisé et a un soutien plus large, il est logique de l'utiliser pour la plupart des nouvelles des applications web interactives qui ont besoin de communiquer fréquemment avec le serveur. Pour les applications web, il va vraiment dépendre de la manière dont le courant AJAX/long-sondage modèle de travail. Les efforts pour convertir sera non négligeable donc, dans de nombreux cas, les coûts ne vaut pas le bénéfice.
Michael
Points
271
Juste une précision: le nombre de connexions client qu'un serveur peut prendre en charge n'a rien à voir avec les ports dans ce scénario, le serveur étant [généralement] seulement à l'écoute pour WS/WSS connexions sur un port unique. Je pense que ce que les autres intervenants ont voulu faire référence à étaient des descripteurs de fichiers. Vous pouvez définir le nombre maximum de descripteurs de fichiers assez élevé, mais ensuite, vous avez à regarder dehors pour la prise des tailles de mémoire tampon en additionnant pour chaque ouvrir un socket TCP/IP. Voici quelques informations supplémentaires: http://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system
Comme une diminution du temps de latence via WS vs HTTP, c'est vrai qu'il n'y a plus l'analyse des en-têtes HTTP delà de la première WS poignée de main. De Plus, comme de plus en plus les paquets sont envoyés avec succès, la fenêtre de congestion TCP s'élargit, de réduire efficacement la RTT.
Arnaud Bouchez
Points
25855
Tout seul serveur est en mesure de serveur de milliers de clients à la fois. Son serveur HTTP logiciel vient d'être est basé sur l'Événement (IOCP) orienté (nous ne sommes pas dans l'ancien Apache une connexion = un thread/processus de l'équation). Même le serveur HTTP intégré dans Windows (http.sys) est IOCP orientée et très efficace (en cours d'exécution en mode noyau). De ce point de vue, il n'y aura pas beaucoup de différence d'échelle entre les WebSockets et régulier de la connexion HTTP. Une connexion TCP/IP utilise un peu de ressources (beaucoup moins qu'un thread), et les OS modernes sont optimisés pour la manipulation de beaucoup de connexions simultanées: les WebSockets et HTTP sont juste OSI 7 protocoles de la couche application, héritant de ce protocole TCP/IP spécifications.
Mais, à partir de l'expérience, je l'ai vu deux problèmes principaux avec les WebSockets:
- Ils ne prennent pas en charge CDN;
- Ils ont des problèmes potentiels de sécurité.
Je recommanderais donc la suivante, pour tout projet:
- Utiliser les WebSockets pour les notifications client (avec un mécanisme de secours à long-polling - il y a beaucoup de bibliothèques);
- Utilisation RESTful / JSON pour toutes les autres données, à l'aide d'un CDN ou des procurations pour le cache.
Dans la pratique, complet WebSockets les demandes ne sont pas à l'échelle. Suffit d'utiliser les WebSockets pour ce qu'ils ont été conçus pour: les notifications push à partir du serveur vers le client.
Sur les problèmes potentiels d'utiliser les WebSockets:
1. Envisager l'utilisation d'un CDN
Aujourd'hui (presque 4 ans plus tard), le site de mise à l'échelle implique l'utilisation de Réseau de diffusion de Contenu (CDN) les extrémités avant, non seulement pour le contenu statique (html,css,js), mais aussi votre (JSON) les données de l'application.
Bien sûr, vous ne mettez pas toutes vos données sur votre cache du CDN, mais dans la pratique, beaucoup de bon contenu ne change pas souvent. Je soupçonne que 80% de votre REPOS ressources peuvent être mis en cache... Même une minute ou 30 secondes) CA expiration du délai d'attente peut être assez pour donner à votre serveur central d'un nouveau live, et d'améliorer la réactivité de l'application beaucoup, car CA peut être géographiquement à l'écoute...
À ma connaissance, il n'existe pas de WebSockets de soutien dans le domaine du CDN encore, et je crains qu'il ne serait jamais. Les WebSockets sont statefull, alors que HTTP est sans état, donc, est beaucoup plus facilement mis en cache. En fait, pour faire les WebSockets CDN-friendly, vous devrez peut-être passer à un apatride Reposant approche... qui ne seraient pas les WebSockets.
2. Les questions de sécurité
Les WebSockets avoir des problèmes de sécurité, en particulier sur les attaques DOS. À des fins d'illustration sur les nouvelles failles de sécurité , voir cette série de diapositives et ce webkit billet.
Les WebSockets d'éviter toute chance de packet inspection à l'OSI 7 application de la couche de niveau, ce qui revient à être assez standard de nos jours, dans tous les métiers de la sécurité. En fait, les WebSockets rend la transmission d'obfuscation, donc peut être une violation majeure de la sécurité de fuite.
kaoD
Points
995
Pensez-y de cette façon : ce qui est moins cher, garder une connexion ouverte, ou ouvrir une nouvelle connexion à chaque requête (avec la surcharge de négociation de le faire, n’oubliez pas c' est TCP.)
Bien sûr cela dépend de l’application, mais à long terme en temps réel connexions (par exemple un chat AJAX), il est préférable de garder la connexion ouverte.
Le nombre maximum de connexions sera plafonné par le nombre maximum de ports francs pour les prises.
