實際上，我目前正在研究基於 Java/Tomcat 的 Web 應用程式的長時間運行連線。在排除任何內部或基於應用程式的原因後，我現在進入網路層。我調查這個問題的原因是我們的回應時間監控中出現了看似隨機的峰值。在調查過程中，我發現這種行為根本不是隨機的，而是由某些客戶端 HTTP 請求觸發的。這些連接的特殊之處在於它們都源自相同的 IP 位址，並且似乎使用 Bluecoat 代理，因為我看到 x-bluecoat-via HTTP 標頭。
正如我所說，應用程式本身執行正常，只有連接結束（從 Tomcat 的角度來看）似乎有某種延遲。伺服器不會直接與客戶端對話，而是位於F5 負載平衡器後面，該負載平衡器實際上應該快取答案（這可能不會發生，因為接受編碼身份標頭和實際回應對於緩衝區來說太大） 。
我得到了 TCP 轉儲，由於一個不幸的錯誤，我目前只能看到從 LB 到應用程式伺服器的包，而不是從應用程式伺服器發送的實際包。
轉儲包含同一 TCP/IP 連線上的多個請求，這是由於 F5 完成的連線池所致。此連線上的最後一個 HTTP 請求是在我們的日誌記錄中標記為長時間運行的實際連線 (925836.442ms)。我看到的是請求封包、一系列ACK，這讓我相信應用程式伺服器正在寫入它的答案，最後是兩個FIN、ACK 封包，後面跟著一個RST、ACK，這是F5 發送的最後一個數據包。
從時間的角度來看，這一切都發生在250 毫秒的過程中，最後一個資料包是在我看到應用程式伺服器上的回應日誌之前發送的15 分13 秒，該日誌是在Tomcat 完成回應之後寫入的。
我現在有點沒有想法，有幾個懸而未決的問題：
Linux 有沒有理由保持已收到 RST 的連線開啟而不告訴應用層？
是否還有其他超時可能導致此行為？如果這是 TCP 重傳逾時，我會看到來自 LB 的更多 RST。
還有其他想法為什麼線路上的關閉連接會導致應用程式層中的連接仍然打開嗎？
應用層中發生的事情（特殊的 HTTP 請求）如何導致傳輸層中的可重現行為？
也許我完全走錯了路，這是 Tomcat 內部的連結保持活動問題？
答案1
我無法在網路層上提供真正的幫助，但是在 Tomcat 上有幾個地方可以配置它http://tomcat.apache.org/connectors-doc/reference/workers.html。您可以嘗試覆蓋逾時並將其配置為在一段時間後關閉連線。
在連結上，您還可以找到負載平衡器配置，這可能對您的場景有所幫助。