Laut netstat ist die Anzahl der TIME_WAIT-Verbindungen enorm

28

Okay, das macht mir Angst - ich sehe ungefähr 1500-2500 davon:

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

Diese Zahl ändert sich schnell.

Ich habe eine ziemlich enge iptables-Konfiguration, so dass ich keine Ahnung habe, was dies verursachen kann. irgendwelche Ideen?

Vielen Dank,

Tamas

Edit: Ausgabe von '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
quelle
1
Ist auf demselben Computer, auf dem der Export ausgeführt wird, NFS aktiviert?
Paul Tomblin
@ Paul Tomblin: Nein.
KTamas
1
Nun, Sie sollten sich die eingerichteten Verbindungen ansehen, um herauszufinden, um welches Programm es sich handelt. "rcpinfo -p" kann auch helfen, herauszufinden, was mit portmapper kommuniziert.
cstamas
Für diejenigen, die sich hier zurechtfinden, während sie versuchen, die Verzögerung unter Windows anzupassen, kann dies über eine Registrierungseinstellung erfolgen .
Synetech

Antworten:

22

BEARBEITEN : tcp_fin_timeout steuert NICHT die TIME_WAIT-Dauer, sondern ist bei 60s fest codiert

Wie von anderen erwähnt, sind einige Verbindungen TIME_WAITein normaler Teil der TCP-Verbindung. Sie können das Intervall sehen, indem Sie Folgendes untersuchen /proc/sys/net/ipv4/tcp_fin_timeout:

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

Und ändern Sie es, indem Sie diesen Wert ändern:

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

Oder dauerhaft, indem Sie es zu /etc/sysctl.conf hinzufügen

net.ipv4.tcp_fin_timeout=30

Wenn Sie den RPC-Dienst oder NFS nicht verwenden, können Sie ihn auch einfach deaktivieren:

/etc/init.d/nfsd stop

Und schalte es komplett aus

chkconfig nfsd off
Brandon
quelle
Ja, mein ipconfig-Skript senkt es bereits auf 30. Ich habe nfsd in /etc/init.d/ nicht ausgeführt, aber portmap, habe es gestoppt, jetzt werden TIME_WAITs auf einige Instanzen reduziert (1-5). Vielen Dank.
KTamas
18
Ähh, tcp_fin_timeout hat nichts mit Sockets im time_wait-Status zu tun. Das betrifft fin_wait_2.
Diq
2
+1 für den Kommentar von diq. Sie sind nicht verwandt.
2.
1
Richtig ... Sie können sehen, dass die Sockets von 60 herunter zählen, auch wenn tcp_fin_timeout mitss --numeric -o state time-wait dst 10.0.0.100
Greg Bray
16

TIME_WAIT ist normal. Dies ist ein Zustand nach dem Schließen eines Sockets, der vom Kernel verwendet wird, um Pakete zu verfolgen, die möglicherweise verloren gegangen sind und zu spät zur Party gekommen sind. Eine hohe Anzahl von TIME_WAIT-Verbindungen ist ein Symptom für viele kurzlebige Verbindungen und kein Grund zur Sorge.

David Pashley
quelle
Diese Antwort ist kurz und bündig. Es hilft sehr. Der letzte Satz hat mich ein wenig verwirrt, aber ich denke, der Punkt ist, dass Sie verstehen müssen, warum so viele Verbindungen hergestellt werden. Wenn Sie einen Client schreiben, der viele Anforderungen generiert, möchten Sie wahrscheinlich sicherstellen, dass er so konfiguriert ist, dass vorhandene Verbindungen wiederverwendet werden, anstatt für jede Anforderung neue Verbindungen zu erstellen.
26.
Kurzer Schweiß, nicht vollständig. TIME_WAITs hängen vom Kontext ab. Wenn Sie viele davon haben, greift möglicherweise jemand Ihren Server an.
Mindaugas Bernatavičius
5

Es ist nicht wichtig. Dies bedeutet lediglich, dass Sie viele Sun RCP TCP-Verbindungen öffnen und schließen (1500-2500 davon alle 2-4 Minuten). Der TIME_WAITStatus ist der Zustand, in den ein Socket beim Schließen wechselt, um zu verhindern, dass Nachrichten für die falschen Anwendungen eingehen, wie dies bei einer zu schnellen Wiederverwendung des Sockets der Fall wäre, und für einige andere nützliche Zwecke. Mach dir keine Sorgen.

(Es sei denn, Sie führen tatsächlich nichts aus, das so viele RCP-Vorgänge verarbeiten sollte. Machen Sie sich dann Sorgen.)

Chaos
quelle
Ich verwende meistens Courier-Imap und Postfix.
KTamas
4

Etwas auf Ihrem System führt eine Menge RPC (Remote Procedure Calls) in Ihrem System aus (beachten Sie, dass sowohl Quelle als auch Ziel localhost sind). Dies wird häufig für lockd für NFS-Bereitstellungen gesehen, aber Sie können es auch für andere RPC-Aufrufe wie rpc.statd oder rpc.spray sehen.

Sie können versuchen, mit "lsof -i" zu ermitteln, wer diese Sockets geöffnet hat und was dies bewirkt. Es ist wahrscheinlich harmlos.

Paul Tomblin
quelle
Nichts ungewöhnliches, ich sehe ein TCP *: sunrpc (LISTEN) für portmap, aber denke, das ist normal.
KTamas
Wiederholen Sie dies so oft, bis Sie sehen, wer die Verbindung öffnet.
Paul Tomblin
netstat -epn --tcp zeigt Ihnen die gleichen Informationen an. Wenn Sie nicht NFS verwenden, haben Sie wahrscheinlich nur sehr wenige Gründe, portmap zu verwenden. Sie könnten es entfernen.
David Pashley
Ich verwende zwar kein NFS, aber apt-get remove portmap möchte 'fam' entfernen, das wahrscheinlich von libfam0, das von courier-imap installiert wurde, automatisch installiert wurde. apt-cache sagt, 'fam' sei ein empfohlenes Paket für libfam0.
KTamas
2

tcp_fin_timeoutKontrolliert NICHT die TIME_WAITVerzögerung. Sie können dies sehen, indem Sie ss oder netstat mit -o verwenden, um die Countdown-Timer anzuzeigen:

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)

Selbst wenn tcp_fin_timeout auf 3 gesetzt ist, beginnt der Countdown für TIME_WAIT immer noch bei 60. Wenn Sie jedoch net.ipv4.tcp_tw_reuse auf 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) setzen, kann der Kernel Sockets in TIME_WAIT wiederverwenden, wenn er feststellt, dass es in TCP keine möglichen Konflikte gibt Segmentnummerierung.

Greg Bray
quelle
1

Ich hatte auch das gleiche Problem. Ich habe mehrere Stunden gebraucht, um herauszufinden, was los ist. In meinem Fall war der Grund dafür, dass netstat versucht, den der IP entsprechenden Hostnamen nachzuschlagen (ich gehe davon aus, dass er die gethostbyaddr-API verwendet). Ich verwendete eine eingebettete Linux-Installation ohne /etc/nsswitch.conf. Zu meiner Überraschung besteht das Problem nur, wenn Sie tatsächlich eine netstat -a ausführen (dies wurde durch Ausführen von portmap im ausführlichen und im Debug-Modus festgestellt).

Nun ist Folgendes passiert: Standardmäßig versuchen die Suchfunktionen auch, den ypbind-Daemon (Sun Yellow Pages, auch bekannt als NIS) zu kontaktieren, um nach einem Hostnamen zu fragen. Um diesen Dienst abzufragen, muss der Portmapper portmap kontaktiert werden, um den Port für diesen Dienst abzurufen. Jetzt wurde der Portmapper in meinem Fall über TCP kontaktiert. Der Portmapper teilt der libc-Funktion dann mit, dass kein solcher Dienst vorhanden ist und die TCP-Verbindung geschlossen wird. Wie wir wissen, wechseln geschlossene TCP-Verbindungen für einige Zeit in den Status TIME_WAIT. Netstat fängt also diese Verbindung beim Auflisten ab und diese neue Zeile mit einer neuen IP gibt eine neue Anfrage aus, die eine neue Verbindung im TIME_WAIT-Status erzeugt und so weiter ...

Um dieses Problem zu lösen, erstellen Sie eine /etc/nsswitch.conf, die die rpc NIS-Dienste nicht verwendet, dh mit den folgenden Inhalten:

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