Ogromna liczba połączeń TIME_WAIT mówi netstat

Ok, to mnie przeraża - widzę około 1500-2500 z nich:

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

Ta liczba szybko się zmienia.

Mam dość ciasną konfigurację iptables, więc nie mam pojęcia, co może to powodować. jakieś pomysły?

Dzięki,

Tamas

Edycja: Wyjście „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   -               

EDYCJA: tcp_fin_timeout NIE kontroluje czasu TIME_WAIT , jest zakodowany na 60s

Jak wspomniano przez innych, posiadanie niektórych połączeń TIME_WAITjest normalną częścią połączenia TCP. Interwał można zobaczyć, badając /proc/sys/net/ipv4/tcp_fin_timeout:

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

I zmień to, modyfikując tę ​​wartość:

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

Lub na stałe, dodając go do /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Ponadto, jeśli nie korzystasz z usługi RPC lub NFS, możesz ją po prostu wyłączyć:

/etc/init.d/nfsd stop

I całkowicie to wyłącz

chkconfig nfsd off

TIME_WAIT jest normalny. Jest to stan po zamknięciu gniazda, używanego przez jądro do śledzenia pakietów, które mogły zostać zgubione i pojawić się późno na imprezie. Duża liczba połączeń TIME_WAIT jest symptomem uzyskiwania wielu krótkotrwałych połączeń, nie ma się czym martwić.

To nie jest ważne. Wszystko to oznacza, że ​​otwierasz i zamykasz wiele połączeń TCP Sun RCP TCP (1500-2500 z nich co 2-4 minuty). TIME_WAITStan jest co gniazdo przechodzi, gdy zamyka się, aby zapobiec wiadomości z przybyciem do niewłaściwych wniosków jak oni mogą, jeśli gniazdo zostały ponownie wykorzystane zbyt szybko, i na kilka innych przydatnych celów. Nie martw się o to.

(Chyba że oczywiście nie uruchamiasz niczego, co powinno przetwarzać tak wiele operacji RCP. W takim razie martw się.)

Coś w twoim systemie wykonuje wiele RPC (Remote Procedural Call wywołań) w twoim systemie (zauważ, że zarówno źródłowy, jak i docelowy to localhost). Jest to często widoczne w przypadku lockd dla montowań NFS, ale możesz to również zobaczyć w przypadku innych wywołań RPC, takich jak rpc.statd lub rpc.spray.

Możesz spróbować użyć „lsof -i”, aby zobaczyć, kto ma otwarte gniazda i zobaczyć, co to robi. To prawdopodobnie nieszkodliwe.

tcp_fin_timeoutNIE kontroluje TIME_WAITopóźnienia. Możesz to zobaczyć za pomocą ss lub netstat z opcją -o, aby zobaczyć liczniki odliczania:

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)

nawet przy tcp_fin_timeout ustawionym na 3 odliczanie dla TIME_WAIT nadal zaczyna się od 60. Jednak jeśli masz net.ipv4.tcp_tw_reuse ustawioną na 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), jądro może ponownie użyć gniazd w TIME_WAIT, jeśli stwierdzi, że nie będzie żadnych konfliktów w TCP numeracja segmentów.

Też miałem ten sam problem. Kosztowało mnie kilka godzin, aby dowiedzieć się, co się dzieje. W moim przypadku powodem tego było to, że netstat próbuje wyszukać nazwę hosta odpowiadającą adresowi IP (zakładam, że używa interfejsu API gethostbyaddr). Korzystałem z wbudowanej instalacji Linuksa, która nie miała /etc/nsswitch.conf. Ku mojemu zdziwieniu problem występuje tylko wtedy, gdy wykonujesz netstat -a (znalazłeś to, uruchamiając portmap w trybie szczegółowym i debugowania).

Teraz stało się to tak: Domyślnie funkcje wyszukiwania próbują również skontaktować się z demonem ypbind (Sun Yellow Pages, znany również jako NIS) w celu zapytania o nazwę hosta. Aby wysłać zapytanie do tej usługi, należy skontaktować się z portmapper portmapper, aby uzyskać port dla tej usługi. Teraz portmapper w moim przypadku skontaktował się za pośrednictwem TCP. Portmapper następnie informuje funkcję libc, że taka usługa nie istnieje i połączenie TCP zostaje zamknięte. Jak wiemy, zamknięte połączenia TCP przechodzą przez pewien czas w stan TIME_WAIT. Więc netstat łapie to połączenie podczas wyświetlania listy, a ta nowa linia z nowym adresem IP wysyła nowe żądanie, które generuje nowe połączenie w stanie TIME_WAIT i tak dalej ...

Aby rozwiązać ten problem, utwórz plik /etc/nsswitch.conf, który nie korzysta z usług NIS rpc, tj. O następującej treści:

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