Ogromna liczba połączeń TIME

28

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   -

— KTamas
źródło

1

Czy masz coś podłączonego do systemu plików NFS na tym samym komputerze, który go eksportuje?

— Paul Tomblin,

@Paul Tomblin: Nie.

— KTamas

1

Cóż, powinieneś spojrzeć na ustanowione połączenia, aby dowiedzieć się, który to program. „rcpinfo -p” może również pomóc dowiedzieć się, co komunikuje się z portmapper.

— cstamas

Dla tych, którzy znajdą tutaj swoją drogę, próbując znaleźć sposób na dostosowanie opóźnienia w systemie Windows, można to zrobić za pomocą ustawienia rejestru .

— Synetech

22

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

— Brandon
źródło

tak, mój skrypt ipconfig już obniża go do 30. Nie mam nfsd w /etc/init.d/, ale miałem uruchomioną portmap, zatrzymałem go, teraz TIME_WAIT są upuszczane do kilku instancji (1-5). Dzięki.

— KTamas

18

Uhh, tcp_fin_timeout nie ma nic wspólnego z gniazdami w stanie time_wait. Wpływa to na fin_wait_2.

— diq

2

+1 za komentarz diq. Nie są spokrewnieni.

— mcauth,

1

Poprawnie ... widać, że gniazda odliczają od 60, nawet jeśli zmieniono tcp_fin_timeout przy użyciuss --numeric -o state time-wait dst 10.0.0.100

— Greg Bray

16

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ć.

— David Pashley
źródło

Ta odpowiedź jest krótka i słodka. To bardzo pomaga. Ostatnie zdanie trochę mnie pomieszało, ale myślę, że chodzi o to, że musisz zrozumieć, dlaczego powstaje tak wiele połączeń. Jeśli piszesz klienta, który generuje wiele żądań, prawdopodobnie chcesz się upewnić, że jest skonfigurowany do ponownego wykorzystywania istniejących połączeń zamiast tworzenia nowych dla każdego żądania.

— nobar

Krótki pot, niekompletny. Czasy TIME_WAIT zależą od kontekstu. Jeśli masz ich dużo, być może ktoś atakuje Twój serwer.

— Mindaugas Bernatavičius

5

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ę.)

— chaos
źródło

Głównie prowadzę kurier-imap i postfiks.

— KTamas

4

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.

— Paul Tomblin
źródło

Nie ma w tym nic niezwykłego, widzę TCP *: sunrpc (LISTEN) dla portmap, ale domyślam się, że to normalne.

— KTamas,

Rób to wielokrotnie, aż zobaczysz, kto otwiera połączenie.

— Paul Tomblin,

netstat -epn --tcp wyświetli te same informacje. O ile nie korzystasz z NFS, prawdopodobnie nie masz zbyt wielu powodów, by używać portmap. Możesz to usunąć.

— David Pashley,

Rzeczywiście nie używam NFS, jednak apt-get remove portmap chce usunąć „fam”, który został automatycznie zainstalowany prawdopodobnie przez libfam0, który został zainstalowany przez courier-imap. apt-cache mówi, że „fam” jest zalecanym pakietem dla libfam0.

— KTamas

2

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.

— Greg Bray
źródło

1

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

— pijawka
źródło

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