Koneksi TIME_WAIT dalam jumlah besar mengatakan netstat

28

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

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

Angka itu berubah dengan cepat.

Saya memiliki konfigurasi iptables yang cukup ketat sehingga saya tidak tahu apa yang menyebabkan ini. 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   -

— KTAMA
sumber

1

Apakah Anda memiliki sesuatu yang dipasang NFS pada mesin yang sama yang mengekspornya?

— Paul Tomblin

@ Paulus Tomblin: Tidak

— KTamas

1

Nah, Anda harus melihat koneksi yang sudah ada untuk mengetahui program mana yang tepat. "rcpinfo -p" juga dapat membantu mencari tahu apa yang berkomunikasi dengan portmapper.

— cstamas

Bagi mereka yang menemukan jalan mereka di sini saat mencoba menemukan cara untuk menyesuaikan penundaan di Windows, itu dapat dilakukan melalui pengaturan registri .

— Synetech

22

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

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

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

Dan mengubahnya dengan memodifikasi nilai itu:

[root@dev 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

— Brandon
sumber

ya skrip ipconfig saya sudah menurunkannya menjadi 30. Saya tidak punya nfsd di /etc/init.d/, tapi saya sudah menjalankan portmap, menghentikannya, sekarang TIME_WAIT diturunkan ke beberapa instance (1-5). Terima kasih.

— KTamas

18

Uhh, tcp_fin_timeout tidak ada hubungannya dengan soket dalam keadaan time_wait. Itu mempengaruhi fin_wait_2.

— diq

2

+1 untuk komentar diq. Mereka tidak berhubungan.

— mcauth

1

Benar ... Anda dapat melihat soket menghitung mulai dari 60 meskipun tcp_fin_timeout diubah menggunakanss --numeric -o state time-wait dst 10.0.0.100

— Greg Bray

16

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.

— David Pashley
sumber

Jawaban ini pendek dan manis. Ini sangat membantu. Kalimat terakhir sedikit membingungkan saya, tetapi saya pikir intinya adalah Anda perlu memahami mengapa begitu banyak koneksi yang dibuat. Jika Anda menulis klien yang menghasilkan banyak permintaan, Anda mungkin ingin memastikan bahwa itu dikonfigurasi untuk menggunakan kembali koneksi yang ada daripada membuat yang baru untuk setiap permintaan.

— Nobar

Keringat pendek, tidak lengkap. TIME_WAIT bergantung pada konteksnya. Jika Anda memiliki banyak dari mereka, mungkin seseorang menyerang server Anda.

— Mindaugas Bernatavičius

5

Itu tidak penting. Semua yang menandakan adalah bahwa Anda membuka dan menutup banyak koneksi TCP Sun RCP (1500-2500 dari mereka setiap 2-4 menit). The TIME_WAITnegara adalah apa socket masuk ke dalam ketika menutup, untuk mencegah pesan dari tiba untuk aplikasi yang salah seperti mereka mungkin jika soket yang digunakan kembali terlalu cepat, dan untuk beberapa tujuan lain yang bermanfaat. Jangan khawatir tentang itu.

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

— kekacauan
sumber

Saya menjalankan kurir-imap dan postfix, kebanyakan.

— KTamas

4

Sesuatu pada sistem Anda sedang melakukan banyak RPC (Remote Procedure Calls) 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.

— Paul Tomblin
sumber

Tidak ada yang tidak biasa di sana, saya melihat TCP *: sunrpc (DENGARKAN) untuk portmap tapi tebak itu normal.

— KTamas

Terus lakukan itu berulang kali sampai Anda melihat siapa yang membuka koneksi.

— Paul Tomblin

netstat -epn --tcp akan menampilkan informasi yang sama kepada Anda. Kecuali Anda menggunakan NFS, Anda mungkin memiliki sedikit alasan untuk menggunakan portmap. Anda bisa menghapusnya.

— David Pashley

Saya memang tidak menggunakan NFS, namun apt-get remove portmap ingin menghapus 'fam' yang secara otomatis diinstal mungkin oleh libfam0 yang diinstal oleh kurir-imap. apt-cache mengatakan 'fam' adalah paket yang disarankan untuk libfam0.

— KTamas

2

tcp_fin_timeoutTIDAK mengontrol TIME_WAITpenundaan. 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 dari 60. Namun jika Anda memiliki net.ipv4.tcp_tw_reuse diatur 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.

— Greg Bray
sumber

1

Saya punya masalah yang sama juga. Saya menghabiskan beberapa jam untuk mencari tahu apa yang sedang terjadi. Dalam kasus saya, alasan untuk ini adalah bahwa 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 dap 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 ketahui, koneksi TCP tertutup memasuki keadaan TIME_WAIT untuk beberapa waktu. Jadi netstat menangkap koneksi ini ketika 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

— Leecher
sumber