pengembangan-web-mp.com

Koneksi TIME_WAIT dalam jumlah besar mengatakan netstat

Oke, ini membuat saya takut - Saya melihat sekitar 1500-2500 di antaranya:

[email protected]:# 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...]

[email protected]:# netstat | grep 'TIME_WAIT' |wc -l
1942

Angka itu berubah dengan cepat.

Saya memiliki konfigurasi iptables yang cukup ketat sehingga saya tidak tahu apa yang menyebabkannya. ada ide?

Terima kasih,

Tamas

Sunting: Output dari '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   -               
28
KTamas

EDIT: tcp_fin_timeout TIDAK TIDAK mengontrol durasi TIME_WAIT, hardcoded pada 60-an

Seperti yang disebutkan oleh orang lain, memiliki beberapa koneksi di TIME_WAIT adalah bagian normal dari koneksi TCP. Anda dapat melihat interval dengan memeriksa /proc/sys/net/ipv4/tcp_fin_timeout:

[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

Dan mengubahnya dengan mengubah nilai itu:

[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Atau secara permanen dengan menambahkannya ke /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Juga, jika Anda tidak menggunakan layanan RPC atau NFS, Anda bisa mematikannya:

/etc/init.d/nfsd stop

Dan matikan sepenuhnya

chkconfig nfsd off
22
Brandon

TIME_WAIT normal. Ini adalah keadaan setelah soket ditutup, digunakan oleh kernel untuk melacak paket-paket yang mungkin hilang dan terlambat datang ke pesta. Banyaknya koneksi TIME_WAIT adalah gejala mendapatkan banyak koneksi yang berumur pendek, tidak perlu khawatir.

16
David Pashley

Itu tidak penting. Semua yang menandakan adalah bahwa Anda membuka dan menutup banyak Sun RCP TCP (1500-2500 di antaranya setiap 2-4 menit). Status TIME_WAIT Adalah apa yang soket masuk ketika ditutup, untuk mencegah pesan datang untuk aplikasi yang salah seperti mereka mungkin jika soket digunakan kembali terlalu cepat, dan untuk beberapa tujuan bermanfaat lainnya. Jangan khawatir tentang hal itu.

(Kecuali, tentu saja, Anda tidak benar-benar menjalankan apa pun yang seharusnya memproses banyak operasi RCP. Lalu, khawatir.)

5
chaos

Sesuatu pada sistem Anda melakukan banyak RPC (Panggilan Prosedur Jarak Jauh) dalam sistem Anda (perhatikan bahwa sumber dan tujuan adalah localhost). Itu sering terlihat untuk lockd untuk NFS mounts, tetapi Anda mungkin juga melihatnya untuk panggilan RPC lainnya seperti rpc.statd atau rpc.spray.

Anda dapat mencoba menggunakan "lsof -i" untuk melihat siapa yang membuka soket itu dan melihat apa yang melakukannya. Mungkin tidak berbahaya.

4
Paul Tomblin

tcp_fin_timeout TIDAK mengontrol TIME_WAIT keterlambatan. Anda dapat melihat ini dengan menggunakan ss atau netstat dengan -o untuk melihat penghitung waktu mundur:

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)

bahkan dengan tcp_fin_timeout yang diatur ke 3, hitungan mundur untuk TIME_WAIT masih dimulai pada 60. Namun jika Anda memiliki net.ipv4.tcp_tw_reuse atur ke 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) maka kernel dapat menggunakan kembali soket di TIME_WAIT jika itu menentukan tidak akan ada kemungkinan konflik di TCP penomoran segmen.

2
Greg Bray

Saya punya masalah yang sama juga. Saya menghabiskan beberapa jam untuk mencari tahu apa yang sedang terjadi. Dalam kasus saya, alasannya adalah netstat mencoba mencari nama host yang sesuai dengan IP (saya berasumsi itu menggunakan API gethostbyaddr). Saya menggunakan instalasi Linux tertanam yang tidak memiliki /etc/nsswitch.conf. Yang mengejutkan saya, masalahnya hanya ada ketika Anda benar-benar melakukan netstat -a (menemukan ini dengan menjalankan portmap dalam mode verbose dan debug).

Sekarang apa yang terjadi adalah sebagai berikut: Per default, fungsi pencarian juga mencoba untuk menghubungi daemon ypbind (Sun Yellow Pages, juga dikenal sebagai NIS) untuk meminta nama host. Untuk menanyakan layanan ini, portmapper portmap harus dihubungi untuk mendapatkan port untuk layanan ini. Sekarang portmapper dalam kasus saya dihubungi melalui TCP. Portmapper kemudian memberi tahu fungsi libc bahwa tidak ada layanan seperti itu dan koneksi TCP ditutup. Seperti yang kita tahu, ditutup TCP koneksi masukkan status TIME_WAIT untuk beberapa waktu. Jadi netstat menangkap koneksi ini saat mendaftar dan baris baru ini dengan IP baru mengeluarkan permintaan baru yang menghasilkan koneksi baru dalam status TIME_WAIT dan seterusnya ...

Untuk mengatasi masalah ini, buat /etc/nsswitch.conf yang tidak menggunakan layanan NPC rpc yaitu dengan konten berikut:

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