Comment conserver un million de connexions simultanées TCP?
Je dois concevoir un serveur qui doit servir des millions de clients qui sont simultanément connectés au 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 être derrière un pare-feu) .
Quelqu'un sait-il comment procéder et quel matériel/logiciel est nécessaire (au moindre coût)?
Quels systèmes d'exploitation envisagez-vous pour cela?
Si vous utilisez un système d'exploitation Windows et utilisez quelque chose de plus tard que Vista, vous ne devriez pas avoir de problème avec plusieurs milliers de connexions sur une seule machine. J'ai exécuté des tests (ici: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html ) avec une machine Windows Server 2003 de faible spécification et atteint facilement plus de 70 000 connexions actives TCP. 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 donc vous pourriez probablement atteindre votre objectif avec un petit groupe de machines. Je ne sais pas de quoi vous avez besoin en face de ceux pour acheminer les connexions.
Windows fournit une fonctionnalité appelée ports de complétion d'E/S (voir: http://msdn.Microsoft.com/en-us/magazine/cc302334.aspx ) qui vous permet de gérer plusieurs milliers de connexions simultanées avec très peu de threads (je faisais 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 souhaitez exécuter des tests, j'ai sur mon blog des outils disponibles gratuitement qui vous permettent de détruire un simple serveur d'écho en utilisant plusieurs milliers de connexions ( 1 ) et ( 2 =) et du code gratuit que vous pourriez utiliser pour commencer ()
La deuxième partie de votre question, tirée de vos commentaires, est plus délicate. Si l'adresse IP du client continue de changer et qu'il n'y a rien entre vous et lui qui fournit NAT pour vous donner une adresse IP cohérente, alors leurs connexions seront, sans aucun doute, interrompues et devront être rétablies Si les clients détectent cette connexion s’effondrent lorsque leur adresse IP change, ils peuvent se reconnecter au serveur, s’ils ne le peuvent pas, je suggère aux clients d’interroger le serveur de temps en temps afin de pouvoir détecter la connexion perte et reconnexion. 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 essaie d'envoyer des données.
Et rappelez-vous, vos problèmes ne commencent qu'à partir du moment où votre système évolue à ce niveau ...
Ce problème est lié au soi-disant problème C10K . La page C10K répertorie un grand nombre de bonnes ressources pour résoudre les problèmes que vous rencontrerez lorsque vous essayez de permettre à des milliers de clients de se connecter au même serveur.
Je suis tombé sur le Projet APE il y a quelque temps. Cela ressemble à un rêve devenu réalité. Ils peuvent prendre en charge jusqu'à 100 000 clients simultanés sur un seul nœud. Répartissez-les sur 10 ou 20 nœuds et vous pourrez servir des millions de personnes. Parfait pour les applications RESTful. Pourrait vouloir regarder plus en profondeur pour tout espace de noms partagé. Un inconvénient est qu'il s'agit d'un serveur autonome, comme en complément d'un serveur Web. Ce serveur est bien sûr Open Source, donc tout coût est lié au matériel/FAI.
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 l'itinéraire inverse en 30 secondes ou moins, de sorte que votre serveur ne pourra jamais répondre au client.
TCP est la seule option, et cela vous donnera également des maux de tête. La plupart des routeurs vont oublier l'itinéraire et/ou interrompre la connexion après quelques minutes, donc votre code client/serveur devra envoyer assez souvent "keep alives".
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 fonctionne!
Comme Greg l'a mentionné, le problème que vous décrivez est C10K (ou plutôt "C1M" dans votre cas) J'ai récemment créé un serveur d'écho simple TCP sur linux qui évolue très bien avec le nombre de sessions ( seulement testé jusqu'à 200 000 cependant), en utilisant la file d'attente epoll . Sur BSD, vous avez quelque chose de similaire appelé kqueue. Vous pouvez vérifier le code si vous le souhaitez. Hope cela aide et bonne chance!