いくつかの理論
私はtcpについて読んでいますTIME-WAIT（ここそしてそこには) そして私が読んだところによると、これは（セグメントの最大寿命）に設定された値であり2 x MSL、接続を「接続テーブル」にしばらく保持して、次のことを保証するとのことです。「同じタプルで接続を作成できるようになる前に、そのタプルの以前のバージョンに属するすべてのパケットは無効になります」。
接続中または接続がTIME-WAIT存在しない間に受信されたセグメント (特定の状況下での SYN を除く) は破棄されるため、接続をすぐに閉じないのはなぜでしょうか?
Q1: これは、古い接続からのセグメントを処理する処理が少なくなり、同じタプルで新しい接続を作成する処理が少なくなるためでしょうかTIME-WAIT(つまり、パフォーマンス上の利点があるのでしょうか)?
上記の説明が成り立たない場合、 がTIME-WAIT有用であると考えられる唯一の理由は、クライアントが、SYN同じタプル上の古い接続の残りのセグメントを送信する前に、接続に対して を送信する場合です。この場合、受信側は接続を再度開きますが、不良セグメントとを取得し、接続を終了する必要があります。
Q2: この分析は正しいでしょうか?
Q3: TIME-WAIT を使用すると他に利点はありますか?
練習
私は管理している本番サーバー上の Munin グラフを見てきました。ここに 1 つあります。
ご覧のとおり、 にはTIME-WAITよりも多くの接続がありESTABLISHED、ほとんどの場合は約 2 倍ですが、場合によっては 4 倍になることもあります。
Q4: パフォーマンスに影響はありますか?
Q5: もしそうなら、値を下げるのは賢明/推奨されますかTIME-WAIT（そして何をすべきですか）？
TIME-WAITQ6: この/接続の比率はESTABLISHED正常ですか? これは悪意のある接続試行に関連している可能性がありますか?
答え1
つまり、心配する必要はありませんTIME_WAIT。オーバーヘッドはほとんどなく、通常は問題になりません。
ビジー状態のサーバーではポートが枯渇する可能性がありますが、その場合には の sysctl オプションがありnet.ipv4.tcp_tw_reuse = 1、これによりカーネルはTIME_WAIT必要に応じてまだ残っている古いポートを再利用できます。
TIME_WAIT は TCP 仕様の一部であり、まだ転送中の可能性があるパケットをキャッチするためにあります (すべての接続が信頼できるわけではないことに注意してください。TCP はこれを解決することを目指していました)。タイムアウト値は、ほとんどの最新の用途では非常に高い可能性がありますが、通常は netstat の出力以外のものに干渉することはありません。
ソケットを自分で制御していて、データを待っていないことが確実な場合 (たとえば、最終送信者である場合や、応答を気にしない場合) は、オプションを設定した後にソケットを閉じることができますSO_NOLINGER。これにより、 で接続が終了しRST、直ちにソケットが破棄されます。
それであなたの質問は:
Q1、Q2、Q3: リンクが信頼できない可能性があるため、「念のため」遅れたパケットを収集するためにあります。これは仕様の一部であり、パケット損失を防ぐものであり、調整しても実際の利点はありません。
Q4: いいえ
Q5: 心配する必要はありません。必要に応じて、これらのソケットの再利用を強制するオプションがあります。
Q5:相関関係はありませんTIME_WAITがESTABLISHED、短命な接続が多いほど、その比率は大きくなります。これは悪意のある何かによって引き起こされる可能性がありますが、「過剰なネットワーク アクティビティ」がそうであるように、指標にはなりません。
答え2
TIME_WAIT に関する私の限られた経験からの回答をいくつか示します。
1/2/3) これを見て質問ですそしてこのページTIME_WAIT の適切な説明については、こちらを参照してください。これはパフォーマンスの問題というよりは、接続内のすべての TCP パケットが適切に受信されることを保証するサービス品質の問題です。
4/5) TIME_WAIT に関連するパフォーマンスの問題の 1 つは、非常に混雑したサーバーで TIME_WAIT 状態にある接続が多すぎると、最終的に利用可能な接続が不足する可能性があることです。この問題が発生した場合は、TIME_WAIT 値を減らしてみてください。ただし、これは「自分が何をしているかわかっている」調整のカテゴリに分類される可能性があります。このSOの質問さらに詳しい情報については、こちらをご覧ください。
6) TIME_WAIT のデフォルト値は、約 240 秒 (またはパケット MSL の 120 秒の 2 倍) であるはずです。したがって、確立された接続と待機中の接続の比率は、着信接続速度と接続が開いている時間によって異なります。たとえば、ビジー状態のサーバーをいくつか確認したところ、比率は 1.3 から 400 の範囲でした。これはすべて、サーバーと受信するトラフィックに基づいて正常であると考えられます。