HTTP的KeepAlive与TCP的LINGER

用IE访问一个网页下载一个文件，抓包获取HTTP的Request和Response，发现在Response后面有一个RST：

这是怎么回事呢？没有正常发FIN断开连接。我们看HTTP的GET细节：

有一个KeepAlive，这说明客户端希望保持住TCP连接，它可能会重用这个TCP连接发送另一个HTTP请求或者别的HTTP数据。然后我们看Response的细节：

服务器把KeepAlive给echo回来了，这意味着服务器“同意”了客户端的KeepAlive。接下来会怎样呢？这里面比较复杂：

a).服务端的KeepAlive为15s，超过15s如果客户端不再发送新的HTTP数据，服务端就会发送FIN断开TCP连接。
b).客户端即便GET时发送了KeepAlive头，且服务端也echo回来KeepAlive，客户端也可以断开TCP，要么正常发送FIN断开，要么发送RST断开。

虽然服务端同意了KeepAlive，但那是HTTP层面的，这意味着服务端会等客户端15s的时间，客户端在这段时间内可以随意，如果客户端发送了FIN，服务端也会FIN，客户端也会发送RST，问题是什么情况下会发送RST呢？

        我们知道，如果TCP socket设置了LINGER的时候，会在close的时候改变行为，这取决于LINGER参数怎么设置，具体的内容可以自行google。简单来讲，设置了LINGER，客户端close的时候不会发送FIN，而是会立即或者等待一段时间直接发送RST断开连接，同时清除发送队列里的所有未发送的数据。我上面抓的包完全符合这个，也就是说IE设置了LINGER！是不是呢？

        我也不知道，我没有IE的源码...但是十有八九是这样子的。其实嘛，仔细想象一下，IE这么玩是合理的，因为清除自己发送队列的数据也没有什么不妥，毕竟自己都要关闭连接了，close是自己调用的，这说明它自己知道这时候已经无所谓了，又为何为了完成TCP的正常关闭状态机而发送FIN，发送RST可能更加直接，显然TCP的设计也充分考虑到了这种“主动”行为，从而保留了LINGER接口。

        服务端也可以拒绝客户端的KeepAlive，这个时候服务端在发送完Response数据后，会立即发送FIN断开连接。什么时候服务端会拒绝KeepAlive呢？这可以通过服务端的配置来完成，比如Apache服务器的配置文件中：

# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

同时，也可以配置不同的请求细节而做出不同的反应：

# The following directives modify normal HTTP response behavior to
# handle known problems with browser implementations.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "Mozilla/5" keepalive
BrowserMatch "MSIE 4.0b2;" nokeepalive downgrade-1.0 force-response-1.0

好了，细节知道了一点点，之后我怎么确认IE就是设置了LINGER呢？我无法确认！我试着用Firefox和QQ浏览器试一下，均没有发现有RST的发送。我需要发现一个设置了LINGER的浏览器所表现了和IE一样的行为，这就说明...

        这什么也说明不了，但是我喜欢用这种方法做任何事情。这种方法叫做拟合。我就不扯什么线性回归和最小二乘法了，不管怎么说吧，我觉得，任何事情，当你不知道细节的时候，那就用你知道细节的东西去模拟，直到模拟出相似的现场，那么此时的细节就是你要知道的细节，这个过程是模糊匹配，取决于你要的精度！但是很多人会不喜欢这种方法，...其实我倒是觉得倒着做事反而更加可控，当有人反驳说我连现象的规律都摸不清的时候，怎么去拟合，其实我的目标就是去摸清现象的规律，我当然不知道细节，我只要有大数据就好了。

        我还真得谢谢前同事，一个精通WEB和各种高性能服务器的人，我本来是不懂什么HTTP的，也曾经想学PHP，但从来没有正儿八经的学会过，这次通过这个契机，我感觉可以去学学WEB了。