Une énorme quantité de connexions TIME_WAIT indique netstat

28

D'accord, cela me fait flipper - j'en vois environ 1500-2500:

root@wherever:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942

Ce nombre évolue rapidement.

J'ai une configuration iptables assez serrée, donc je n'ai aucune idée de ce qui peut provoquer cela. des idées?

Merci,

Tamas

Edit: Sortie de 'netstat -anp':

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -
linux networking debian tcpip netstat KTamas
la source
1
Avez-vous quelque chose de NFS monté sur la même machine qui l'exporte?
Paul Tomblin
@Paul Tomblin: Non.
KTamas
1
Eh bien, vous devriez regarder les connexions établies pour savoir de quel programme il s'agit. "rcpinfo -p" peut également aider à découvrir ce qui communique avec portmapper.
cstamas
Pour ceux qui trouvent leur chemin ici tout en essayant de trouver un moyen d'ajuster le délai sous Windows, cela peut être fait via un paramètre de registre .
Synetech

Réponses:

22

EDIT: tcp_fin_timeout NE CONTRÔLE PAS la durée TIME_WAIT, il est codé en dur à 60 s

Comme mentionné par d'autres, avoir des connexions TIME_WAITest une partie normale de la connexion TCP. Vous pouvez voir l'intervalle en examinant /proc/sys/net/ipv4/tcp_fin_timeout:

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

Et changez-le en modifiant cette valeur:

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Ou de façon permanente en l'ajoutant à /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

De plus, si vous n'utilisez pas le service RPC ou NFS, vous pouvez simplement le désactiver:

/etc/init.d/nfsd stop

Et éteignez-le complètement

chkconfig nfsd off
Brandon
la source
ouais mon script ipconfig le réduit déjà à 30. Je n'ai pas nfsd dans /etc/init.d/, mais j'ai eu portmap en cours d'exécution, je l'ai arrêté, maintenant TIME_WAITs est descendu à quelques instances (1-5). Merci.
KTamas
18
Euh, tcp_fin_timeout n'a rien à voir avec les sockets dans l'état time_wait. Cela affecte fin_wait_2.
diq
2
+1 pour le commentaire de diq. Ils ne sont pas liés.
mcauth
1
Correct ... vous pouvez voir le compte à rebours des sockets à partir de 60 même si tcp_fin_timeout est modifié à l'aide dess --numeric -o state time-wait dst 10.0.0.100
Greg Bray
16

TIME_WAIT est normal. C'est un état après la fermeture d'un socket, utilisé par le noyau pour garder une trace des paquets qui peuvent avoir été perdus et arrivés en retard à la fête. Un nombre élevé de connexions TIME_WAIT est un symptôme d'avoir beaucoup de connexions de courte durée, pas de quoi s'inquiéter.

David Pashley
la source
Cette réponse est courte et douce. Ça aide beaucoup. La dernière phrase m'a un peu dérouté, mais je pense que le fait est que vous devez comprendre pourquoi tant de connexions sont créées. Si vous écrivez un client qui génère un grand nombre de demandes, vous voulez probablement vous assurer qu'il est configuré pour réutiliser les connexions existantes plutôt que d'en créer de nouvelles pour chaque demande.
nobar
Sueur courte, incomplète. TIME_WAITs dépendent du contexte. Si vous en avez beaucoup, il se peut que quelqu'un attaque votre serveur.
Mindaugas Bernatavičius
5

Ce n'est pas important. Tout ce que cela signifie, c'est que vous ouvrez et fermez un grand nombre de connexions TCP Sun RCP (1 500 à 2 500 d'entre elles toutes les 2 à 4 minutes). L' TIME_WAITétat est ce dans quoi un socket entre lorsqu'il se ferme, pour empêcher les messages d'arriver pour les mauvaises applications comme ils le feraient si le socket était réutilisé trop rapidement, et pour quelques autres fins utiles. Ne t'en fais pas.

(À moins, bien sûr, que vous n'exécutiez rien qui devrait traiter autant d'opérations RCP. Alors, inquiétez-vous.)

le chaos
la source
J'utilise principalement courier-imap et postfix.
KTamas
4

Quelque chose sur votre système fait beaucoup de RPC (appels de procédure à distance) dans votre système (notez que la source et la destination sont localhost). Cela est souvent vu pour lockd pour les montages NFS, mais vous pouvez également le voir pour d'autres appels RPC comme rpc.statd ou rpc.spray.

Vous pouvez essayer d'utiliser "lsof -i" pour voir qui a ces sockets ouverts et voir ce qui le fait. C'est probablement inoffensif.

Paul Tomblin
la source
Rien d'inhabituel là-bas, je vois un TCP *: sunrpc (LISTEN) pour portmap mais devinez que c'est normal.
KTamas
Continuez à le faire à plusieurs reprises jusqu'à ce que vous voyiez qui ouvre la connexion.
Paul Tomblin
netstat -epn --tcp vous montrera les mêmes informations. Sauf si vous utilisez NFS, vous avez probablement très peu de raisons d'utiliser portmap. Vous pouvez le supprimer.
David Pashley
Je n'utilise pas NFS en effet, cependant apt-get remove portmap veut supprimer 'fam' qui a été automatiquement installé probablement par libfam0 qui a été installé par courier-imap. apt-cache dit que «fam» est un paquet recommandé pour libfam0.
KTamas
2

tcp_fin_timeoutne contrôle PAS le TIME_WAITretard. Vous pouvez le voir en utilisant ss ou netstat avec -o pour voir les minuteries de compte à rebours:

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

même avec tcp_fin_timeout défini sur 3, le compte à rebours pour TIME_WAIT commence toujours à 60. Cependant, si net.ipv4.tcp_tw_reuse est défini sur 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), le noyau peut réutiliser les sockets dans TIME_WAIT s'il détermine qu'il n'y aura aucun conflit possible dans TCP numérotation des segments.

Greg Bray
la source
1

J'ai aussi eu le même problème. J'ai mis plusieurs heures à découvrir ce qui se passe. Dans mon cas, la raison en est que netstat essaie de rechercher le nom d'hôte correspondant à l'IP (je suppose qu'il utilise l'API gethostbyaddr). J'utilisais une installation Linux intégrée qui n'avait pas /etc/nsswitch.conf. À ma grande surprise, le problème n'existe que lorsque vous effectuez réellement un netstat -a (découvert cela en exécutant portmap en mode verbeux et débogage).

Maintenant, ce qui s'est passé est le suivant: Par défaut, les fonctions de recherche essaient également de contacter le démon ypbind (Sun Yellow Pages, également connu sous le nom de NIS) pour demander un nom d'hôte. Pour interroger ce service, le portmapper portmap doit être contacté pour obtenir le port de ce service. Maintenant, le portmapper dans mon cas a été contacté via TCP. Le portmapper indique ensuite à la fonction libc qu'aucun service de ce type n'existe et que la connexion TCP est fermée. Comme nous le savons, les connexions TCP fermées entrent dans un état TIME_WAIT pendant un certain temps. Donc netstat intercepte cette connexion lors de l'inscription et cette nouvelle ligne avec une nouvelle IP émet une nouvelle requête qui génère une nouvelle connexion dans l'état TIME_WAIT et ainsi de suite ...

Afin de résoudre ce problème, créez un /etc/nsswitch.conf qui n'utilise pas les services rpc NIS, c'est-à-dire avec le contenu suivant:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files
leecher
la source