HTTP Keep-Alive 学习

最新推荐文章于 2023-07-20 18:32:32 发布

FzBcumt

最新推荐文章于 2023-07-20 18:32:32 发布

阅读量237

点赞数

分类专栏： HTTP协议文章标签： HTTP协议 Keep-Alive

本文链接：https://blog.csdn.net/FzBcumt/article/details/84653872

版权

HTTP协议专栏收录该内容

1 篇文章 0 订阅

订阅专栏

面试某家互联网公司时，问道HTTP中Keep-Alive，平时经常会在http 头文件看到

Connection:

keep-alive，但要我讲它的用途，确实不知道！

以下是介绍HTTP中Keep-Alive的文章，转自现代魔法学院

section 01 HTTP Keep-Alive是什么？如何工作？

HTTP Keep-Alive

在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。

使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。

但是，keep-alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。

keepalvie timeout

Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。

当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。

下面写一个脚本，方便测试：

 
sleep(60);  //为了便于分析测试，会根据测试进行调整 
 
echo "www.example.com";

1. 当keepalive_timeout时间为0时，即不启用Keep-Alive时，一个tcp连接的生命周期：

 
    01#tcpdump -n host 218.1.57.236 and port 80
 
36:50.792731 IP 218.1.57.236.43052 > 222.73.211.215.http: S 1520902589:1520902589(0) win 65535
 
36:50.792798 IP 222.73.211.215.http > 218.1.57.236.43052: S 290378256:290378256(0) ack 1520902590 win 5840
 
36:50.801629 IP 218.1.57.236.43052 > 222.73.211.215.http: . ack 1 win 32768
 
    05 
 
36:50.801838 IP 218.1.57.236.43052 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768
 
36:50.801843 IP 222.73.211.215.http > 218.1.57.236.43052: . ack 797 win 59
 
    08 
 
37:50.803230 IP 222.73.211.215.http > 218.1.57.236.43052: P 1:287(286) ack 797 win 59
 
37:50.803289 IP 222.73.211.215.http > 218.1.57.236.43052: F 287:287(0) ack 797 win 59
 
37:50.893396 IP 218.1.57.236.43052 > 222.73.211.215.http: . ack 288 win 32625
 
37:50.894249 IP 218.1.57.236.43052 > 222.73.211.215.http: F 797:797(0) ack 288 win 32625
 
37:50.894252 IP 222.73.211.215.http > 218.1.57.236.43052: . ack 798 win 59

第1~3行建立tcp三次握手，建立连接。用时8898μs
第4~5行通过建立的连接发送第一个http请求，服务端确认收到请求。用时5μs
第5~6行，可以知道脚本执行用时60s1387μs,与php脚本相符。
第6、8行服务端发送http响应。发送响应用时90166μs。
第7行，表明由服务端守护进程主动关闭连接。结合第6、8行，说明http响应一旦发送完毕，服务端马上关闭这个tcp连接
第7、9、10说明tcp连接顺序关闭,用时90963μs。需要注意,这里socket资源并没有立即释放，需要等待2MSL时间（60s）后才被真正释放。

由此可见，在没有设置 keepalive_timeout 情况下，一个socket资源从建立到真正释放需要经过的时间是:建立tcp连接 + 传送http请求 + php脚本执行 + 传送http响应 + 关闭tcp连接 + 2MSL 。(注:这里的时间只能做参考，具体的时间主要由网络带宽，和响应大小而定)

2. 当keepalive_timeout时间大于0时，即启用Keep-Alive时，一个tcp连接的生命周期。为了便于分析，我们将keepalive_timeout设置为300s

 
    01#tcpdump -n host 218.1.57.236 and port 80
 
38:05.471129 IP 218.1.57.236.54049 > 222.73.211.215.http: S 1669618600:1669618600(0) win 65535
 
38:05.471140 IP 222.73.211.215.http > 218.1.57.236.54049: S 4166993862:4166993862(0) ack 1669618601 win 5840
 
38:05.481731 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 1 win 32768
 
38:05.481976 IP 218.1.57.236.54049 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768
 
38:05.481985 IP 222.73.211.215.http > 218.1.57.236.54049: . ack 797 win 59
 
    07 
 
38:07.483626 IP 222.73.211.215.http > 218.1.57.236.54049: P 1:326(325) ack 797 win 59
 
38:07.747614 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 326 win 32605
 
43:07.448454 IP 222.73.211.215.http > 218.1.57.236.54049: F 326:326(0) ack 797 win 59
 
43:07.560316 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 327 win 32605
 
43:11.759102 IP 218.1.57.236.54049 > 222.73.211.215.http: F 797:797(0) ack 327 win 32605
 
43:11.759111 IP 222.73.211.215.http > 218.1.57.236.54049: . ack 798 win 59

我们先看一下，第6~8行，跟上次示例不一样的是，服务端httpd守护进程发完响应后，没有立即主动关闭tcp连接。
第8行，结合第6行，我们可以看到，5分钟(300s)后，服务端主动关闭这个tcp连接。这个时间，正是我们设置的keepalive_timeout的时间。
由此可见，设置了keepalive_timout时间情况下，一个socket建立到释放需要的时间是多了keepalive_timeout时间。

3. 当keepalive_timeout时间大于0，并且在同一个tcp连接发送多个http响应。这里为了便于分析，我们将keepalive_timeout设置为180s

通过这个测试，我们想弄清楚,keepalive_timeout是从第一个响应结束开启计时，还是最后一个响应结束开启计时。测试结果证实是后者，这里，我们每隔120s发一次请求，通过一个tcp连接发送了3个请求。

 
    01# tcpdump -n host 218.1.57.236 and port 80
 
43:57.102448 IP 218.1.57.236.49955 > 222.73.211.215.http: S 4009392741:4009392741(0) win 65535
 
43:57.102527 IP 222.73.211.215.http > 218.1.57.236.49955: S 4036426778:4036426778(0) ack 4009392742 win 5840
 
43:57.111337 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1 win 32768
 
    05 
 
43:57.111522 IP 218.1.57.236.49955 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768
 
43:57.111530 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 797 win 59
 
43:59.114663 IP 222.73.211.215.http > 218.1.57.236.49955: P 1:326(325) ack 797 win 59
 
43:59.350143 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 326 win 32605
 
    10 
 
45:59.226102 IP 218.1.57.236.49955 > 222.73.211.215.http: P 1593:2389(796) ack 650 win 32443
 
45:59.226109 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 2389 win 83
 
46:01.227187 IP 222.73.211.215.http > 218.1.57.236.49955: P 650:974(324) ack 2389 win 83
 
46:01.450364 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 974 win 32281
 
    15 
 
47:57.377707 IP 218.1.57.236.49955 > 222.73.211.215.http: P 3185:3981(796) ack 1298 win 32119
 
47:57.377714 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 3981 win 108
 
47:59.379496 IP 222.73.211.215.http > 218.1.57.236.49955: P 1298:1622(324) ack 3981 win 108
 
47:59.628964 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1622 win 32768
 
    20 
 
50:59.358537 IP 222.73.211.215.http > 218.1.57.236.49955: F 1622:1622(0) ack 3981 win 108
 
50:59.367911 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1623 win 32768
 
50:59.686527 IP 218.1.57.236.49955 > 222.73.211.215.http: F 3981:3981(0) ack 1623 win 32768
 
50:59.686531 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 3982 win 108

第一组，三个ip包表示tcp三次握手建立连接，由浏览器建立。
第二组，发送第一次http请求并且得到响应，服务端守护进程输出响应之后，并没马上主动关闭tcp连接。而是启动keepalive_timout计时。
第三组，2分钟后，发送第二次http请求并且得到响应，同样服务端守护进程也没有马上主动关闭tcp连接，重新启动keepalive_timout计时。
第四组，又2分钟后，发送了第三次http请求并且得到响应。服务器守护进程依然没有主动关地闭tcp连接（距第一次http响应有4分钟了,大于keepalive_timeout值），而是重新启动了keepalive_timout计时。
第五组，跟最后一个响应keepalive_timeout(180s)内，守护进程再没有收到请求。计时结束，服务端守护进程主动关闭连接。4次挥手后，服务端进入TIME_WAIT状态。

这说明，当设定了keepalive_timeout，一个socket由建立到释放，需要时间是：tcp建立 + (最后一个响应时间 – 第一个请求时间) + tcp关闭 + 2MSL。红色加粗表示每一次请求发送时间、每一次请求脚本执行时间、每一次响应发送时间，还有两两请求相隔时间。进一步测试，正在关闭或者TIME_WAIT状态的tcp连接，不能传输http请求和响应。即，当一个连接结束keepalive_timeout计时，服务端守护进程发送第一个FIN标志ip包后，该连接不能再使用了。

http keep-alive与tcp keep-alive

http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP连接状况的保鲜机制。tcp keep-alive保鲜定时器，支持三个系统内核配置参数：

 
    1echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
 
    2echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl
 
    3echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

keepalive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置idle（双方没有任何数据流发送往来）了tcp_keepalive_time后，服务器内核就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次，每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。

也就是说，仅当nginx的keepalive_timeout值设置高于tcp_keepalive_time，并且距此tcp连接传输的最后一个http响应，经过了tcp_keepalive_time时间之后，操作系统才会发送侦测包来决定是否要丢弃这个TCP连接。一般不会出现这种情况，除非你需要这样做。

keep-alive与TIME_WAIT

使用http keep-alvie，可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。

最后

我想用一张示意图片来说明使用启用keepalive的不同。另外，http keepalive是客户端浏览器与服务端httpd守护进程协作的结果，所以，我们另外安排篇幅介绍不同浏览器的各种情况对keepalive的利用。

section 02 了解HTTP Keep-Alive的基本情况

Keep-Alive是HTTP协议中非常重要的一个属性。大家知道HTTP构建在TCP之上。在HTTP早期实现中，每个HTTP请求都要打开一个socket连接。这种做效率很低，因为一个Web 页面中的很多HTTP请求都指向同一个服务器。例如，很多为Web页面中的图片发起的请求都指向一个通用的图片服务器。持久连接的引入解决了多对已请求服务器导致的socket连接低效性的问题。它使浏览器可以再一个单独的连接上进行多个请求。浏览器和服务器使用Connection头ilai指出对Keep-Alive的支持。

HTTP是一个请求<->响应模式的典型范例，即客户端向服务器发送一个请求信息，服务器来响应这个信息。在老的HTTP版本中，每个请求都将被创建一个新的客户端->服务器的连接，在这个连接上发送请求，然后接收请求。这样的模式有一个很大的优点就是，它很简单，很容易理解和编程实现；它也有一个很大的缺点就是，它效率很低，因此Keep-Alive被提出用来解决效率低的问题。

HTTP/1.0

HTTP 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；HTTP 1.1中默认启用Keep-Alive，如果加入"Connection: close"，才关闭。

在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。

HTTP/1.1

目前大部分浏览器都是用HTTP 1.1协议，也就是说默认会启用Keep-Alive的连接请求。列举以下浏览器的并发数作参考：IE6,7在HTTP/1.0中默认最大并发连接数为4，在HTTP/1.1中默认最大并发连接数为2，IE8都为6，Firefox2在HTTP/1.0中默认最大并发连接数为2 在HTTP/1.1中默认最大并发连接数为8，firefox 3默认都是6。

在HTTP/1.1版本中，官方规定的Keep-Alive使用标准和在HTTP/1.0版本中有些不同，默认情况下所在HTTP1.1中所有连接都被保持，除非在请求头或响应头中指明要关闭：Connection: Close ，这也就是为什么Connection: Keep-Alive字段再没有意义的原因。另外，还添加了一个新的字段Keep-Alive:，因为这个字段并没有详细描述用来做什么，可忽略它。

Not reliable（不可靠）

HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果。

Keep-Alive和POST

在HTTP1.1细则中规定了在一个POST消息体后面不能有任何字符，还指出了对于某一个特定的浏览器可能并不遵循这个标准（比如在POST消息体的后面放置一个CRLF符）。而据我所知，大部分浏览器在POST消息体后都会自动跟一个CRLF符再发送，如何解决这个问题呢？根据上面的说明在POST请求头中禁止使用Keep-Alive，或者由服务器自动忽略这个CRLF，大部分服务器都会自动忽略，但是在未经测试之前是不可能知道一个服务器是否会这样做。

一些容易犯的误区：

HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）
从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接
Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间

section 03 Apache中Keep-Alive配置建议

在 Apache 服务器中，Keep-Alive 是一个布尔值，On 代表打开，Off 代表关闭，这个指令在其他众多的 HTTPD 服务器中都是存在的。

Keep-Alive 配置指令决定当处理完用户发起的 HTTP 请求后是否立即关闭 TCP 连接，如果 Keep-Alive 设置为On，那么用户完成一次访问后，不会立即断开连接，如果还有请求，那么会继续在这一次 TCP 连接中完成，而不用重复建立新的 TCP 连接和关闭TCP 连接，可以提高用户访问速度。

那么我们考虑3种情况：
1. 用户浏览一个网页时，除了网页本身外，还引用了多个 javascript 文件，多个 css 文件，多个图片文件，并且这些文件都在同一个 HTTP 服务器上。
2. 用户浏览一个网页时，除了网页本身外，还引用一个 javascript 文件，一个图片文件。
3. 用户浏览的是一个动态网页，由程序即时生成内容，并且不引用其他内容。
对于上面3中情况，我认为：1 最适合打开 Keep-Alive ，2 随意，3 最适合关闭 Keep-Alive

下面我来分析一下原因。

在 Apache 中，打开和关闭 Keep-Alive 功能，服务器端会有什么异同呢？

先看看理论分析。

打开 Keep-Alive 后，意味着每次用户完成全部访问后，都要保持一定时间后才关闭会关闭 TCP 连接，那么在关闭连接之前，必然会有一个Apache 进程对应于该用户而不能处理其他用户，假设 Keep-Alive 的超时时间为 10 秒种，服务器每秒处理 50个独立用户访问，那么系统中 Apache 的总进程数就是 10 * 50 ＝ 500 个，如果一个进程占用 4M 内存，那么总共会消耗 2G内存，所以可以看出，在这种配置中，相当消耗内存，但好处是系统只处理了 50次 TCP 的握手和关闭操作。

如果关闭 Keep-Alive，如果还是每秒50个用户访问，如果用户每次连续的请求数为3个，那么 Apache 的总进程数就是 50 * 3= 150 个，如果还是每个进程占用 4M 内存，那么总的内存消耗为 600M，这种配置能节省大量内存，但是，系统处理了 150 次 TCP的握手和关闭的操作，因此又会多消耗一些 CPU 资源。

再看看实践的观察。

我在一组大量处理动态网页内容的服务器中，起初打开 Keep-Alive功能，经常观察到用户访问量大时Apache进程数也非常多，系统频繁使用交换内存，系统不稳定，有时负载会出现较大波动。关闭了 Keep-Alive功能后，看到明显的变化是： Apache 的进程数减少了，空闲内存增加了，用于文件系统Cache的内存也增加了，CPU的开销增加了，但是服务更稳定了，系统负载也比较稳定，很少有负载大范围波动的情况，负载有一定程度的降低；变化不明显的是：访问量较少的时候，系统平均负载没有明显变化。

总结一下：

在内存非常充足的服务器上，不管是否关闭 Keep-Alive 功能，服务器性能不会有明显变化；

如果服务器内存较少，或者服务器有非常大量的文件系统访问时，或者主要处理动态网页服务，关闭 Keep-Alive 后可以节省很多内存，而节省出来的内存用于文件系统Cache，可以提高文件系统访问的性能，并且系统会更加稳定。

补充1：

关于是否应该关闭 Keep-Alive 选项，我觉得可以基于下面的一个公式来判断。

在理想的网络连接状况下，系统的 Apache 进程数和内存使用可以用如下公式表达：

HttpdProcessNumber = KeepAliveTimeout * TotalRequestPerSecond / Average(KeepAliveRequests)

HttpdUsedMemory = HttpdProcessNumber * MemoryPerHttpdProcess

换成中文：

总Apache进程数 = KeepAliveTimeout * 每秒种HTTP请求数 / 平均KeepAlive请求

Apache占用内存 = 总Apache进程数 * 平均每进程占用内存数

需要特别说明的是：

[平均Keep-Alive请求] 数，是指每个用户连接上服务器后，持续发出的 HTTP 请求数。当 Keep-AliveTimeout 等 0或者 Keep-Alive 关闭时，Keep-AliveTimeout 不参与乘的运算从上面的公式看，如果 [每秒用户请求]多，[Keep-AliveTimeout] 的值大，[平均Keep-Alive请求] 的值小，都会造成 [Apache进程数] 多和 [内存]多，但是当 [平均Keep-Alive请求] 的值越大时，[Apache进程数] 和 [内存] 都是趋向于减少的。

基于上面的公式，我们就可以推算出当平均Keep-Alive请求 <= Keep-AliveTimeout 时，关闭 Keep-Alive 选项是划算的，否则就可以考虑打开。

补充2: Keep-Alive 该参数控制Apache是否允许在一个连接中有多个请求，默认打开。但对于大多数论坛类型站点来说，通常设置为off以关闭该支持。

补充3: 如果服务器前跑有应用squid服务，或者其它七层设备,Keep-Alive On 设定要开启持续长连接

实际在前端有 squid 的情况下, Keep-Alive 很关键。记得 On

section 04 HTTP协议中的长连接与短连接

长连接与短连接
- 长连接：client方与server方先建立连接，连接建立后不断开，然后再进行报文发送和接收。这种方式下由于通讯连接一直存在。此种方式常用于P2P通信。
- 短连接：Client方与server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此方式常用于一点对多点通讯。C/S通信。
长连接与短连接的操作过程

短连接的操作步骤是：

建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

长连接的操作步骤是：

建立连接——数据传输...（保持连接）...数据传输——关闭连接

长连接与短连接的使用时机

短连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。每个TCP连接的建立都需要三次握手，每个TCP连接的断开要四次握手。

如果每次操作都要建立连接然后再操作的话处理速度会降低，所以每次操作后，下次操作时直接发送数据就可以了，不用再建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，频繁的socket创建也是对资源的浪费。

Web网站的http服务一般都用短连接，因为长连接对于服务器来说要耗费一定的资源。像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。试想如果都用长连接，而且同时用成千上万的用户，每个用户都占有一个连接的话，可想而知服务器的压力有多大。所以并发量大，但是每个用户又不需频繁操作的情况下需要短连接。

总之：长连接和短连接的选择要根据需求而定。

长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

HTTP协议长连接、短连接总结

长连接与短连接的不同主要在于client和server采取的关闭策略不同。短连接在建立连接以后只进行一次数据传输就关闭连接，而长连接在建立连接以后会进行多次数据数据传输直至关闭连接（长连接中关闭连接通过Connection：closed头部字段）。

二者关闭策略的不同，就产生了长连接的优点：
- 通过开启、关闭更少的TCP连接，节约CPU时间和内存
- 通过减少TCP开启引起的包的数目，降低网络阻塞。
二者所应用的具体场景不同。短连接多用于操作频繁、点对点的通讯，且连接数不能太多的情况。数据库的连接则采用长连接。