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

Question

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

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

客户端 - Windows XP，Internet Explorer 8，Flash播放器12。

服务器 - Java 7

在上述行为之前，我们有几个长期的TCP连接，每个连接都被重用于多个HTTP请求;我们打开一个长轮询，当这个轮询完成时，打开另一个。我们看到几个小时表现良好且重用的TCP连接在前一次民意调查结束时开始民意调查。 最终 - 有时在12或更长时间的正常行为之后 - 对长期连接进行轮询将发送HTTP POST并立即发送TCP FIN，然后服务器才能编写响应。

客户端的行为是始终打开一个民意调查，所以此时我们尝试打开一个新民意调查。

然后客户端发送新的TCP连接，发送另一个HTTP POST，具有相同的行为;发送请求，然后发送客户端的FIN。

此行为可以持续几分钟，直到服务器最终可以响应终止客户端。 （服务器通过遇到IO异常检测到初始关闭连接，下次它可以与客户端通信时，响应是告诉客户端关闭）

编辑：我们只通过Flash客户端打开连接，而不是深入研究低级TCP代码。虽然Steffen Ullrich是正确的，并且单边关闭是可能的并且应该处理，但不清楚的是为什么在这个（看似任意的）点发生单侧关闭。我们并没有从应用程序中调用来煽动这种行为。

我的问题是：

1. 在收到响应之前，在什么情况下会终止HTTP请求的TCP连接？我理解这是不好的行为，并且是一个不完整的HTTP事务，因此可能是较低的事情是因为未知原因而终止连接。

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

注意：

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

1. 提供多个HTTP请求的长期TCP连接（＃1）。
2. HTTP请求是通过＃1。
3. 服务器确认请求。
4. 客户端发送FIN以关闭连接＃1。服务器以FIN，ACK响应。 （预期的流量将是发送HTTP响应的服务器）。在这一点上，服务器会遇到IO异常。
5. 客户端打开连接＃2并发送HTTP请求。
6. 行为从3开始继续。

Answer 1

立即发送请求后跟FIN不是连接关闭，而是关闭写shutdown(socket,SHUT_WR)。客户端通过这种方式告诉服务器它不会再发送任何数据，但它仍然可能会收到数据。这并不罕见。