TCP状態TIME_WAITとHTTPキープアライブの関係
HTTPリクエストのキープアライブとTIME_WAITのTCPソケットの関係は何ですか？それらは相関する必要がありますか？
さらに、システムとWebサーバーの設定を一致させる必要があります。 server.max-keep-alive-idle = 60？ TIME_WAITのソケット数を減らす方法は？ Linuxでは、TIME_WAIT状態は60秒でハードコードされています（少なくともLinuxのUbuntu/Debain値の場合）。
Lighttpdでは、デフォルト値server.max-keep-alive-idle = 5そして、彼らは高負荷のためにさらに低いことを勧めます。 TCPソケットが使用可能な場合、5秒後にhttpリクエストを閉じるのは無駄です。もちろん、設定net.ipv4.tcp_tw_reuse = 1缶に書かれていることを行います。
この関連する質問- tcpはどのようにして接続を維持しますか？[クローズ] 問題に触れますが、私には完全には答えていません。
TCPはレイヤー4、HTTPレイヤー7です。
HTTP 1.0では、HTTPキープアライブがレイヤー7で使用され、Connectionヘッダーを使用して永続的な接続をシミュレートします。
HTTP 1.1では、接続はデフォルトで永続的であると見なされ、TCPそのジョブを実行するためにのみ依存します。リクエストは同じTCP接続、一方の側は最後の要求または応答ヘッダーにConnection: closeを設定するので、両方の側はHTTP要求をこれ以上交換できないことを認識し、接続が閉じられます。
通常、Webサーバーの場合、TIME_WAIT状態は、接続をアクティブに閉じることを決定すると、クライアントのFINパケットを受信し、最後のACK4方向の分解に戻ります。この後、2 * MSLを待ちます。これは、接続が確実に閉じられるようにするための方法です。これが、カーネルでコンパイルされた60sの出所です。このようにして、同じ4タプルを使用した新しい接続で、前の接続から発生した順序が狂ったパケットを受信しないことが確実になります。
変更したくない。
反対側では、server.max-keep-alive-idleはタイムアウトであり、HTTPリクエストが受信されず、Webサーバーによってアクティブに閉じられた場合、ESTABLISHED接続はアイドルと見なされます。この決定が行われると、今あなたが理解しているように、TCPティアダウンが行われます。
tcp_tw_recycleには十分注意してください。訪問者が、広いNATネットワークの背後から来ている場合、同じ4つのタプルで複数のTCP接続が発生し、タイムスタンプが乱れる可能性があります。サーバー側でクライアント接続試行をサイレントにドロップする場合。
したがって、最良のオプションは、lighttpdで見たパラメータを調整することです。システム全体で、FIN_WAIT2状態とTIME_WAIT状態のソケットのバケットを安全にnet.ipv4.tcp_fin_timeoutとnet.ipv4.tcp_max_tw_bucketsで下げることができます。