HTTP POST在Flash连接响应前由客户端关闭

Question

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

关于测试环境的一些细节：

Client - Windows XP，8，Flash player 12.

服务器- Java 7

在上述行为之前，我们有几个长期存在的TCP连接，每个连接被重用用于多个HTTP请求；我们打开一个长轮询，当这个轮询完成时，打开另一个。当上一次投票结束时，我们看到几个小时的良好行为和重用的TCP连接打开了投票。最终--有时经过12个小时或更长时间的正常行为--对一个长期存在的连接的投票将发送HTTP，并在服务器编写响应之前立即发送一个TCP FIN。

客户端的行为是始终保持投票开放，因此在这一点上我们尝试打开一个新的投票。

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

这种行为可以持续几分钟，直到服务器最终响应以杀死客户端。(服务器通过遇到IO异常来检测初始关闭的连接，下次它可以与客户端通信时，响应是告诉客户端关闭)

编辑:我们只通过Flash客户端打开连接，而不是钻研低层TCP代码。虽然Steffen是正确的，并且单边关闭是可能的，并且应该处理，但不清楚的是为什么在这个点(看起来是任意的)出现了单边关闭。我们并不是从申请中打电话来煽动这种行为。

我的问题是：

1. 在什么情况下，HTTP请求的TCP连接会在接收响应之前终止？我知道这是不好的行为，也是一个不完整的HTTP事务，因此，可能是一些较低的东西正在以未知的原因终止连接。
2. 是否有任何可以用来帮助理解问题的诊断信息？(我们目前正在使用Wireshark监视服务器和客户端的活动。)

备注：

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

1. 提供多个HTTP请求的长期TCP连接(#1)。
2. HTTP请求是在#1上提出的。
3. 服务器ACK请求。
4. 客户端发送FIN到关闭连接#1。服务器响应FIN，ACK。(预期的通信量将是发送HTTP响应的服务器)。在这一点上，服务器经历了IO异常。
5. 客户端打开连接#2并发送HTTP请求。
6. 行为从3开始持续。

Answer 1

立即发送请求，后面跟着FIN不是连接关闭，而是关闭写入shutdown(socket,SHUT_WR)。客户端以这种方式告诉服务器，它将不再发送任何数据，但它可能仍然会接收数据。也没那么少见。