Огромное количество соединений TIME_WAIT говорит netstat

Ладно, это меня пугает - я вижу около 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

Это число быстро меняется.

У меня довольно плотный конфиг iptables, поэтому я понятия не имею, что может вызвать это. Любые идеи?

Благодарность,

Тамас

Редактировать: Вывод '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   -               

РЕДАКТИРОВАТЬ: tcp_fin_timeout не контролирует продолжительность TIME_WAIT, он жестко закодирован в 60 с

Как уже упоминалось, наличие некоторых подключений TIME_WAITявляется нормальной частью TCP-соединения. Вы можете увидеть интервал, изучив /proc/sys/net/ipv4/tcp_fin_timeout:

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

И измените его, изменив это значение:

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

Или навсегда, добавив его в /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Кроме того, если вы не используете службу RPC или NFS, вы можете просто отключить ее:

/etc/init.d/nfsd stop

И выключи его полностью

chkconfig nfsd off

TIME_WAIT это нормально. Это состояние после закрытия сокета, которое используется ядром для отслеживания пакетов, которые могут быть потеряны и опозданы на вечеринку. Большое количество соединений TIME_WAIT - это признак получения большого количества недолговечных соединений, не о чем беспокоиться.

Это не важно Все, что означает, - это то, что вы открываете и закрываете большое количество TCP-соединений Sun RCP (1500-2500 из них каждые 2-4 минуты). TIME_WAITСостояние , что сокет переходит в , когда он закрывается, чтобы предотвратить сообщения от прибывающих для неправильных применений , как они могли бы , если сокет были повторно слишком быстро, и в течение нескольких других полезных целей. Не беспокойся об этом.

(Если, конечно, вы на самом деле не выполняете ничего, что должно обрабатывать столько операций RCP. Тогда беспокойтесь.)

Что-то в вашей системе выполняет много RPC (удаленных вызовов процедур) в вашей системе (обратите внимание, что источником и получателем является localhost). Это часто наблюдается для lockd для монтирования NFS, но вы также можете увидеть это и для других вызовов RPC, таких как rpc.statd или rpc.spray.

Вы можете попробовать использовать "lsof -i", чтобы увидеть, у кого открыты эти сокеты, и посмотреть, что это делает. Это, вероятно, безвредно.

tcp_fin_timeoutНЕ контролирует TIME_WAITзадержку. Это можно увидеть с помощью ss или netstat с -o, чтобы увидеть таймеры обратного отсчета:

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)

даже если для tcp_fin_timeout установлено значение 3, обратный отсчет для TIME_WAIT по-прежнему начинается с 60. Однако если для net.ipv4.tcp_tw_reuse установлено значение 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), то ядро ​​может повторно использовать сокеты в TIME_WAIT, если определит, что в TCP не будет никаких возможных конфликтов. нумерация сегментов.

У меня тоже была такая же проблема. Мне потребовалось несколько часов, чтобы выяснить, что происходит. В моем случае причиной этого было то, что netstat пытается найти имя хоста, соответствующее IP (я предполагаю, что он использует API gethostbyaddr). Я использовал встроенную установку Linux, которая не имела /etc/nsswitch.conf. К моему удивлению, проблема существует, только когда вы фактически выполняете команду netstat -a (выясните это, запустив portmap в подробном режиме и режиме отладки).

Теперь произошло следующее: По умолчанию функции поиска также пытаются связаться с демоном ypbind (Sun Yellow Pages, также известным как NIS) для запроса имени хоста. Чтобы запросить этот сервис, необходимо связаться с portmapper portmap, чтобы получить порт для этого сервиса. Теперь в моем случае с portmapper связались через TCP. Затем portmapper сообщает функции libc, что такой службы не существует, и соединение TCP закрывается. Как мы знаем, закрытые TCP-соединения в течение некоторого времени переходят в состояние TIME_WAIT. Поэтому netstat перехватывает это соединение при перечислении, и эта новая строка с новым IP-адресом выдает новый запрос, который генерирует новое соединение в состоянии TIME_WAIT и так далее ...

Чтобы решить эту проблему, создайте /etc/nsswitch.conf, который не использует службы NIS rpc, то есть со следующим содержимым:

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