Величезна кількість 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   -

— KTamas
джерело

1

У вас є щось, встановлене NFS на тій же машині, яка експортує його?

— Пол Томблін

@Paul Tomblin: Ні.

— KTamas

1

Ну, ви повинні подивитися на встановлені з'єднання, щоб дізнатися, яка це програма. "rcpinfo -p" також може допомогти з'ясувати, що спілкується з portmapper.

— cstamas

Для тих, хто шукає тут свій шлях, намагаючись знайти спосіб регулювання затримки під Windows, це можна зробити через налаштування реєстру .

— Synetech

22

EDIT: tcp_fin_timeout НЕ контролює тривалість TIME_WAIT , він жорстко кодується в 60s

Як зазначають інші, наявність деяких з'єднань 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

— Брендон
джерело

так, мій сценарій ipconfig вже знижує його до 30. У мене немає nfsd в /etc/init.d/, але у мене була запущена портмапа, зупинила її, тепер TIME_WAIT знижується до кількох примірників (1-5). Спасибі.

— KTamas

18

Так, tcp_fin_timeout не має нічого спільного з розетками в стані time_wait. Це впливає на fin_wait_2.

— diq

2

+1 для коментаря diq. Вони не пов'язані.

— mcauth

1

Правильно ... ви можете бачити зворотний розряд сокетів з 60, навіть якщо tcp_fin_timeout змінено за допомогоюss --numeric -o state time-wait dst 10.0.0.100

— Грег Брей

16

TIME_WAIT - це нормально. Це стан після закриття сокета, яке використовується ядром для відстеження пакетів, які, можливо, загубилися і запізнилися на партію. Велика кількість TIME_WAIT-з'єднань є симптомом отримання безлічі короткочасних з'єднань, що нічого не турбує.

— Девід Пашлі
джерело

Ця відповідь коротка і мила. Це дуже допомагає. Останнє речення мене трохи збентежило, але я думаю, що справа в тому, що вам потрібно зрозуміти, чому так багато зв’язків створюється. Якщо ви пишете клієнт, який генерує багато запитів, ви, ймовірно, хочете переконатися, що він налаштований на повторне використання існуючих з'єднань, а не на створення нових для кожного запиту.

— nobar

Короткий піт, не повний. TIME_WAIT залежать від контексту. Якщо у вас їх багато, можливо, хтось атакує ваш сервер.

— Міндоўг Бернатавічус

5

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

(Якщо, звичайно, ви насправді не виконуєте нічого, що оброблятиме багато операцій RCP. Тоді, переживайте.)

— хаос
джерело

В основному я запускаю кур’єрські зображення та постфікс.

— KTamas

4

Щось у вашій системі робить багато RPC (віддалених викликів процедур) у вашій системі (зауважте, що джерело та місце призначення - localhost). Це часто спостерігається для блокування для монтажу NFS, але ви також можете бачити його для інших викликів RPC, таких як rpc.statd або rpc.spray.

Ви можете спробувати скористатися "lsof -i", щоб побачити, хто має ці розетки, і побачити, що це робить. Це, мабуть, нешкідливо.

— Пол Томблін
джерело

Нічого незвичайного там я не бачу TCP *: sunrpc (LISTEN) для портмапи, але гадаю, що це нормально.

— KTamas

Продовжуйте робити це повторно, поки не побачите, хто відкриває з'єднання.

— Пол Томблін

netstat -epn --tcp покаже вам ту саму інформацію. Якщо ви не використовуєте NFS, у вас, ймовірно, є дуже мало причин для використання портмапи. Ви можете її видалити.

— Девід Пашлі

Я дійсно не використовую 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 (це з’ясувалося, запустивши портмапу в режимі докладної роботи та налагодження).

Тепер це сталося наступне: За замовчуванням функції пошуку також намагаються зв’язатися з демоном ypbind (Sun Yellow Pages, також відомим як NIS) для запиту імені хоста. Щоб здійснити запит на цю послугу, для отримання порту для цієї послуги потрібно зв’язатися з портмапою портпорта. Тепер до портмейпера в моєму випадку зв’язався через TCP. Портмейпер потім повідомляє функцію libc, що такої служби не існує, і з'єднання TCP закривається. Як ми знаємо, закриті TCP-з'єднання протягом певного часу переходять у стан TIME_WAIT. Таким чином, netstat вловлює це з'єднання під час перерахування, і цей новий рядок з новою IP-адресою видає новий запит, який генерує нове з'єднання у стані TIME_WAIT і так далі ...

Щоб вирішити цю проблему, створіть /etc/nsswitch.conf, який не використовує rpc NIS-послуги, тобто із наступним вмістом:

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

— п'явка
джерело