膨大な量のTIME_WAIT接続でnetstatが表示される
さて、これは私を忍び寄らせています-私はこれらのうちの約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 -
編集： 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
TIME_WAITは正常です。これは、ソケットが閉じた後の状態で、カーネルによって使用され、パケットが失われてパーティーに遅れて届いた可能性があるパケットを追跡します。 TIME_WAIT接続の数が多い場合、短時間の接続が多数発生する症状であり、心配する必要はありません。
それは重要ではありません。意味するのは、Sun RCPの多くの接続を開いたり閉じたりしているということだけですTCP接続（2〜4分ごとに1500〜2500））TIME_WAIT状態は、ソケットが閉じられたときに入る状態であり、ソケットがあまりにも早く再利用された場合など、間違ったアプリケーションにメッセージが届かないようにするため、および他のいくつかの有用な目的のためです。心配しないでください。
（もちろん、実際には多くのRCP操作を処理する必要のあるものを何も実行していません。その場合は心配してください。）
システム上の何かが、システム内で多くのRPC（リモートプロシージャコール）を実行しています（ソースと宛先の両方がlocalhostであることに注意してください）。 NFSマウントのlockdでよく見られますが、rpc.statdやrpc.sprayなどの他のRPC呼び出しでも見られる場合があります。
「lsof -i」を使用して、それらのソケットを開いているユーザーを確認し、何が行われているかを確認できます。それはおそらく無害です。
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）TCPセグメント番号付けで競合が発生しないと判断した場合、カーネルはTIME_WAITでソケットを再利用できます。
私も同じ問題を抱えていました。何が起こっているのかを調べるのに数時間かかりました。私の場合、この理由は、netstatがIPに対応するホスト名を検索しようとしたためです（私はgethostbyaddr APIを使用していると想定しています）。 /etc/nsswitch.confがない組み込みLinuxインストールを使用していました。驚いたことに、この問題は実際にnetstat -aを実行しているときにのみ存在します（詳細およびデバッグモードでportmapを実行することでこれがわかります）。
次に、何が起こったのかを示します。デフォルトでは、検索機能はypbindデーモン（Sun Yellow Pages、NISとも呼ばれます）に接続してホスト名を照会しようとします。このサービスを照会するには、portmapper portmapにアクセスして、このサービスのポートを取得する必要があります。今私のポートマッパーはTCP経由で接続されました。次にポートマッパーはlibc関数にそのようなサービスが存在しないことを通知し、TCP接続が閉じられます。ご存じのように、閉じられたTCP接続は一部のTIME_WAIT状態に入りますそのため、netstatはリストを表示するときにこの接続をキャッチし、新しいIPを持つこの新しい行が、TIME_WAIT状態などの新しい接続を生成する新しい要求を発行します。
この問題を解決するには、rpc NISサービスを使用しない/etc/nsswitch.confを作成します。つまり、次の内容を含めます。
passwd: files
group: files
hosts: files dns
networks: files dns
services: files
protocols: files
netmasks: files