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


114

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?


2
Toutes mes excuses aux intervenants, j'ai déchiré ce fil comme une tornade. Il y avait tout simplement trop de réponses incorrectes à mon goût, et toujours pas de réponse directe. J'utilise beaucoup stackoverflow et je trouve de nombreuses réponses de haute qualité. J'espère que d'autres pourront trouver ce fil et trouver une réponse éclairée utile.
Todd

Salut David, as-tu trouvé la bonne réponse à cette question?
Plat

64000 connexions TCP sur une seule adresse IP du serveur. Vous pouvez mettre à niveau votre réseau de serveurs pour évoluer et prendre en charge plus de 64 000.
Airy

Réponses:


109

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.

2
Merci d'avoir inclus des liens vers des personnes qui expliquent comment elles le font.
Rick Smith

Que faire si le serveur unique auquel le client s'est connecté tombe en panne? Et si tout votre SPA était connecté au hasard à un serveur et le surchargeait? L'idée d'utiliser des équilibreurs de charge n'est pas seulement d'utiliser 1, vous pouvez en utiliser autant que vous le souhaitez
pyros2097

3
Les clients sélectionneraient un serveur au hasard. Les chances que tous se connectent au hasard à l'un d'eux sont pratiquement impossibles. Bien que l'on puisse suivre le nombre de clients et que le serveur puisse demander à un client de passer à un autre serveur s'il est trop surpeuplé.
Todd

1
Re: la limitation 64K - ce que vous dites est vrai, mais il est assez courant pour une application serveur de transmettre des requêtes par proxy à certains services backend, auquel cas le "serveur" devient maintenant un "client" et peut bien avoir pour s'inquiéter de l'épuisement éphémère des ports (par exemple: nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus ). Je suis sûr que vous le savez, mais en le mentionnant pour les autres (:
jwd

@jwd bon point, contextuel pour nginx sur une application Web, mais pour un site Web de base, un tel proxy n'aurait pas besoin de se produire. On pourrait également dire la même chose de la connexion à une base de données via TCP par une application Web. En théorie, cela est résolu en utilisant toutes les adresses de la plage 127. *. *. *, Mais en pratique, je ne sais pas si c'est une option disponible.
Todd

54

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.


3
Une réponse un peu mitigée. Le PO semble faire référence à un meilleur scénario, et inclure comment serait bénéfique, plutôt que de trouver le pire des cas et de se référer ensuite à un article qui pourrait avoir la solution. Il est utile de noter le goulot d'étranglement du disque. En utilisant les E / S asynchrones, un très grand nombre de clients simultanés peuvent être atteints.
Todd

Comment pouvez-vous dire qu'il n'y a pas de réelle limitation logicielle puisque la taille du port est elle-même de 16 bits, ce qui rend le maximum de ports disponibles à tout instant à un maximum de 65,5K. Je pense que votre réponse est incorrecte.
आनंद

Votre machine peut avoir plus d'une adresse IP, donc plus de 2 ^ 16 ports sont disponibles.
Arman Ordookhani

8

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


1
Bien que cela soit peut-être vrai pour Linux, cela fait référence à une limite virtuelle, pas à une référence des possibilités. Cette réponse est un peu spécifique à mon goût et ne fournit aucun nombre ou indication du nombre de connexions simultanées. Malgré vos efforts, ce n'est pas très utile. Peut-être pourriez-vous répondre par vous-même à une question: "Pourquoi ne puis-je pas serveur plus de X connexions TCP simultanées sur Linux"
Todd

2
Autant que je sache, c'est faux . somaxconn est le nombre maximum de connexions en file d'attente sur un socket ouvert (c'est-à-dire la valeur maximale du paramètre backlog de listen(int socket, int backlog). Il n'est pas lié au nombre de sockets qu'un processus peut ouvrir.
Timmmm

8

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/


Grands nouveaux liens, avec une compréhension correcte de la question. J'aime le conseil général pour hit-barrière -> fixer la barrière. Chacun a une situation spécifique différente, mais au moins ils ont ici une indication de ce qui est économiquement / pratiquement réalisable. Il ne faut pas promettre à un client 100 millions par serveur de si tôt.
Todd

5

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.


12
Cela ne répond pas du tout à la question. Indépendamment de l'exactitude de ce que vous avez dit, il y aurait encore un certain nombre de connexions TCP simultanées à un moment donné, quel est le maximum? Telle est l'essence de la question.
Todd

3
Si vous avez quelque chose de valable à apporter, Todd, allez-y et faites-le.
Jeremy Friesner

8
J'ai déjà eu une réponse le 28 mars, vous devez l'avoir ratée. Dans le monde moderne des applications à page unique avec des connexions d'interrogation longue et de socket Web, HTTP n'est pas toujours de courte durée. Mais même si elle est de courte durée, il y a toujours un nombre maximum de connexions simultanées. Tenter d'expliquer la question n'est pas une réponse à l'OMI. Cette réponse serait mieux placée comme commentaire sur la question, c'est certainement utile, mais la question concerne les "connexions de socket", pas les "personnes". Une question sur le ratio (utilisateurs: connexions actives) doit être une question distincte si vous le souhaitez.
Todd

1
Keep Alive sur HTTP Les connexions TCP existent et sont demandées par les navigateurs depuis le dernier millénaire - c'est au serveur de décider si elle permet à la connexion de rester active et quel sera le délai d'inactivité. Autoriser Keep Alive réduit la latence d'un groupe de requêtes (par exemple une page html et ses ressources associées), mais augmente l'utilisation des ressources sur le serveur.
iheggie

1

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


0

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.


pour votre bénéfice, j'ai ajouté une section supplémentaire à ma réponse pour traiter votre idée fausse. Cette question concerne également les «connexions de socket» et non les «personnes», ce qui constitue une distinction importante dans le contexte de cette question.
Todd

Si nous parlons d'une seule machine serveur et d'un seul routeur, je pense que cette réponse est juste. Mais @Todd utilise une batterie de serveurs, que l'utilisateur peut connecter à n'importe lequel d'entre eux de manière aléatoire via un équilibreur de charge.
Amr

@amr c'est incorrect. Ma réponse concerne une seule machine. Le "Webfarm?" section est là pour le contraste et des conseils pour aller au-delà et conclut que les équilibreurs de charge ne sont pas nécessaires avec une bonne architecture. Vous n'avez tout simplement pas encore lu complètement ma réponse.
Todd

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.