005_关于HTTP协议中的保持连接
Posted arun
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了005_关于HTTP协议中的保持连接相关的知识,希望对你有一定的参考价值。
缘起
中午在群里讨论,用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协议中的保持连接的主要内容,如果未能解决你的问题,请参考以下文章