Les WebSockets HTML maintiennent-ils une connexion ouverte pour chaque client? Cette échelle?
je suis curieux si quelqu'un a des informations sur l'évolutivité des sites Web HTML. Pour tout ce que j'ai lu, il semble que chaque client maintiendra une ligne ouverte de communication avec le serveur. Je me demande juste comment cette balance et combien de connexions WebSocket ouvertes un serveur peut gérer. Peut-être que laisser ces connexions ouvertes n'est pas un problème dans la réalité, mais il se sent comme il est.
5 réponses
dans la plupart des façons les WebSockets seront probablement mieux dimensionnés que les requêtes AJAX/HTML. Cependant, cela ne signifie pas que WebSockets est un remplacement pour toutes les utilisations D'AJAX/HTML.
chaque connexion TCP en elle-même consomme très peu en termes de ressources du serveur. Souvent, la mise en place de la connexion peut être coûteuse, mais le maintien d'une connexion inactive est presque gratuit. La première limitation est généralement rencontré est le nombre maximum de descripteurs de fichiers (sockets consommer fichier descripteurs) qui peuvent être ouvertes simultanément. Ceci est souvent par défaut à 1024 mais peut facilement être configuré plus haut.
avez-vous déjà essayé de configurer un serveur web pour prendre en charge des dizaines de milliers de clients AJAX simultanés? Changer ces clients en clients WebSockets et cela pourrait être faisable.
les connexions HTTP, bien qu'elles ne créent pas de fichiers ouverts ou ne consomment pas de numéros de port pendant une longue période, sont plus chères dans presque tous les autres cas:
-
" chaque connexion HTTP transporte beaucoup de bagages qui ne sont pas utilisés la plupart du temps: cookies, type de contenu, longueur du contenu, user-agent, server id, date, last-modified, etc. Une fois qu'une connexion WebSockets est établie, seules les données requises par l'application doivent être envoyées de part et d'autre.
-
typiquement, les serveurs HTTP sont configurés pour enregistrer le début et la fin de chaque requête HTTP prenant disque et CPU temps. Il deviendra standard pour enregistrer le début et l'achèvement des données de WebSockets, mais tandis que la connexion WebSockets faisant le transfert duplex il n'y aura pas de journalisation supplémentaire de frais généraux (sauf par l'application/service si elle est conçue pour le faire).
-
typiquement, les applications interactives qui utilisent AJAX soit en continu poll ou utiliser une sorte de long-poll mécanisme. WebSockets est une façon beaucoup plus propre (et moins de ressources) de faire un événement plus modèle où le serveur et le client se notifient mutuellement quand ils ont quelque chose à signaler sur la connexion existante.
-
la plupart des serveurs Web populaires en production ont un ensemble de processus (ou threads) pour traiter les requêtes HTTP. Au fur et à mesure que la pression augmente, la taille du pool augmente parce que chaque processus/thread gère une requête HTTP à la fois. Chaque processus/thread supplémentaire utilise plus de mémoire et la création de nouveaux processus / threads est tout à fait un peu plus cher que de créer de nouvelles connexions de socket (ce que ces processus/threads doivent encore faire). La plupart des cadres de serveur WebSockets populaires vont la route de l'événement qui a tendance à se dimensionner et à mieux fonctionner.
le principal avantage des WebSockets sera des connexions à faible latence pour les applications Web interactives. Il prendra une meilleure échelle et consommera moins de ressources serveur que HTTP AJAX / long-poll (en supposant que l'application / serveur est conçu correctement), mais IMO plus faible latence est le principal avantage de WebSockets parce qu'il permettra de nouvelles classes d'applications web qui ne sont pas possibles avec les frais généraux actuels et la latence de AJAX/long-poll.
une fois que la norme WebSockets sera plus finalisée et plus largement appuyée, il sera logique de l'utiliser pour la plupart des nouvelles applications Web interactives qui doivent communiquer fréquemment avec le serveur. Pour les applications Web interactives existantes, dépend de l'efficacité du modèle AJAX/long-poll actuel. Les efforts pour convertir sera non négligeable donc, dans de nombreux cas, les coûts ne vaut pas le bénéfice.
mise à Jour :
lien Utile: 600k simultanées websocket connexions sur AWS l'aide d'un Noeud.js
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, puisque le serveur n'écoute [typiquement] que les connexions WS/WSS sur un seul port. Je pense que les autres commentateurs voulaient parler de descripteurs de fichiers. Vous pouvez définir le nombre maximum de descripteurs de fichiers assez élevé, mais vous devez ensuite faire attention aux tailles de tampon de socket qui s'additionnent pour chaque socket TCP/IP OUVERT. Voici quelques informations supplémentaires: https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system
quant à la diminution de la latence via WS vs. HTTP, c'est vrai puisqu'il n'y a plus d'analyse des en-têtes HTTP au-delà de la poignée de main WS initiale. De plus, comme de plus en plus de paquets sont envoyés avec succès, la fenêtre de congestion TCP s'élargit, réduisant ainsi la RTT.
N'importe quel serveur simple moderne est capable de servir des milliers de clients à la fois . Son logiciel de serveur HTTP doit juste être orienté Event-Driven (IOCP) (nous ne sommes plus dans L'ancienne équation Apache one connection = one thread/process). Même le serveur HTTP construit sous Windows (http.sys) est orienté IOCP et très efficace (tournant en mode noyau). De ce point de vue, il n'y aura pas beaucoup de différence d'échelle entre les WebSockets et les HTTP réguliers. connexion. Une connexion TCP / IP utilise une petite ressource (beaucoup moins qu'un thread), et les systèmes D'exploitation modernes sont optimisés pour gérer un grand nombre de connexions simultanées: les WebSockets et le HTTP ne sont que des protocoles OSI 7, héritant de ces spécifications TCP/IP.
mais, de l'expérience, j'ai vu deux principaux problèmes avec WebSockets:
- Ils ne prennent pas en charge CDN;
- ils ont des problèmes de sécurité potentiels.
donc je recommande ce qui suit, pour tout projet:
- utilisez des WebSockets pour les notifications des clients seulement (avec un mécanisme de secours à long-polling - il y a beaucoup de bibliothèques autour);
- utilisez RESTful / JSON pour toutes les autres données, en utilisant un CDN ou des mandataires pour le cache.
en pratique, les applications full WebSockets ne sont pas à l'échelle bien. Il suffit d'utiliser les WebSockets pour ce pour quoi ils ont été conçus: pousser les notifications du serveur vers le client.
Sur les problèmes potentiels d'utiliser les WebSockets:
1. Envisager D'utiliser un CDN
Aujourd'hui (presque 4 ans plus tard), la mise à l'échelle Web implique l'utilisation de réseau de livraison de contenu (CDN) front ends, non seulement pour le contenu statique (html,css, js), mais aussi votre (JSON) les données de l'application .
bien sûr, vous ne mettrez pas toutes vos données sur votre cache CDN, mais en pratique, beaucoup de contenu commun ne changera pas souvent. Je soupçonne que 80% de vos ressources de repos peuvent être mises en cache... Même un délai D'expiration CDN d'une minute (ou 30 secondes) peut être suffisant pour donner à votre serveur central un nouveau live, et améliorer la réactivité de l'application beaucoup, puisque CDN peut être réglé géographiquement...
à mon en fait, il n'y a pas encore de support de WebSockets en CDN, et je pense qu'il n'y en aura jamais. Les WebSockets sont statefull, tandis que le HTTP est apatride, donc facilement mis en cache. En fait, pour rendre WebSockets CDN-friendly, vous pouvez avoir besoin de passer à une approche de repos apatride... ce qui ne serait plus des WebSockets.
2. Questions de sécurité
Les WebSocketspeuvent présenter des problèmes de sécurité, en particulier en ce qui concerne les attaques DOS. Pour l'illustration à propos des nouvelles vulnérabilités de sécurité , voir cet ensemble de diapositives et ce ticket webkit .
Les WebSocketsévitent toute possibilité d'inspection de paquets au niveau de la couche application OSI 7, ce qui est devenu assez standard de nos jours, dans n'importe quelle sécurité d'entreprise. En fait, WebSockets rend la transmission obscurcie, donc peut - être une violation majeure de la fuite de sécurité.
pensez-y de cette façon: ce qui est moins cher, garder une connexion ouverte, ou ouvrir une nouvelle connexion pour chaque demande (avec la négociation au-dessus de le faire, rappelez-vous que C'est TCP.)
bien sûr, cela dépend de l'application, mais pour les connexions temps réel à long terme (par exemple un chat AJAX), il est de loin préférable de garder la connexion ouverte.
Le nombre max de connexions seront plafonnés par le nombre maximum de ports libres pour les sockets.
Non il ne met pas à l'échelle, donne un travail énorme aux aiguillages de routes intermédiaires. Ensuite, sur le serveur de côté les défauts de page (vous devez conserver tous ces descripteurs) atteignent des valeurs élevées, et le temps d'apporter une ressource dans la zone de travail augmente. Il s'agit principalement de serveurs JAVA écrits et il pourrait être plus rapide de tenir sur ces gazilions de sockets puis de détruire/créer un. Quand vous exécutez un tel serveur sur une machine n'importe quel autre processus ne peut plus bouger.