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

Question

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

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

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

服务器 - Java 7

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

客户端的行为是始终保持投票打开，所以此时我们尝试打开一个新的投票。

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

这种行为可以持续几分钟，直到服务器最终可以响应杀死客户端。 （服务端通过遇到IO Exception检测初始关闭的连接，下次可以和客户端通信，响应就是告诉客户端关闭）

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

我的问题是：

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

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

注意事项：

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

1. 长期 TCP 连接 (#1) 服务于多个 HTTP 请求。
2. HTTP 请求通过 #1 发出。
3. 服务器确认请求。
4. 客户端发送 FIN 以关闭连接 #1。服务器以 FIN,ACK 响应。 （预期的流量将是发送 HTTP 响应的服务器）。大约在此时，服务器会遇到 IO 异常。
5. 客户端打开连接 #2 并发送 HTTP 请求。
6. 行为从 3 开始继续。

Answer 1

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