Comment conserver un million de connexions TCP simultanées?

Je suis en train de concevoir un serveur qui doit servir des millions de clients connectés simultanément au serveur via TCP.

Le trafic de données entre le serveur et les clients sera rare, 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).

Est-ce que quelqu’un sait comment faire cela 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 que vous utilisez quelque chose plus tard que Vista, vous ne devriez pas avoir de problème avec plusieurs milliers de connexions sur un seul ordinateur. J’ai effectué des tests (ici: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html ) avec une machine Windows Server 2003 à faible coût et plus de 70 000 TCP actifs les liaisons. Certaines des limites de ressources qui affectent le nombre de connexions possibles ont été considérablement améliorées sous Vista (voir ici: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html ) et ainsi de suite. vous pourriez probablement atteindre votre objective avec un petit groupe de machines. Je ne sais pas ce dont vous auriez besoin pour acheminer les connexions.

Windows fournit une fonction appelée ports d’achèvement E / S (voir: http://msdn.microsoft.com/en-us/magazine/cc302334.aspx ) qui vous permettent de gérer plusieurs milliers de connexions simultanées avec très peu de threads (j’étais en effectuant des tests hier avec 5000 connexions saturant un lien vers un serveur avec 2 threads pour traiter les E / S …). Ainsi, l’architecture de base est très évolutive.

Si vous voulez exécuter des tests, j’ai des outils disponibles gratuitement sur mon blog qui vous permettent de lancer un serveur d’écho simple en utilisant plusieurs milliers de connexions ( 1 ) et ( 2 ) et du code gratuit que vous pouvez utiliser pour démarrer ( 3 )

La deuxième partie de votre question, à partir de vos commentaires, est plus délicate. Si l’adresse IP du client ne cesse de changer et qu’il n’y a rien entre vous et lui qui fournit un NAT pour vous donner une adresse IP cohérente, leurs connexions seront sans aucun doute terminées et devront être rétablies. Si les clients détectent cette connexion, arrêtez-les lorsque leur adresse IP change, puis reconnectez-vous au serveur. Si ce n’est pas le cas, je suggère aux clients d’interroger le serveur de temps en temps pour détecter la perte de connexion. reconnecter. Il n’y a rien que le serveur puisse faire ici, car il ne peut pas prédire la nouvelle adresse IP et il découvrira que l’ancienne connexion a échoué lorsqu’elle tente d’envoyer des données.

Et rappelez-vous que vos problèmes ne font que commencer une fois que votre système a atteint ce niveau …

Ce problème est lié au problème dit C10K . La page C10K répertorie un grand nombre de ressources utiles pour résoudre les problèmes que vous rencontrerez lorsque vous tenterez d’autoriser des milliers de clients à se connecter au même serveur.

Je suis tombé sur le projet APE il y a quelque temps. Cela semble être un rêve devenu réalité. Ils peuvent prendre en charge jusqu’à 100 000 clients concurrents sur un seul nœud. Répartissez-les sur 10 ou 20 nœuds et vous pouvez servir des millions. Parfait pour les applications RESTful. Peut-être voudrez-vous approfondir un espace de noms partagé. Un inconvénient est qu’il s’agit d’un serveur autonome, en complément d’un serveur Web. Ce serveur est bien sûr Open Source, donc tout coût est lié au matériel / aux 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, afin que votre serveur ne puisse jamais répondre au client.

TCP est la seule option, et elle vous donnera également des maux de tête. La plupart des routeurs vont oublier l’itinéraire et / ou abandonner la connexion au bout de quelques minutes. Votre code client / serveur devra donc envoyer assez souvent du “maintien en vie”.

Je recommande de configurer un “renifleur” pour voir comment les compagnies de téléphone restnt en contact avec votre smartphone pour leur technologie “push”. Copiez ce qu’ils font, car ça marche !

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 TCP echo simple sur Linux qui évolue très bien avec le nombre de sessions (seulement testé jusqu’à 200.000). en utilisant la queue epoll . Sur BSD, vous avez quelque chose de similaire appelé kqueue. Vous pouvez consulter le code si vous le souhaitez. J’espère que ça t’aide et bonne chance!

EDIT: Comme indiqué dans les commentaires ci-dessous, mon affirmation initiale selon laquelle il existe une limite de 64 Ko basée sur le nombre de ports est incorrecte. Cependant, le nombre de descripteurs de socket est limité à 32 Ko.

Avec une conception de serveur TCP / IP classique, vous pouvez limiter le nombre de connexions ouvertes simultanées. Le serveur dispose d’un port d’écoute et, lorsqu’un client s’y connecte, le serveur effectue un appel d’acceptation, ce qui crée un nouveau socket sur un port aléatoire pour le rest de la connexion.

Pour gérer plus de 64K connexions simultanées, je pense que vous devez utiliser UDP à la place. Vous n’avez besoin que d’un seul port pour l’écoute du serveur et vous devez gérer les connexions à l’aide d’un ID client 32 bits dans les données de paquet au lieu d’avoir un port distinct pour chaque client. L’ID client 32 bits peut être l’adresse IP du client et le client peut écouter sur un port UDP connu les messages provenant du serveur. Ce port serait le seul à devoir être ouvert sur le pare-feu.

Avec cette approche, votre seule limite est la rapidité avec laquelle vous pouvez gérer et répondre aux messages UDP. Avec des millions de clients, même le trafic clairsemé pourrait vous donner de gros pics, et si vous ne lisez pas les paquets assez rapidement, votre queue d’entrée se remplira et vous commencerez à déposer des paquets. La page C10K à laquelle Greg pointe vous donnera des stratégies pour cela.