Java Flash中的HTTP POST-客户端在响应之前关闭TCP连接

我遇到了一个有趣的问题，HTTP 1.1 POST请求的TCP连接在请求之后立即关闭（即，在服务器可以发送响应之前）

有关测试环境的一些详细信息：

客户端-Windows XP、Internet Explorer 8、Flash player 12

服务器-Java 7

在上述行为之前，我们有几个长期存在的TCP连接，每个连接都可用于多个HTTP请求；我们打开一个长轮询，当此轮询完成时，打开另一个轮询。在上一次投票结束时，我们看到几个小时行为良好且重复使用的TCP连接打开投票。 最终——有时在正常行为持续12个小时或更长时间之后——在服务器写入响应之前，对长期连接的轮询将发送HTTP POST并立即发送TCP FIN

客户机的行为是始终保持民意调查处于打开状态，因此在这一点上，我们尝试打开一个新的民意调查

然后，发送另一个HTTP POST的客户端以相同的行为打开一个新的TCP连接；发送请求，然后是来自客户端的FIN

这种行为可能会持续几分钟，直到服务器最终能够响应终止客户端。（服务器通过遇到IO异常来检测初始关闭的连接，下次可以与客户端通信时，响应是通知客户端关闭）

编辑：我们只通过Flash客户端打开连接，不深入研究低级TCP代码。虽然Steffen Ullrich是正确的，单侧停堆是可能的，应该加以处理，但不清楚的是，为什么单侧停堆发生在这一点上（似乎是任意的）。我们不是从应用程序中调用close来煽动这种行为

我的问题是：

在什么情况下，HTTP请求的TCP连接会在收到响应之前终止？我知道这是一种不好的行为，而且是一个不完整的HTTP事务，所以可能是因为未知的原因终止了连接

是否有任何诊断方法可用于帮助理解问题？（我们目前正在使用Wireshark监控服务器和客户端活动。）

注:

在Wireshark中，我们看到的行为是：

为多个HTTP请求提供服务的长期TCP连接（#1）

HTTP请求通过#1进行

服务器确认请求

客户端发送FIN以关闭连接#1。服务器用FIN、ACK响应。（预期流量将是发送HTTP响应的服务器）。在这一点上，服务器会遇到IO异常

客户端打开连接#2并发送HTTP请求

行为从3月3日开始持续

---

在FIN之后立即发送请求并不是连接关闭，而是停止写入

shutdown（socket，shuth\u WR）

。客户机以这种方式告诉服务器，它将不再发送任何数据，但它仍可能接收数据。这并不少见。

我们没有收到响应，因此客户端不再接收数据，除了服务器用FIN、ACK响应TCP FIN之外。在什么情况下，当没有预期或明确要求时，会调用shutdown（）？我们不在低层处理TCP，而是通过Flash/浏览器与之交互。单面关机的信号并不少见，即一方将不再发送数据。web服务器必须处理它，例如，它必须期望在请求完成后，客户端将告诉服务器不再填充数据，例如，关闭其写入。另请参阅。我知道情况可能是这样。让我感到不安的是，为什么此时可能会要求单方面关闭。这是来自Flash运行时、浏览器、内核，还是不可能知道？单边关闭是由用户空间通过调用shutdown启动的，因此它不是内核。据我所知，Flash运行时有自己的独立于浏览器的网络处理，所以我猜在这种情况下它是由Flash完成的。