Çok fazla miktarda TIME_WAIT bağlantısı netstat diyor

28

Tamam, bu beni korkutuyor - yaklaşık 1500-2500 tane görüyorum:

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

Bu sayı hızla değişiyor.

Oldukça sıkı bir iptables config var, bu yüzden buna neyin sebep olabileceği hakkında hiçbir fikrim yok. herhangi bir fikir?

Teşekkürler,

Tamas

Düzenleme: 'netstat -anp' çıktısı:

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
kaynak

1

Dışa aktarmakta olan makineye monte edilmiş NFS var mı?

— Paul Tomblin

@ Paul Tomblin: Hayır

— KTamas

1

Hangi program olduğunu bulmak için kurulan bağlantılara bakmalısınız. "rcpinfo -p" ayrıca portmapper ile iletişim kurmanın ne olduğunu bulmanıza yardımcı olabilir.

— cstamas

Windows altında gecikmeyi ayarlamanın bir yolunu bulmaya çalışırken yollarını burada bulmuş olanlar için, bir kayıt defteri ayarı aracılığıyla yapılabilir .

— Synetech

22

EDIT: tcp_fin_timeout TIME_WAIT süresini kontrol ETMEZ , 60'larda kodlanmış

Diğerleri tarafından belirtildiği gibi, bazı bağlantıların yapılması TIME_WAITTCP bağlantısının normal bir parçasıdır. Aralıkları inceleyerek görebilirsiniz /proc/sys/net/ipv4/tcp_fin_timeout:

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

Ve bu değeri değiştirerek değiştirin:

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

Veya /etc/sysctl.conf dosyasına ekleyerek kalıcı olarak

net.ipv4.tcp_fin_timeout=30

Ayrıca, RPC servisini veya NFS'yi kullanmazsanız, sadece kapatabilirsiniz:

/etc/init.d/nfsd stop

Ve tamamen kapat

chkconfig nfsd off

— Brandon
kaynak

evet, ipconfig betiğim zaten onu 30'a düşürdü. /etc/init.d/ içinde nfsd'im yok, fakat portmap çalışıyordu, durdurdum, şimdi TIME_WAIT'ler birkaç örneğe düşürüldü (1-5). Teşekkürler.

— KTamas

18

Uhh, tcp_fin_timeout'un time_wait durumunda soketlerle ilgisi yoktur. Bu fin_wait_2'yi etkiler.

— diq

2

Diq adlı kullanıcının yorumu için +1. Akraba değiller.

— mcauth

1

Doğru ... tcp_fin_timeout kullanılarak değiştirilmiş olsa bile soketlerin 60'tan geriye doğru sayıldığını görebilirsinizss --numeric -o state time-wait dst 10.0.0.100

— Greg Bray

16

TIME_WAIT normal. Bir soket kapandıktan sonra, çekirdeğin kaybolduğu ve partiye geç geldiği paketleri takip etmek için kullandığı bir durumdur. Çok sayıda TIME_WAIT bağlantısı, endişelenecek bir şey değil, çok sayıda kısa süreli bağlantı kurma semptomudur.

— David Pashley
kaynak

Bu cevap kısa ve tatlı. Çok yardımcı olur. Son cümle beni biraz şaşırttı, ama bence neden bu kadar çok bağlantı kurulduğunu anlamanız gerekiyor. Çok fazla istek üreten bir istemci yazıyorsanız, muhtemelen her istek için yenilerini oluşturmak yerine mevcut bağlantıları yeniden kullanmak üzere yapılandırıldığından emin olmak istersiniz.

— nobar

Kısa ter, tamamlanmadı. TIME_WAIT içeriğe bağlıdır. Birçoğunuz varsa, birisi sunucunuza saldırıyor olabilir.

— Mindaugas Bernatavičius

5

Önemli değil. Tek önemli olan, bir çok Sun RCP TCP bağlantısını açıp kapattığınızdır (her 2-4 dakikada bir 1500-2500). Durum TIME_WAIT, bir soketin çok hızlı bir şekilde tekrar kullanılması durumunda olduğu gibi olabilecek yanlış uygulamalara ulaşmasını önlemek ve bir kaç başka yararlı amaç için, bir soketin kapandığında nelere yol açtığını gösterir. Endişelenme.

(Tabii ki, elbette, pek çok RCP işleminin gerçekleştirilmesi gereken hiçbir şeyi çalıştırmıyorsunuz. O zaman endişelenmeyin.)

— kaos
kaynak

Çoğunlukla kurye-imap ve postfix'i çalıştırıyorum.

— KTamas

4

Sisteminizdeki bir şey sisteminizde çok fazla RPC (Uzaktan İşlem Çağrısı Çağrısı) yapıyor (hem kaynağın hem de hedefin yerel ana bilgisayar olduğuna dikkat edin). Bu genellikle NFS bağları için lockd için görülür, ancak bunu rpc.statd veya rpc.spray gibi diğer RPC çağrıları için de görebilirsiniz.

Bu soketleri kimin açtığını ve ne yaptığını görmek için "lsof -i" yi kullanmayı deneyebilirsiniz. Muhtemelen zararsızdır.

— Paul Tomblin
kaynak

Olağandışı bir şey yok, portmap için bir TCP *: sunrpc (LISTEN) görüyorum ama bunun normal olduğunu tahmin ediyorum.

— KTamas

Bağlantıyı kimin açtığını görene kadar tekrar tekrar yapmaya devam edin.

— Paul Tomblin

netstat -epn --tcp size aynı bilgiyi gösterir. NFS kullanmıyorsanız, portmap kullanmak için muhtemelen çok az nedeniniz vardır. Kaldırabilirsin.

— David Pashley

Gerçekten NFS kullanmıyorum, ancak apt-get remove portmap, muhtemelen kurye-imap tarafından yüklenen libfam0 tarafından otomatik olarak yüklenen 'fam'i kaldırmak istiyor. apt-cache 'fam' ifadesinin libfam0 için önerilen bir paket olduğunu söylüyor.

— KTamas

2

tcp_fin_timeoutTIME_WAITgecikmeyi kontrol etmez . Geri sayım zamanlayıcılarını görmek için -s ile ss veya netstat'ı kullanarak bunu görebilirsiniz:

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'e ayarlanmış olsa bile, TIME_WAIT için geri sayım hala 60'ta başlar. Ancak net.ipv4.tcp_tw_reuse 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) olarak ayarlandıysa , çekirdek TCP'de olası bir çakışma olmayacağını belirlerse TIME_WAIT içindeki yuvaları yeniden kullanabilir bölüm numaralandırma.

— Greg Bray
kaynak

1

Ben de aynı sorunu yaşadım. Neler olup bittiğini öğrenmek için bana birkaç saat harcadım. Benim durumumda, bunun nedeni netstat'ın IP'ye karşılık gelen ana bilgisayar adını aramaya çalışmasıydı (sanırım gethostbyaddr API'sini kullanıyor). /Etc/nsswitch.conf dosyası olmayan gömülü bir Linux kurulumu kullanıyordum. Sürprizime göre, sorun yalnızca aslında bir netstat -a yaptığınız zamandır (bunu portmap'i ayrıntılı ve hata ayıklama modunda çalıştırarak bulduk).

Şimdi olan şey şuydu: Varsayılan olarak, arama işlevleri aynı zamanda bir ana bilgisayar adı sorgulamak için ypbind arka plan programı (NIS olarak da bilinen Sun Yellow Pages) ile bağlantı kurmaya çalışır. Bu hizmeti sorgulamak için, bu hizmet için bağlantı noktasını almak üzere portmapper bağlantı noktasıyla bağlantı kurulmalıdır. Şimdi benim durumumdaki portmapper TCP ile temasa geçti. Portmapper daha sonra libc fonksiyonuna böyle bir servisin olmadığını ve TCP bağlantısının kapandığını söyler. Bildiğimiz gibi, kapalı TCP bağlantıları bir süredir TIME_WAIT durumuna girer. Netstat listelediğinde bu bağlantıyı yakalar ve yeni bir IP'ye sahip olan bu yeni satır TIME_WAIT durumunda yeni bir bağlantı oluşturan yeni bir istek yayınlar.

Bu sorunu çözmek için, rpc NIS servislerini kullanmayan, yani aşağıdaki içeriklere sahip olmayan bir /etc/nsswitch.conf oluşturun:

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

— leecher
kaynak