我遇到了一个有趣的问题，其中HTTP 1.1 POST请求的TCP连接在请求之后立即关闭（即，在服务器发送响应之前） .
有关测试环境的一些细节：
客户端 - Windows XP，Internet Explorer 8，Flash播放器12 .
服务器 - Java 7
在上述行为之前，我们有几个长期的TCP连接，每个连接都被重用于多个HTTP请求;我们打开一个长轮询，当这个轮询完成时，打开另一个 . 我们看到几个小时表现良好且重用的TCP连接在前一轮询结束时开始民意调查 . 最终 - 有时在12或更长时间的正常行为之后 - 对长期连接进行轮询将发送HTTP POST并立即发送TCP FIN，然后服务器才能编写响应 .
客户端行为是始终打开一个轮询，所以此时我们尝试打开一个新的轮询 .
然后，客户端发送另一个HTTP POST，打开一个新的TCP连接，具有相同的行为;发送请求，然后发送客户端的FIN .
此行为可以持续几分钟，直到服务器最终响应以终止客户端 . （服务器通过遇到IO异常检测到初始关闭的连接，下次它可以与客户端通信时，响应是告诉客户端关闭）
编辑：我们只通过Flash客户端打开连接，而不是深入研究低级TCP代码 . 虽然Steffen Ullrich是正确的，并且单边关闭是可能的并且应该处理，但不清楚的是为什么在这个（看似任意的）点发生单侧关闭 . 我们并没有从应用程序中调用来煽动这种行为 .
我的问题是：
-
在什么情况下，HTTP请求的TCP连接会在收到响应之前终止？我理解这是不好的行为，并且是一个不完整的HTTP事务，因此可能是较低的事情是因为未知原因而终止连接 .
-
是否有可用于帮助理解问题的诊断？ （我们目前正在使用Wireshark监控服务器和客户端活动 . ）
笔记：
在Wireshark中，我们看到的行为是：
-
提供多个HTTP请求的长期TCP连接（＃1） .
-
HTTP请求通过＃1进行 .
-
服务器确认请求 .
-
客户端发送FIN以关闭连接＃1 . 服务器以FIN，ACK响应 . （预期的流量将是发送HTTP响应的服务器） . 在这一点上，服务器会遇到IO异常 .
-
客户端打开连接＃2并发送HTTP请求 .
-
行为从3开始继续 .
1 回答
立即发送请求后跟FIN不是连接关闭，而是关闭写入
shutdown(socket,SHUT_WR). 客户端通过这种方式告诉服务器它不会再发送任何数据，但它仍然可能会收到数据 . 这并不罕见 .