实际上，我正在研究基于Java / Tomcat的Web应用程序的长时间运行连接。 排除任何内部或应用程序的原因后，我现在是在networking层。 我调查这个问题的原因是，我们在响应时间监控方面似乎有随机高峰。 在调查过程中，我发现这种行为并不是那么随意，而是由某些客户端HTTP请求触发的。 关于这些连接的特殊之处在于，它们都来自相同的IP地址，并且似乎使用了Bluecoat Proxy，因为我通过HTTP标头看到了x-bluecoat。
正如我所说，应用程序本身正常执行，只有连接的结束（从Tomcat的angular度来看）似乎有点延迟。 服务器不直接与客户端通话，而是在F5负载均衡器的后面，这个负载均衡器应该实际caching答案（这可能不会发生，因为接受编码的标识头，实际响应对于缓冲区来说是很大的）。
我得到了一个TCP转储，由于一个不幸的错误，我目前只能看到从LB到应用服务器的包，而不是从应用服务器发送的实际包。
转储在同一TCP / IP连接上包含多个请求，这是由F5完成的连接池所致。 此连接上的最后一个HTTP请求是在我们的日志logging中被标记为长时间运行（925836.442ms）的实际连接。 我看到的是请求数据包，一系列的ACK使我相信应用服务器正在写它的答案，最后是两个FIN，ACK包，后面是RST，ACK是F5发送的最后一个数据包。
从定时的angular度来看，这一切都发生在250ms的过程中，最后一个数据包发送15分钟和13秒，然后我看到应答服务器上的响应日志，这个响应被认为是由Tomcat完成后写入的。
我现在有点想法，并有一些开放的问题：
Linux是否有任何理由保持打开一个已经收到RST的连接而不告诉应用层？
是否有其他超时可能导致此行为？ 如果这将是TCP重传超时，我会看到来自LB的更多RST。
任何其他的想法，为什么一个封闭的连接线将导致在应用层仍然打开连接？
在应用层（特殊的HTTP请求）中发生的事情如何导致传输层中的重复行为？
也许我完全在错误的轨道上，这是一个连接保持在Tomcat里面的问题？
我不能真正帮助networking层，但在Tomcat上有几个地方可以configurationhttp://tomcat.apache.org/connectors-doc/reference/workers.html 。 您可以尝试覆盖超时并将其configuration为在一段时间后closures连接。
在链接上，你也有负载平衡器configuration，这可能是你的scheme有帮助。