Combien de connexions socket un serveur Web peut-il gérer?

Disons que si je devais obtenir un hébergement partagé, virtuel ou dédié, je lis quelque part qu'un serveur / une machine ne peut gérer que 64 000 connexions TCP à la fois, est-ce vrai? Combien d'hébergeurs pourraient-ils en gérer quelle que soit la bande passante? Je suppose que HTTP fonctionne sur TCP.

Cela signifierait-il que seuls 64 000 utilisateurs pourraient se connecter au site Web, et si je voulais en servir davantage, je devrais passer à une ferme Web?

En bref: vous devriez pouvoir réaliser de l' ordre de millions de connexions TCP actives simultanées et par extension de requête (s) HTTP. Cela vous indique les performances maximales auxquelles vous pouvez vous attendre avec la bonne plate-forme avec la bonne configuration.

Aujourd'hui, je m'inquiétais de savoir si IIS avec ASP.NET prendrait en charge dans l'ordre de 100 connexions simultanées (regardez ma mise à jour, attendez ~ 10k réponses par seconde sur les anciennes versions d'ASP.Net Mono). Quand j'ai vu cette question / réponses, je n'ai pas pu m'empêcher de me répondre, de nombreuses réponses à la question ici sont complètement incorrectes.

Meilleur cas

La réponse à cette question ne doit concerner que la configuration de serveur la plus simple à découpler des innombrables variables et configurations possibles en aval.

Considérez donc le scénario suivant pour ma réponse:

1. Pas de trafic sur les sessions TCP, sauf pour les paquets keep-alive (sinon, vous auriez évidemment besoin d'une quantité correspondante de bande passante réseau et d'autres ressources informatiques)
2. Logiciel conçu pour utiliser des sockets et une programmation asynchrones, plutôt qu'un thread matériel par requête d'un pool. (c.-à-d. IIS, Node.js, Nginx ... serveur Web [mais pas Apache] avec un logiciel d'application conçu par asynchrone)
3. Bonnes performances / CPU dollar / Ram. Aujourd'hui, arbitrairement, disons i7 (4 cœurs) avec 8 Go de RAM.
4. Un bon pare-feu / routeur pour correspondre.
5. Pas de limite virtuelle / gouverneur - c.-à-d. Linux somaxconn, IIS web.config ...
6. Aucune dépendance à un autre matériel plus lent - aucune lecture à partir du disque dur, car ce serait le plus petit dénominateur commun et le goulot d'étranglement, pas les E / S réseau.

Réponse détaillée

Les conceptions liées aux threads synchrones ont tendance à être les moins performantes par rapport aux implémentations d'E / S asynchrones.

WhatsApp obtient un million de trafic AVEC sur une seule machine OS à saveur Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .

Et enfin, celui-ci, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , entre dans beaucoup de détails , explorant comment même 10 millions pourraient être atteints. Les serveurs ont souvent des moteurs de déchargement TCP matériels, des ASIC conçus pour ce rôle spécifique plus efficacement qu'un processeur à usage général.

Bons choix de conception de logiciels

La conception d'E / S asynchrones diffère selon les systèmes d'exploitation et les plates-formes de programmation. Node.js a été conçu dans un esprit asynchrone . Vous devriez utiliser au moins Promises, et quand ECMAScript 7 arrive, async/ await. C # /. Net a déjà un support asynchrone complet comme node.js. Quels que soient le système d'exploitation et la plate-forme, le système asynchrone devrait fonctionner très bien. Et quelle que soit la langue que vous choisissez, recherchez le mot-clé "asynchrone", la plupart des langages modernes auront un support, même s'il s'agit d'un module complémentaire.

Vers WebFarm?

Quelle que soit la limite de votre situation particulière, oui, une ferme Web est une bonne solution à la mise à l'échelle. Il existe de nombreuses architectures pour y parvenir. L'un utilise un équilibreur de charge (les fournisseurs d'hébergement peuvent les proposer, mais même ceux-ci ont une limite, ainsi qu'un plafond de bande passante), mais je ne suis pas favorable à cette option. Pour les applications à page unique avec des connexions de longue durée, je préfère plutôt avoir une liste ouverte de serveurs parmi lesquels l'application cliente choisira au hasard au démarrage et réutilisera pendant la durée de vie de l'application. Cela supprime le point de défaillance unique (équilibreur de charge) et permet la mise à l'échelle via plusieurs centres de données et donc beaucoup plus de bande passante.

Briser un mythe - 64K ports

Pour répondre à la question concernant «64 000», c'est une idée fausse. Un serveur peut se connecter à plus de 65535 clients. Voir /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

À propos, Http.sys sous Windows permet à plusieurs applications de partager le même port de serveur sous le schéma d'URL HTTP. Ils enregistrent chacun une liaison de domaine distincte, mais il n'y a finalement qu'une seule application serveur qui transmet les demandes aux applications appropriées.

Mise à jour 2019-05-30

Voici une comparaison à jour des bibliothèques HTTP les plus rapides - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

• Date du test: 2018-06-06
• Matériel utilisé: Dell R440 Xeon Gold + 10 GbE
• Le leader a ~ 7 millions de réponses en texte brut par seconde (réponses et non connexions)
• Le second Fasthttp pour golang annonce 1,5 million de connexions simultanées - voir https://github.com/valyala/fasthttp
• Les principaux langages sont Rust, Go, C ++, Java, C et même C # se classant à 11 (6,9 millions par seconde). Scala et Clojure se classent plus bas. Python se classe au 29e rang à 2,7 millions par seconde.
• En bas de liste, je note laravel et cakephp, rails, aspnet-mono-ngx, symfony, zend. Tous en dessous de 10k par seconde. Notez que la plupart de ces frameworks sont construits pour des pages dynamiques et assez anciens, il peut y avoir des variantes plus récentes qui figurent plus haut dans la liste.
• N'oubliez pas qu'il s'agit de texte en clair HTTP, pas pour la spécialité Websocket: de nombreuses personnes qui viennent ici seront probablement intéressées par des connexions simultanées pour websocket.

Cette question est assez difficile. Il n'y a pas de réelle limitation logicielle sur le nombre de connexions actives qu'une machine peut avoir, bien que certains systèmes d'exploitation soient plus limités que d'autres. Le problème devient un problème de ressources. Par exemple, disons qu'une seule machine souhaite prendre en charge 64 000 connexions simultanées. Si le serveur utilise 1 Mo de RAM par connexion, il aura besoin de 64 Go de RAM. Si chaque client a besoin de lire un fichier, la charge d'accès au disque ou à la matrice de stockage devient beaucoup plus importante que ces périphériques ne peuvent gérer. Si un serveur a besoin de créer un processus par connexion, le système d'exploitation passera la majorité de son temps à changer de contexte ou à affamer les processus pour le temps CPU.

La page de problème C10K a une très bonne discussion sur ce problème.

Pour ajouter mes deux cents à la conversation, un processus peut ouvrir simultanément un nombre de sockets connectés égal à ce nombre (dans les systèmes de type Linux) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

Ce numéro peut être modifié à la volée (uniquement par l'utilisateur root bien sûr)

echo 1024> / proc / sys / net / core / somaxconn

Mais dépend entièrement du processus du serveur, du matériel de la machine et du réseau, du nombre réel de prises pouvant être connectées avant de planter le système

Il semble que la réponse soit d'au moins 12 millions si vous avez un serveur costaud, votre logiciel serveur est optimisé pour cela, vous avez suffisamment de clients. Si vous testez d'un client à un serveur, le nombre de numéros de port sur le client sera l'une des limites de ressources évidentes (chaque connexion TCP est définie par la combinaison unique d'IP et de numéro de port à la source et à la destination).

(Vous devez exécuter plusieurs clients, sinon vous atteignez d'abord la limite de 64 Ko sur les numéros de port)

En fin de compte, c'est un exemple classique de l'esprit d'esprit selon lequel "la différence entre la théorie et la pratique est beaucoup plus grande en pratique qu'en théorie" - en pratique, atteindre les nombres plus élevés semble être un cycle de a. proposer des modifications spécifiques de configuration / architecture / code, b. testez-le jusqu'à ce que vous atteigniez une limite, c. Ai-je fini? Sinon, d. déterminer quel était le facteur limitant, e. revenir à l'étape a (rincer et répéter).

Voici un exemple avec 2 millions de connexions TCP sur un boitier costaud (128 Go de RAM et 40 cœurs) exécutant Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - ils se sont terminés jusqu'à avoir besoin d'une cinquantaine de serveurs raisonnablement importants juste pour fournir la charge client (leurs petits clients initiaux ont atteint leur maximum trop tôt, par exemple "ont atteint un maximum de 4core / 15gb box @ 450k clients").

Voici une autre référence pour aller cette fois à 10 millions: http://goroutines.com/10m .

Cela semble être basé sur Java et 12 millions de connexions: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

Notez que HTTP ne garde généralement pas les connexions TCP ouvertes plus longtemps qu'il n'en faut pour transmettre la page au client; et il faut généralement beaucoup plus de temps à l'utilisateur pour lire une page Web qu'il n'en faut pour télécharger la page ... pendant que l'utilisateur consulte la page, il n'ajoute aucune charge au serveur.

Ainsi, le nombre de personnes qui peuvent consulter simultanément votre site Web est beaucoup plus grand que le nombre de connexions TCP qu'il peut servir simultanément.

Dans le cas du protocole IPv4, le serveur avec une adresse IP qui écoute sur un seul port peut gérer 2 ^ 32 adresses IP x 2 ^ 16 ports donc 2 ^ 48 sockets uniques. Si vous parlez d'un serveur en tant que machine physique et que vous êtes capable d'utiliser les 2 ^ 16 ports, il peut y avoir au maximum 2 ^ 48 x 2 ^ 16 = 2 ^ 64 sockets TCP / IP uniques pour une adresse IP. Veuillez noter que certains ports sont réservés au système d'exploitation, donc ce nombre sera inférieur. Pour résumer:

1 IP et 1 port -> 2 ^ 48 prises

1 IP et tous les ports -> 2 ^ 64 sockets

toutes les sockets IPv4 uniques dans l'univers -> 2 ^ 96 sockets

Il y a deux discussions différentes ici: l'une est le nombre de personnes pouvant se connecter à votre serveur. D'autres ont répondu adéquatement à cette question, je ne vais donc pas m'y attarder.

Autre est le nombre de ports sur lesquels votre serveur peut écouter? Je crois que c'est de là que vient le nombre de 64K. En fait, le protocole TCP utilise un identifiant 16 bits pour un port, qui se traduit par 65536 (un peu plus de 64 Ko). Cela signifie que vous pouvez avoir autant d '"écouteurs" différents sur le serveur par adresse IP.

Je pense que le nombre de connexions de socket simultanées qu'un serveur Web peut gérer dépend en grande partie de la quantité de ressources consommée par chaque connexion et de la quantité de ressources totale disponible sur le serveur, à l'exception de toute autre configuration limitant les ressources du serveur Web.

Pour illustrer, si chaque connexion socket consommait 1 Mo de ressources serveur et que le serveur dispose de 16 Go de RAM disponible (théoriquement), cela signifierait qu'il ne pourrait gérer que (16 Go / 1 Mo) de connexions simultanées. Je pense que c'est aussi simple que ça ... VRAIMENT!

Ainsi, quelle que soit la façon dont le serveur Web gère les connexions, chaque connexion consommera finalement des ressources.