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

28

Ладно, это меня пугает - я вижу около 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   -
linux networking debian tcpip netstat KTamas
источник
1
У вас есть что-то NFS, смонтированное на той же машине, которая экспортирует это?
Пол Томблин
@ Пол Томблин: Нет.
KTamas
1
Что ж, вы должны посмотреть на Установленные соединения, чтобы узнать, какая это программа. «rcpinfo -p» также может помочь выяснить, что связывается с portmapper.
Cstamas
Для тех, кто находит свой путь здесь, пытаясь найти способ отрегулировать задержку под Windows, это можно сделать с помощью параметра реестра .
Synetech

Ответы:

22

РЕДАКТИРОВАТЬ: 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
Brandon
источник
да, мой сценарий ipconfig уже понижает его до 30. У меня нет nfsd в /etc/init.d/, но у меня действительно был запущен portmap, он остановлен, теперь TIME_WAITs уменьшены до нескольких экземпляров (1-5). Спасибо.
KTamas
18
Ухх, tcp_fin_timeout не имеет ничего общего с сокетами в состоянии time_wait. Это затрагивает fin_wait_2.
Дик
2
+1 за комментарий дика. Они не связаны.
Мак
1
Правильно ... вы можете видеть, как сокеты отсчитывают от 60, даже если tcp_fin_timeout изменяется с помощьюss --numeric -o state time-wait dst 10.0.0.100
Грег Брей
16

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

Дэвид Пашли
источник
Этот ответ короткий и сладкий. Это очень помогает. Последнее предложение меня немного смутило, но я думаю, дело в том, что вам нужно понять, почему создается так много связей. Если вы пишете клиент, который генерирует много запросов, вы, вероятно, захотите убедиться, что он настроен на повторное использование существующих соединений, а не на создание новых для каждого запроса.
Нобар
Короткий пот, не полный. TIME_WAIT зависят от контекста. Если у вас их много, возможно, кто-то атакует ваш сервер.
Миндаугас Бернатавичюс
5

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

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

хаос
источник
Я в основном использую курьерские IMAP и Postfix.
KTamas
4

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

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

Пол Томблин
источник
Там нет ничего необычного, я вижу TCP *: sunrpc (LISTEN) для portmap, но думаю, что это нормально.
KTamas
Продолжайте делать это несколько раз, пока не увидите, кто открывает соединение.
Пол Томблин
netstat -epn --tcp покажет вам ту же информацию. Если вы не используете NFS, у вас, вероятно, мало причин для использования portmap. Вы можете удалить это.
Дэвид Пашли
Я действительно не использую NFS, однако apt-get remove portmap хочет удалить 'fam', которая была автоматически установлена, вероятно, libfam0, которая была установлена ​​courier-imap. apt-cache говорит, что fam - это рекомендуемый пакет для libfam0.
KTamas
2

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 не будет никаких возможных конфликтов. нумерация сегментов.

Грег Брей
источник
1

У меня тоже была такая же проблема. Мне потребовалось несколько часов, чтобы выяснить, что происходит. В моем случае причиной этого было то, что 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
Leecher
источник