最后更新:3年前 手机定位技术交流文章
一个读者以前问过我以下问题:

一般的问题是,TCP Keepalive和HTTP Keep-Alive是件东西吗?
这是一个好问题,许多人应该混淆,因为这两个东西看起来太相似,很容易把它们误认为是相同的。
事实上,这是两个完全不同的事,而且实现的水平也不同:
接下来,分别谈谈它们。
HTTP协议使用请求-响应模式,这意味着客户端启动请求,服务器返回响应,一次一次。

请求-应答
由于HTTP基于TCP传输协议,在客户端和服务端能够通信HTTP之前,你需要先建立一个TCP连接,然后客户端发送一个HTTP请求,服务端接收响应并返回它,所以请求-响应模式已经完成,TCP连接被释放。

HTTP请求
如果每次请求都要经历这样的过程:建立 TCP -> 请求资源 -> 响应资源 -> 释放连接,那么此方式就是HTTP 短连接,如下图:

HTTP 短连接
太无聊了,一个连接只要求一个资源。
能不能在第HTTP请求完后,先不断开 TCP 连接,让后续的 HTTP 请求继续使用此连接?
当然可以,HTTP Keep-Alive 就是实现了这个功能,可以使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答,避免了连接建立和释放的开销,这个方法称为HTTP 长连接。

HTTP 长连接
HTTP长连接的特征是,只要任何端不明确要求切断,它们都保持TCP连接状态。
怎么才能使用 HTTP Keep-Alive 功能?
在HTTP1中,如果浏览器想打开Keep-Alive,它必须被添加到请求的包标题:
Connection: Keep-Alive
然后当服务器接收一个请求并响应时,它还添加一个头条到响应中:
Connection: Keep-Alive
这样,连接不会被中断,而是保持。 当客户端发送另一个请求时,它使用同样的连接。
从HTTP 1.1起,Keep-Alive是默认的启用,如果你想关闭Keep-Alive,你需要将其添加到HTTP请求的包头:
Connection:close
大多数浏览器现在默认使用HTTP/1,所以Keep-Alive默认是开放的。
长期的HTTP连接不仅降低了TCP连接资源的成本,而且为HTTP流线技术提供了可行的基础。
所谓的HTTP流线允许客户端同时发送多个请求,而不等待服务器的响应,从而减少响应时间。
举例来说,客户需要请求两个资源。以前的做法是,在同一的TCP连接中,先发送 A 请求,然后等待服务器响应,请求B在收到后发出.HTTP流线机制允许客户端同时发送A和B请求。

右边HTTP流线机制
然而,服务器在序列中响应,首先响应请求A,然后响应请求B。
此外,等待服务器响应客户端发送的第一个请求集之前,客户端可以发送下一个请求集意味着,如果服务器的响应过程被封锁,客户端不能发送下一个请求集。
可能有的同学会问,如果使用了 HTTP 长连接,如果客户端完成HTTP请求后,就不再发起新的请求,此时这个 TCP 连接一直占用着不是挺浪费资源的吗?
是的,因此为了避免浪费资源,Web服务软件通常提供一个 maintenance_timeout参数来指定HTTP长期连接的加班时间。
例如,如果您设置HTTP长连接为60秒超时,网络服务软件将启动一个计时器,如果客户端在完后HTTP请求后,在60秒内,没有新的请求被启动。定时器的时间一到,这触发了调用函数释放连接.

HTTP长连接超时
TCP的存活者 这东西其实就是TCP 的保活机制,它的工作原理我之前的文章写过,这里就直接贴下以前的内容。

如果两个端之间的TCP连接没有数据交互,并满足启动TCP备份机制的条件,则内核中的TCP协议堆栈发送检测消息。
因此,TCP备份机制可以通过在两个实体之间没有数据交互的情况下检测消息来确定对方的TCP连接是否存在,这是在内核中进行的。

TCP 保活机制
注意,如果应用程序想要使用TCP备份机制,则必须通过插座接口设置SO_KEEPALIVE选项才能生效。如果它没有设置,则不能使用TCP备份机制。
HTTP Keep-Alive 也叫 HTTP 长连接,该函数由应用程序实现,允许使用相同的TCP连接发送和接收多个HTTP请求/响应,减少由HTTP短途连接产生的多个TCP连接的创建和释放成本。
TCP的存活者 也叫 TCP 保活机制,这个函数由内核实现,当客户和服务端在一定时间内与数据不交互时,为了确保连接仍然有效,就会发送探测报文,检查对方是否还在网上,然后决定是否关闭连接。
原文链接:
https://mp.weixin.qq.com/s/25atTs4b-vORIx525ur_aw作者:小林编码
如果你觉得这篇文章对你有帮助的话,你可以把注意力转向支持它
本文由 在线网速测试 整理编辑,转载请注明出处。