sviluppo-web-qa.it

Enorme quantità di connessioni TIME_WAIT dice netstat

Ok, questo mi sta spaventando - ne vedo circa 1500-2500:

[email protected]:# 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...]

[email protected]:# netstat | grep 'TIME_WAIT' |wc -l
1942

Quel numero sta cambiando rapidamente.

Ho una configurazione iptables piuttosto stretta, quindi non ho idea di cosa possa causare questo. qualche idea?

Grazie,

Tamas

Modifica: output di '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   -               
28
KTamas

EDIT: tcp_fin_timeout NOTES controlla la durata di TIME_WAIT, è hardcoded a 60s

Come menzionato da altri, con alcune connessioni in TIME_WAIT è una parte normale della TCP. Puoi vedere l'intervallo esaminando /proc/sys/net/ipv4/tcp_fin_timeout:

[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

E cambiarlo modificando quel valore:

[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

O permanentemente aggiungendolo a /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Inoltre, se non si utilizza il servizio RPC o NFS, è possibile disattivarlo:

/etc/init.d/nfsd stop

E spegnilo completamente

chkconfig nfsd off
22
Brandon

TIME_WAIT è normale. È uno stato dopo che un socket è stato chiuso, utilizzato dal kernel per tenere traccia dei pacchetti che potrebbero essersi persi e presentati in ritardo alla festa. Un numero elevato di connessioni TIME_WAIT è un sintomo di ottenere molte connessioni di breve durata, non nulla di cui preoccuparsi.

16
David Pashley

Non è importante Tutto ciò significa che stai aprendo e chiudendo un sacco di Sun RCP TCP (1500-2500 di esse ogni 2-4 minuti). Lo stato TIME_WAIT È ciò che entra un socket quando viene chiuso, per impedire che i messaggi arrivino per le applicazioni errate come potrebbero fare se il socket fosse riutilizzato troppo rapidamente e per un paio di altri scopi utili.

(A meno che, ovviamente, non si stia eseguendo effettivamente qualcosa che dovrebbe elaborare molte operazioni RCP. Quindi, preoccuparsi.)

5
chaos

Qualcosa sul tuo sistema sta facendo un sacco di RPC (Remote Procedure Calls) all'interno del tuo sistema (nota che sia la sorgente che la destinazione sono localhost). Questo è spesso visto per lockd per montaggi NFS, ma potresti anche vederlo per altre chiamate RPC come rpc.statd o rpc.spray.

Potresti provare a usare "lsof -i" per vedere chi ha quei socket aperti e vedere cosa lo sta facendo. Probabilmente è innocuo.

4
Paul Tomblin

tcp_fin_timeout NON controlla TIME_WAIT ritardo. Puoi vederlo usando ss o netstat con -o per vedere i timer del conto alla rovescia:

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)

anche con tcp_fin_timeout impostato su 3 il conto alla rovescia per TIME_WAIT inizia ancora a 60. Tuttavia, se net.ipv4.tcp_tw_reuse è impostato su 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) quindi il kernel può riutilizzare i socket in TIME_WAIT se determina che non ci saranno possibili conflitti nella numerazione dei segmenti TCP.

2
Greg Bray

Ho avuto anche lo stesso problema. Mi costano diverse ore per scoprire cosa sta succedendo. Nel mio caso, la ragione di ciò è stata che netstat cerca di cercare il nome host corrispondente all'IP (suppongo che stia usando l'API gethostbyaddr). Stavo usando un'installazione Linux incorporata che non aveva /etc/nsswitch.conf. Con mia sorpresa, il problema esiste solo quando stai effettivamente eseguendo un netstat -a (lo hai scoperto eseguendo portmap in modalità dettagliata e debug).

Ora quello che è successo è stato il seguente: Per impostazione predefinita, le funzioni di ricerca provano anche a contattare il demone ypbind (Sun Yellow Pages, noto anche come NIS) per richiedere un nome host. Per richiedere questo servizio, è necessario contattare la portmap portmap per ottenere la porta per questo servizio. Ora il portmapper nel mio caso è stato contattato tramite TCP. Il portmapper quindi dice alla funzione libc che non esiste tale servizio e che TCP viene chiusa. Come sappiamo, chiuso TCP entrano in uno stato TIME_WAIT per alcuni Quindi netstat rileva questa connessione durante la quotazione e questa nuova riga con un nuovo IP emette una nuova richiesta che genera una nuova connessione nello stato TIME_WAIT e così via ...

Per risolvere questo problema, creare un file /etc/nsswitch.conf che non utilizza i servizi NIS rpc, ovvero con i seguenti contenuti:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files
1
leecher