「netstat」の出力に CLOSE_WAIT ステータスの接続が多数表示されるのはなぜですか?

この投稿では、「CLOSE_WAIT」状態を報告する TCP 接続について詳しく説明します。 TCP ソケットの可能な状態値は次のとおりです:

BOUND	バインド、すぐに接続または聞くことができます。
閉店	閉店。ソケットは使用されていません。
閉会	閉じてからリモート シャットダウン。確認待ちです。
CLOSE_WAIT	リモート シャットダウン。ソケットが閉じるのを待っています。
確立済み	接続が確立されました。
FIN_WAIT_1	ソケットが閉じられました。接続をシャットダウンしています。
FIN_WAIT_2	ソケットが閉じられました。リモートからのシャットダウンを待っています。
アイドル	アイドル状態、開封済みだがバインドされていない
LAST_ACK	リモート シャットダウン、その後クローズ。確認待ちです。
聞く	着信接続をリッスンしています。
SYN_RECEIVED	アクティブ/開始同期が受信され、接続が進行中
SYN_SENT	アクティブに接続を確立しようとしています。
TIME_WAIT	クローズ後にリモート シャットダウンの再送信を待ちます。

「CLOSE_WAIT」 ‘ 状態は、ローカル エンドがまだアプリケーションの終了を待っている間に、接続のもう一方のエンドが閉じられたことを意味します。

詳細

TCP 接続の「CLOSE_WAIT」状態は、システムがエンドポイントを閉じたという通知 (「FIN」パケット) を他のシステムから受信した後、システムがアプリケーションからクローズ システム コールを受信しなかった場合に発生します。言い換えると、接続のローカル エンドが相手側から「FIN」を受信したが、OS はローカル エンドのプログラムが実際に接続を閉じるのを待っていることを意味します。

問題は、ローカル マシンで実行されているプログラムがソケットを閉じていないことです。これは TCP チューニングの問題ではありません。プログラムが接続を開いたままにしている間、接続は永久に「CLOSE_WAIT」のままになる可能性があります。したがって、ほとんどの場合、この問題はアプリケーションのバグが原因で発生します。ただし、TCP/IP パラメータが適切に設定されていない場合、閉じられた TCP/IP 接続は、プロセスからファイル記述子を取得するさまざまな「CLOSE」状態で非常に長い時間留まります。この問題を解決するために、/etc/sysctl.conf 内の TCP/IP パラメーター (net.ipv4.tcp_xxx パラメーターなど) を調整して、TCP/IP 接続が短時間で閉じられるようにする必要がある場合があります。 .