Quel est le coût de plusieurs TIME_WAIT côté serveur?

Question

Supposons qu'un client établit beaucoup de connexions éphémères à un serveur.

Si le client ferme la connexion, il y aura beaucoup de ports à l'état TIME_WAIT du côté client. Étant donné que le client manque de ports locaux, il devient impossible de faire une nouvelle tentative de connexion rapidement.

Si le serveur ferme la connexion, je verrai beaucoup de TIME_WAIT sur le serveur. Cependant, cela fait-il du mal? Le client (ou d'autres clients) peut continuer à faire des tentatives de connexion car il ne manque jamais de ports locaux et le nombre d'état TIME_WAIT augmentera côté serveur. Qu'est-ce qui se passe finalement? Quelque chose de mauvais arrive? (ralentissement, crash, connexions perdues, etc.)

Veuillez noter que ma question n'est pas "Quel est l'objectif de TIME_WAIT ?" mais "Que se passe-t-il s'il y a autant d'états TIME_WAIT sur le serveur?" Je sais déjà ce qui se passe lorsqu'une connexion est fermée dans TCP / IP et pourquoi l'état TIME_WAIT est requis. Je n'essaye pas de le dépanner mais je veux juste savoir quel est le problème potentiel avec cela.

Pour le dire simplement, disons netstat -nat | grep: 8080 | grep TIME_WAIT | wc -l imprime 100000 . Ce qui se passerait? Est-ce que la pile réseau O / S ralentit? " Trop de fichiers ouverts " Erreur? Ou simplement rien d'inquiétant?

Answer 1

Chaque socket dans TIME_WAIT consomme de la mémoire dans le noyau, généralement un peu moins qu'un socket ESTABLISHED tout en restant significatif. Un nombre suffisamment important pourrait épuiser la mémoire du noyau ou au moins dégrader les performances, car cette mémoire pourrait être utilisée à d'autres fins. Les sockets TIME_WAIT ne contiennent pas de descripteurs de fichiers ouverts (en supposant qu'ils aient été fermés correctement), vous ne devriez donc pas avoir à vous soucier d'un "trop ??de fichiers ouverts". erreur.

Le socket lie également cette adresse de code src / dst afin qu'il ne puisse pas être réutilisé pendant la durée de l'intervalle TIME_WAIT . . (C’est le but recherché de l’état TIME_WAIT .) La connexion du port n’est généralement pas un problème, sauf si vous devez vous reconnecter avec la même paire de ports. Le plus souvent, un côté utilise un port éphémère, un seul côté étant ancré à un port bien connu. Toutefois, un très grand nombre de sockets TIME_WAIT peuvent épuiser l’espace de port éphémère si vous vous connectez de manière répétée et fréquente entre les deux mêmes adresses IP. Notez que cela n’affecte que cette paire d’adresses IP particulière et n’affectera pas l’établissement de connexions avec d’autres hôtes.

Answer 2

Résultats obtenus jusqu'à présent:

Même si le serveur a fermé le socket à l'aide d'un appel système, son descripteur de fichier ne sera pas publié s'il passe à l'état TIME_WAIT. Le descripteur de fichier sera publié ultérieurement lorsque l'état TIME_WAIT aura disparu (c'est-à-dire après 2 * MSL secondes). Par conséquent, trop de TIME_WAIT entraînera probablement une erreur "trop ??de fichiers ouverts" dans le processus du serveur.

Je pense que la pile TCP / IP O / S a été mise en œuvre avec une structure de données appropriée (table de hachage, par exemple). Par conséquent, le nombre total de TIME_WAIT ne doit pas affecter les performances de la pile TCP / IP O / S. Seul le processus (serveur) qui possède les sockets à l'état TIME_WAIT en souffrira.

Answer 3

Chaque connexion est identifiée par un tuple (IP du serveur, port du serveur, IP du client, port du client). De manière cruciale, les connexions TIME_WAIT (qu’elles soient côté serveur ou côté client) occupent chacune l’un de ces n-uplets.

Avec les TIME_WAIT côté client, il est facile de comprendre pourquoi vous ne pouvez plus établir de connexions - vous n'avez plus de ports locaux. Cependant, le même problème s’applique côté serveur: une fois qu’il dispose de connexions 64k dans l’état TIME_WAIT pour un seul client , il ne peut plus accepter de connexions provenant de ce client , car il n'a aucun moyen de faire la différence entre l'ancienne connexion et la nouvelle connexion - les deux connexions sont identifiées par le même tuple. Le serveur doit simplement renvoyer les RST aux nouvelles tentatives de connexion de ce client dans ce cas.

Answer 4

Si vous avez beaucoup de connexions depuis plusieurs adresses IP clientes vers les adresses IP du serveur, vous risquez de rencontrer des limitations du tableau de suivi des connexions.

Vérifier:

sysctl net.ipv4.netfilter.ip_conntrack_count
sysctl net.ipv4.netfilter.ip_conntrack_max

Sur tous les tuples src ip / port et dest ip / port, vous ne pouvez avoir que net.ipv4.netfilter.ip_conntrack_max dans la table de suivi. Si cette limite est atteinte, vous verrez un message dans vos journaux "nf_conntrack: table saturée, laissant tomber le paquet". et le serveur n'acceptera pas de nouvelles connexions entrantes jusqu'à ce qu'il y ait de l'espace dans la table de suivi.

Cette limitation peut vous toucher longtemps avant que les ports éphémères ne soient épuisés.

Answer 5

Dans mon scénario, j’ai exécuté un script qui planifie les fichiers de façon répétée. Mon produit effectue des calculs et envoie une réponse au client, c’est-à-dire que le client effectue un appel http répétitif pour obtenir la réponse de chaque fichier. mon serveur passe à l'état time_wait et une exception est renvoyée dans le client, ce qui ouvre une connexion http, par exemple

 Error : [Errno 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

Le résultat est que mon application a été suspendue. Je ne sais pas si les threads sont partis en attente ou ce qui s’est passé, mais j’ai besoin de supprimer tous les processus ou de redémarrer mon application pour la faire fonctionner à nouveau.

J'ai essayé de réduire le temps d'attente à 30 secondes car il s'agit de 240 secondes par défaut, mais cela n'a pas fonctionné.

L'impact global était donc essentiel car il a rendu mon application non réactive

Answer 6

il semble que le serveur ne peut que manquer de ports à attribuer pour les connexions entrantes (pour la durée des TIMED_WAIT existants) - un cas d'attaque par le DOS.