Comment conserver un million de connexions TCP simultanées ?

Question

Je dois concevoir un serveur qui doit servir des millions de clients qui sont simultanément connecté avec le serveur via TCP.

Le trafic de données entre le serveur et les clients sera faible, de sorte que les problèmes de bande passante peuvent être ignorés.

Une exigence importante est que chaque fois que le serveur doit envoyer des données à un client, il doit utiliser la connexion TCP existante au lieu d'ouvrir une nouvelle connexion vers le client (car le client peut se trouver derrière un pare-feu).

Quelqu'un sait-il comment faire, et quel matériel/logiciel est nécessaire (au moindre coût) ?

Answer 1

Quels systèmes d'exploitation envisagez-vous pour cela ?

Si vous utilisez un système d'exploitation Windows et une version ultérieure à Vista, vous ne devriez pas avoir de problème avec plusieurs milliers de connexions sur une seule machine. J'ai effectué des tests (ici : http://www.lenholgate.com/blog/2005/11/Windows-tcpip-server-performance.html ) avec une machine Windows Server 2003 de faible puissance et a facilement atteint plus de 70 000 connexions TCP actives. Certaines des limites de ressources qui affectent le nombre de connexions possibles ont été considérablement levées sur Vista (voir ici : http://www.lenholgate.com/blog/2005/11/Windows-tcpip-server-performance.html ) et vous pourriez donc probablement atteindre votre objectif avec un petit groupe de machines. Je ne sais pas ce dont vous auriez besoin en amont de celles-ci pour acheminer les connexions.

Windows fournit une fonction appelée Ports de complétion d'E/S (voir : http://msdn.microsoft.com/en-us/magazine/cc302334.aspx ) qui vous permettent de servir plusieurs milliers de connexions simultanées avec très peu de threads (j'ai fait des tests hier avec 5000 connexions saturant un lien vers un serveur avec 2 threads pour traiter les E/S...). L'architecture de base est donc très évolutive.

Si vous voulez faire des tests, j'ai quelques outils disponibles gratuitement sur mon blog qui vous permettent d'écraser un simple serveur d'écho en utilisant plusieurs milliers de connexions ( 1 ) et ( 2 ) et un code gratuit que vous pouvez utiliser pour commencer ( 3 )

La deuxième partie de votre question, d'après vos commentaires, est plus délicate. Si l'adresse IP du client change constamment et qu'il n'y a rien entre vous et lui qui fournisse une NAT pour vous donner une adresse IP cohérente, alors leurs connexions seront sans doute interrompues et devront être rétablies. Si les clients détectent cette rupture de connexion lorsque leur adresse IP change, ils peuvent se reconnecter au serveur. S'ils ne le peuvent pas, je suggère que les clients interrogent le serveur de temps en temps afin de détecter la perte de connexion et de se reconnecter. Le serveur ne peut rien faire ici car il ne peut pas prédire la nouvelle adresse IP et il découvrira que l'ancienne connexion a échoué lorsqu'il essaiera d'envoyer des données.

Et n'oubliez pas que vos problèmes ne font que commencer une fois que votre système est passé à ce niveau...

Answer 2

Ce problème est lié à ce que l'on appelle C10K problème. La page C10K répertorie un grand nombre de bonnes ressources pour résoudre les problèmes que vous rencontrerez lorsque vous tenterez de permettre à des milliers de clients de se connecter au même serveur.

Answer 3

Je suis tombé sur le APE Projet il y a quelque temps. Cela semble être un rêve devenu réalité. Ils peuvent supporter jusqu'à 100 000 clients simultanés sur un seul nœud. Répartis sur 10 ou 20 nœuds, vous pouvez en servir des millions. Parfait pour les applications RESTful. Vous pourriez vouloir regarder plus profondément pour tout espace de noms partagé. Un inconvénient est qu'il s'agit d'un serveur autonome, c'est-à-dire complémentaire à un serveur web. Ce serveur est bien sûr Open Source, donc tout coût est lié au matériel/ISP.

Answer 4

@Chris, je ne pense pas qu'il soit correct que les routeurs abandonnent des routes selon que les programmes d'application répondent ou non aux requêtes TCP ou UDP. Les routeurs peuvent abandonner des routes si des messages contenant des mises à jour de routage ne sont pas reçus, mais pas sur la base de messages génériques de programmes d'application.

Answer 5

Vous ne pouvez pas utiliser UDP. Si le client envoie une demande et que vous ne répondez pas immédiatement, un routeur va oublier la route inverse en 30 secondes ou moins, de sorte que votre serveur ne pourra jamais répondre au client.

TCP est la seule option, et elle aussi vous donnera des maux de tête. La plupart des routeurs vont oublier la route et/ou interrompre la connexion après quelques minutes, de sorte que votre code client/serveur va devoir envoyer des "keep alives" assez souvent.

Je recommande de mettre en place un "sniffer", pour voir comment les compagnies de téléphone restent en contact avec votre smartphone pour leur technologie "push". Copiez tout ce qu'ils font, parce que ce genre de choses travaux !