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的情况:

技术分享

客户端Connectionkeep-aliveKeep-Alive5的情况

技术分享

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

最后一个场景, server配置keepalive为3, client Connectionkeep-aliveKeep-Alive5的情况

技术分享

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

结论

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

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

以上是关于005_关于HTTP协议中的保持连接的主要内容,如果未能解决你的问题,请参考以下文章

计算机网络学习-005

HTTP协议及HTTPS,能否保持长连接等

HTTP协议中的短轮询、长轮询、长连接和短连接

Apache保持连接

蓝牙协议分析_BLE连接有关的技术分析

005-TCP传输控制协议