我目前正在调查基于 Java/Tomcat 的 Web 应用程序的长时间运行连接。在排除任何内部或基于应用程序的原因后，我现在开始研究网络层。我调查这个问题的原因是我们的响应时间监控似乎出现了随机峰值。在调查过程中，我发现这种行为根本不是随机的，而是由某些客户端 HTTP 请求触发的。这些连接的特殊之处在于它们都来自同一个 IP 地址，并且似乎使用了 Bluecoat 代理，因为我看到了 x-bluecoat-via HTTP 标头。
正如我所说，应用程序本身运行正常，只有连接结束（从 Tomcat 的角度来看）似乎有某种延迟。服务器不直接与客户端通信，而是位于 F5 负载均衡器后面，该负载均衡器实际上应该缓存答案（这可能不会发生，因为 accept-encoding 标识标头和实际响应对于缓冲区来说太大）。
我得到了一个 TCP 转储，由于一个不幸的错误，我目前只能看到从 LB 到应用服务器的包，而不是从应用服务器发送的实际包。
转储包含同一 TCP/IP 连接上的多个请求，这是由于 F5 完成的连接池化所致。此连接上的最后一个 HTTP 请求是在我们的日志中标记为长时间运行（925836.442 毫秒）的实际连接。我看到的是请求数据包，一系列 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。您可以尝试覆盖超时并将其配置为在一定时间后关闭连接。
在链接上您还可以看到负载均衡器配置，这可能对您的场景有帮助。