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

Question

Nous allons supposer qu'il y a un client qui fait beaucoup de court-séjour connexions à un serveur.

Si le client ferme la connexion, il y aura de nombreux ports en TIME_WAIT etat sur le côté client. Étant donné que 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 vais voir de nombreux TIME_WAITs sur le côté serveur. Cependant, cela veut-il faire du mal? Le client (ou d'autres clients) peuvent continuer à faire des tentatives de connexion depuis il n'est jamais à court de ports locaux, et le nombre d' TIME_WAIT etat va augmenter sur le côté serveur. Qu'advient-il finalement? Fait quelque chose de mauvais se produire? (ralentissement, accident, perte de connexion, etc.)

Veuillez noter que ma question n'est pas "Quel est le but de l' TIME_WAIT? ", mais "Ce qui se passe si il ya tellement de nombreux TIME_WAIT états sur le serveur?" Je sais déjà ce qui se passe lors de la fermeture d'une connexion TCP/IP et pourquoi TIME_WAIT de l'état est nécessaire. Je ne suis pas en train de dépanner, mais je veux juste savoir qu'est-ce que le problème potentiel avec elle.

Pour faire simple, disons - netstat -nat | grep :8080 | grep TIME_WAIT | wc -l tirages 100000. Qu'arriverait-il? L'O/S du réseau de la pile ralentir? "Trop de fichiers ouverts" erreur? Ou, tout simplement rien à s'inquiéter?

Answer 1

Chaque connexion est identifié par un n-uplet (IP du serveur, le port du serveur, l'IP du client, le client de port). Surtout, à l' TIME_WAIT des connexions (si ils sont sur le côté serveur ou côté client) occupent chacun une de ces n-uplets.

Avec l' TIME_WAITs sur le côté client, il est facile de voir pourquoi vous ne pouvez pas faire plus de connexions - vous n'avez plus de ports locaux. Cependant, le même problème s'applique sur le côté serveur - une fois qu'il a 64 ko connexions en TIME_WAIT état pour un seul client, il ne peut pas accepter plus de connexions à partir de ce client, car il n'a aucun moyen de faire la différence entre la connexion ancienne et la nouvelle connexion - les deux connexions sont identifiées par le même tuple. Le serveur doit juste renvoyer RSTs à de nouvelles tentatives de connexion à partir de ce client dans ce cas.

Answer 2

Résultats à ce jour:

Même si le serveur a fermé la socket en utilisant l'appel système, son descripteur de fichier ne sera pas publiée si elle entre dans l'état TIME_WAIT. Le descripteur de fichier sera publié plus tard, lorsque l'état TIME_WAIT est parti (c'est à dire après 2*MSL secondes). Par conséquent, trop de TIME_WAITs éventuellement conduire à un "trop de fichiers ouverts" erreur dans le processus de serveur.

Je crois O/S pile TCP/IP a été mis en œuvre avec une bonne structure de données (par exemple, la table de hachage), de sorte que le nombre total de TIME_WAITs ne devrait pas affecter les performances de l'O/S pile TCP/IP. Seul le processus (serveur), qui détient les sockets dans l'état TIME_WAIT va en souffrir.

Answer 3

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