私は現在、Java/Tomcat ベースの Web アプリケーションの長時間実行接続を調査しています。内部またはアプリケーション ベースの理由を除外した後、ネットワーク層にまで踏み込んでいます。この問題を調査している理由は、応答時間の監視で一見ランダムなスパイクが発生しているように見えるからです。調査中に、この動作はまったくランダムではなく、特定のクライアント HTTP 要求によってトリガーされていることがわかりました。これらの接続の特別な点は、すべてが同じ IP アドレスから発信され、x-bluecoat-via HTTP ヘッダーが表示されるため、Bluecoat プロキシを使用しているように見えることです。
前述したように、アプリケーション自体は正常に動作しますが、接続の終了 (Tomcat の観点から) のみが何らかの理由で遅れているようです。サーバーはクライアントと直接通信するのではなく、F5 ロードバランサーの背後にあり、実際には応答をキャッシュする必要があります (accept-encoding アイデンティティ ヘッダーと実際の応答がバッファーに対して大きすぎるため、キャッシュされない可能性があります)。
TCP ダンプを取得しましたが、残念なミスにより、現在は LB からアプリケーション サーバーへのパッケージのみが表示され、アプリケーション サーバーから送信される実際のパッケージは表示されません。
ダンプには、同じ TCP/IP 接続上の複数のリクエストが含まれています。これは、F5 によって行われた接続プールによるものです。この接続上の最後の HTTP リクエストは、ログで長時間実行 (925836.442 ミリ秒) としてフラグが付けられた実際の接続です。私が確認したのは、リクエスト パケット、一連の ACK です。これは、アプリケーション サーバーが応答を書き込んでいると推測されます。そして最後に、2 つの FIN、ACK パッケージと、それに続く RST、ACK です。これは、F5 によって送信された最後のパケットです。
タイミングの観点から見ると、これはすべて 250 ミリ秒の間に発生し、最後のパケットは、Tomcat によって応答が完了したと判断された後に書き込まれる、アプリケーション サーバーの応答ログが表示される 15 分 13 秒前に送信されます。
現時点ではアイデアがあまり出ず、いくつか疑問があります。
Linux が RST を受信した接続を開いたままにして、アプリケーション層に通知しない理由はあるのでしょうか?
この動作を引き起こす可能性のある他のタイムアウトはありますか? これが TCP 再送信タイムアウトである場合、LB からの RST がさらに多く表示されます。
回線上の接続が閉じているのに、アプリケーション層では接続が開いたままになる理由について、他に何か考えはありますか?
アプリケーション層 (特別な HTTP リクエスト) で発生した事象が、どのようにしてトランスポート層で再現可能な動作を引き起こすのでしょうか?
おそらく私は完全に間違った方向に進んでいて、これは Tomcat 内の接続キープアライブの問題なのでしょうか?
答え1
ネットワーク層については私はあまり手助けできませんが、Tomcatではそれを設定できる場所がいくつかあります。参考文献タイムアウトを上書きして、一定時間後に接続を閉じるように設定することもできます。
リンクには、シナリオに役立つ可能性のあるロード バランサー構成も記載されています。