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

Question

Supposons qu'un client réalise de nombreuses connexions de courte durée avec un serveur.

Si le client ferme la connexion, il y aura plusieurs ports dans l'état TIME_WAIT côté client. Comme le client est à court 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 côté serveur. Cependant, cela fait-il du mal? Le client (ou d'autres clients) peut continuer à effectuer des tentatives de connexion car il ne court jamais sur les ports locaux et le nombre d'états TIME_WAIT augmentera du côté serveur. Qu'est-ce qui se passe finalement? Est-ce que quelque chose de mal arrive? (ralentissement, plantage, perte de connexion, 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 quand une connexion est fermée en TCP/IP et pourquoi l'état TIME_WAIT est requis. Je n'essaie pas de résoudre le problème mais je veux juste savoir quel est le problème potentiel avec cela. Pour mettre simplement, disons netstat -nat | grep :8080 | grep TIME_WAIT | wc -l imprime 100000. Ce qui se passerait? La pile réseau O/S ralentit-elle? "Trop de fichiers ouverts" erreur? Ou, juste pas de quoi s'inquiéter?

Answer 1

Chaque socket dans TIME_WAIT consomme de la mémoire dans le noyau, généralement un peu moins qu'une socket ESTABLISHED mais toujours significative. 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 ont été correctement fermés), vous ne devriez donc pas avoir à vous soucier d'une erreur "trop ​​de fichiers ouverts".

La socket attache également cette adresse IP et ce port src/dst afin qu'elle ne puisse pas être réutilisée pendant la durée de l'intervalle TIME_WAIT. (Ceci est l'objectif prévu de l'état TIME_WAIT.) Lier le 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 camp utilisera un port éphémère, avec seulement un côté ancré à un port bien connu. Cependant, un très grand nombre de sockets TIME_WAIT peut é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'affecte pas l'établissement de connexions avec d'autres hôtes.

Answer 2

Il semble que le serveur puisse simplement manquer de ports à affecter aux connexions entrantes (pour la durée des TIMED_WAIT existants) - un cas d'attaque DOS.

Answer 3

résultats jusqu'à présent:

Même si le serveur a fermé la prise en utilisant l'appel système, le descripteur de fichier ne sera pas libéré si elle entre dans l'état TIME_WAIT. Le descripteur de fichier sera publié plus tard lorsque l'état TIME_WAIT aura disparu (c'est-à-dire après 2 * secondes MSL). Par conséquent, un trop grand nombre de TIME_WAITs peut entraîner une erreur "trop ​​de fichiers ouverts" dans le processus serveur. Je crois que la pile TCP/IP O/S a été implémentée avec une structure de données appropriée (table de hachage par exemple), donc le nombre total de TIME_WAITs ne devrait pas affecter les performances de la pile TCP/IP O/S. Seul le processus (serveur) qui possède les sockets dans l'état TIME_WAIT en souffrira.

Answer 4

Chaque connexion est identifiée par un n-uplet (adresse IP du serveur, port du serveur, adresse IP du client, port du client). Fondamentalement, les connexions TIME_WAIT (qu'elles soient côté serveur ou côté client) occupent chacune un de ces tuples. Avec les TIME_WAIT côté client, il est facile de voir pourquoi vous ne pouvez plus faire de connexions - vous n'avez plus de ports locaux. Cependant, le même problème s'applique du côté serveur - une fois qu'il a 64k connexions dans TIME_WAIT état pour un seul client, il ne peut plus accepter les connexions 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 RST s aux nouvelles tentatives de connexion de ce client dans ce cas.

Answer 5

Si vous avez beaucoup de connexions de nombreuses adresses IP clientes vers les adresses IP du serveur, vous risquez de rencontrer des limitations de la table de suivi des connexions.

Vérifier:

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

Dans l'ensemble src IP/port et dest ip/tuples port vous ne pouvez avoir net.ipv4.netfilter.ip_conntrack_max dans le tableau de suivi. Si cette limite est atteinte, vous verrez un message dans vos journaux "nf_conntrack: table complète, abandon de paquet". et le serveur n'acceptera pas de nouvelles connexions entrantes tant qu'il n'y aura plus d'espace dans la table de suivi.

Cette limitation peut vous toucher bien avant l'expiration des ports éphémères.