005_关于HTTP协议中的保持连接

标签：一段   请求头   ddn   个数   alt   pcl   结束   并且   重要   

缘起

中午在群里讨论，用ab测试 一台只提供静态文件服务， 不与其他任何系统交互的时候，为什么也会产生大量的TIME WAIT状态的。

首先，我们可以简单的理解，在TCP连接的两端，谁主动断开连接(先发送FIN包)，谁进入TIME WAIT，谁被动断开连接(后发送FIN包)，谁进入CLOSE WAIT状态。

那么，由此可以推断，在这个场景中，server是主动断开连接的一方，那么server为什么会主动断开呢， 这就涉及到HTTP里关于keepalive的内容了。

我们常常听说keepalive能提高webserver的性能， 但是为什么呢？ 这里暂且不解释，说完下面的内容，就清楚了。

分析

在HTTP协议中， 除了需要服务器支持并打开keepalive之外， 还有一个重要的请求头Connection需要注意。

我们来看下面一个请求：

GET /? HTTP/1.1
Accept: */*
Cache-Control: no-cache
Connection: close
Host: 127.0.0.1
User-Agent: Apache-HttpClient/4.3.2 (java 1.5)
Accept-Encoding: gzip,deflate

这是我通过Idea 的REST Client 插件发送的一个请求， 我们看到 Connection头的值是close，抓包看一下请求过程

可以看到， 在server响应完成后， 发送了FIN 包， 主动断开连接， 这很好理解。

在来看一个请求：

GET /? HTTP/1.1
Accept: */*
Cache-Control: no-cache
Connection: keep-alive
Keep-Alive: 5
Host: 127.0.0.1
User-Agent: Apache-HttpClient/4.3.2 (java 1.5)
Accept-Encoding: gzip,deflate

可以看到， 这个请求里， Connection的值变成了keep-alive， 并且多了一个Keep-Alive头，值为5。再抓包看看这次请求：

可以看到， server在响应完成后，并没有发送FIN包关闭连接， 而是一段时间后，客户端发送FIN包，关闭连接， 如果你看第二列， time会发现，正好是大约5秒后，客户端发送了FIN包， 这个数值正好是 Keep-Alive头的值。事实上，Keep-Alive头的语义就是客户端保持连接多少秒。

以上的测试， server配的keepalive都是65s， 我们来把它0， 再来测试一遍看看。

客户端Connection头为close的情况：

客户端Connection为keep-alive, Keep-Alive为5的情况

可以看到，server主动断开连接。

最后一个场景， server配置keepalive为3， client Connection为keep-alive, Keep-Alive为5的情况

可以看到，请求结束大约3秒后(主要时间戳)，server发送FIN主动断开连接。

结论

说了这么多，是时候总结一下了，关于keepalive主要有一下几点：

• Connection 头控制客户端是否开启， close 不开启， keep-alive开启
• Keep-Alive头控制客户端保持连接的时间
• 在开启keepalive的时候， 谁先到保持连接的时间，谁先发FIN包，主动关闭连接。

005_关于HTTP协议中的保持连接

标签：一段   请求头   ddn   个数   alt   pcl   结束   并且   重要   

原文地址：http://www.cnblogs.com/itcomputer/p/7767982.html