关于HTTP协议中的保持连接

时间:2022-05-12
本文章向大家介绍关于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-alive, Keep-Alive5的情况

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

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

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

结论

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

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