详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive

这篇具有很好参考价值的文章主要介绍了详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

🌲 HTTP 的 Keep-Alive

🌲 TCP 的 Keepalive

🌲 最后总结

🌲 参考资料


详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive

TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗?

这是个好问题,应该有不少人都会搞混,因为这两个东西看上去太像了,很容易误以为是同一个东西。

事实上,这两个完全是两样不同东西,实现的层面也不同:

  • HTTP 的 Keep-Alive,是由应用层(用户态) 实现的,称为 HTTP 长连接;

  • TCP 的 Keepalive,是由 TCP 层(内核态) 实现的,称为 TCP 保活机制;

接下来,分别说说它们。

🌲 HTTP 的 Keep-Alive

HTTP 协议采用的是「请求-应答」的模式,也就是客户端发起了请求,服务端才会返回响应,一来一回这样子。

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive
请求-应答

由于 HTTP 是基于 TCP 传输协议实现的,客户端与服务端要进行 HTTP 通信前,需要先建立 TCP 连接,然后客户端发送 HTTP  请求,服务端收到后就返回响应,至此「请求-应答」的模式就完成了,随后就会释放 TCP 连接。

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive
一个 HTTP 请求

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

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive
HTTP 短连接

这样实在太累人了,一次连接只能请求一次资源。

能不能在第一个 HTTP 请求完后,先不断开 TCP 连接,让后续的 HTTP 请求继续使用此连接?

当然可以,HTTP 的 Keep-Alive 就是实现了这个功能,可以使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答,避免了连接建立和释放的开销,这个方法称为 HTTP 长连接

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive
HTTP 长连接

HTTP 长连接的特点是,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。

怎么才能使用 HTTP 的 Keep-Alive 功能?

在 HTTP 1.0 中默认是关闭的,如果浏览器要开启 Keep-Alive,它必须在请求的包头中添加:

Connection: Keep-Alive

然后当服务器收到请求,作出回应的时候,它也添加一个头在响应中:

Connection: Keep-Alive

这样做,连接就不会中断,而是保持连接。当客户端发送另一个请求时,它会使用同一个连接。这一直继续到客户端或服务器端提出断开连接。

从 HTTP 1.1 开始, 就默认是开启了 Keep-Alive,如果要关闭 Keep-Alive,需要在 HTTP 请求的包头里添加:

Connection:close

现在大多数浏览器都默认是使用 HTTP/1.1,所以 Keep-Alive 都是默认打开的。一旦客户端和服务端达成协议,那么长连接就建立好了。

HTTP 长连接不仅仅减少了 TCP 连接资源的开销,而且这给 HTTP 流水线技术提供了可实现的基础。

所谓的 HTTP 流水线,是客户端可以先一次性发送多个请求,而在发送过程中不需先等待服务器的回应,可以减少整体的响应时间。

注意!Keep-Alive为HTTP 流水线技术提供了可实现的基础,这个基础说的只是开启Keep-Alive,可以实现HTTP长连接(持久连接)。而实现HTTP流水线技术的是HTTP1.1引入的管道机制(Pipelining),管道机制允许客户端同时发出多个请求,然后服务端按照顺序响应。不要搞混了!参考资料:Keep-Alive和Pipelining

举例来说,客户端需要请求两个资源。以前的做法是,在同一个 TCP 连接里面,先发送 A 请求,然后等待服务器做出回应,收到后再发出 B 请求。HTTP 流水线机制则允许客户端同时发出 A 请求和 B 请求。

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive
右边为 HTTP 流水线机制

但是服务器还是按照顺序响应,先回应 A 请求,完成后再回应 B 请求。

而且要等服务器响应完客户端第一批发送的请求后,客户端才能发出下一批的请求,也就说如果服务器响应的过程发生了阻塞,那么客户端就无法发出下一批的请求,此时就造成了「队头阻塞」的问题。

可能有的同学会问,如果使用了 HTTP 长连接,如果客户端完成一个 HTTP 请求后,就不再发起新的请求,此时这个 TCP 连接一直占用着不是挺浪费资源的吗?

对没错,所以为了避免资源浪费的情况,web 服务软件一般都会提供 keepalive_timeout 参数,用来指定 HTTP 长连接的超时时间。

比如设置了 HTTP 长连接的超时时间是 60 秒,web 服务软件就会启动一个定时器,如果客户端在完后一个 HTTP 请求后,在 60 秒内都没有再发起新的请求,定时器的时间一到,就会触发回调函数来释放该连接。

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive
HTTP 长连接超时

🌲 TCP 的 Keepalive

TCP 的 Keepalive 这东西其实就是 TCP 的保活机制,它的工作原理,我之前的文章也讲解过,在这里我们重新温习一下:

定义一个时间段,在这个时间段内,如果没有任何连接相关的活动,TCP 保活机制会开始作用,每隔一个时间间隔,发送一个「探测报文」,该探测报文包含的数据非常少,如果连续几个探测报文都没有得到响应,则认为当前的 TCP 连接已经死亡,系统内核将错误信息通知给上层应用程序。

在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔,以下都为默认值:

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9
  • tcp_keepalive_time=7200:表示保活时间是 7200 秒(2小时),也就 2 小时内如果没有任何连接相关的活动,则会启动保活机制

  • tcp_keepalive_intvl=75:表示每次检测间隔 75 秒;

  • tcp_keepalive_probes=9:表示检测 9 次无响应,认为对方是不可达的,从而中断本次的连接。

也就是说在 Linux 系统中,最少需要经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接。

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive

如果两端的 TCP 连接一直没有数据交互,达到了触发 TCP 保活机制的条件,那么内核里的 TCP 协议栈就会发送探测报文。

  • 如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应,这样 TCP 保活时间会被重置,等待下一个 TCP 保活时间的到来。

  • 如果对端主机崩溃,或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后,石沉大海,没有响应,连续几次,达到保活探测次数后,TCP 会报告该 TCP 连接已经死亡

注:在探测过程中,对端主机会处于以下四种状态之一:

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive

所以,TCP 保活机制可以在双方没有数据交互的情况,通过探测报文,来确定对方的 TCP 连接是否存活,这个工作是在内核完成的。

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive
TCP 保活机制

注意,应用程序若想使用 TCP 保活机制需要通过 socket 接口设置 SO_KEEPALIVE 选项才能够生效,如果没有设置,那么就无法使用 TCP 保活机制。

🌲 最后总结

HTTP 的 Keep-Alive 也叫 HTTP 长连接,该功能是由「应用程序」实现的,可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答,减少了 HTTP 短连接带来的多次 TCP 连接建立和释放(销毁)的开销。

TCP 的 Keepalive 也叫 TCP 保活机制,该功能是由「内核」实现的,当客户端和服务端长达一定时间没有进行数据交互时,内核为了确保该连接是否还有效,就会发送探测报文,来检测对方是否还在线,然后来决定是否要关闭该连接。

🌲 参考资料

| 实战——我用“大白鲨”让你看见 TCP | TCP、HTTP中的保活机制keep-alive |

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive 

详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive,TCP/IP | OSI模型,# TCP,# HTTP,网络,tcp/ip,服务器,Keep-Alive,Keepalive文章来源地址https://www.toymoban.com/news/detail-657211.html

到了这里,关于详解TCP、HTTP中的保活机制 | Keepalive和Keep-Alive的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 网络协议--TCP的保活定时器

    许多TCP/IP的初学者会很惊奇地发现可以没有任何数据流通过一个空闲的TCP连接。也就是说,如果TCP连接的双方都没有向对方发送数据,则在两个TCP模块之间不交换任何信息。例如,没有可以在其他网络协议中发现的轮询。这意味着我们可以启动一个客户与服务器建立一个连接

    2024年02月06日
    浏览(40)
  • SO_KEEPALIVE、TCP_KEEPIDLE、TCP_KEEPINTVL、保活包

    SO_KEEPALIVE 是一个套接字选项,用于设置是否启用 keepalive 机制。在这段代码中没有涉及到 SO_KEEPALIVE 选项的设置。 当 SO_KEEPALIVE 被设置为非零值时,表示启用 keepalive 机制。keepalive 是一种用于检测连接是否仍然有效的机制。通过定期发送一些特定的探测数据,可以检测到网络

    2024年02月14日
    浏览(39)
  • Unity-TCP-网络聊天功能(四): 消息粘包、心跳机制保活(心跳包)、断线重连

    bug1:下线后,如果发送多条消息,在客户端上线时,一瞬间接收到,效果如同粘包,需要拆包。举例,连续发送三条160长度消息,可能实际显示2条消息,原因,第三条消息和第二条消息粘包,第二条消息长度变为320,但是Receive方法没有考虑这个问题,相当于这段代码只运行

    2024年02月11日
    浏览(38)
  • java.net.SocketTimeoutException: Read timed out,tcp连接心跳[TCP Keep-Alive],socket模拟http

     读超时con.setReadTimeout(3 * 60 * 60 * 1000);已设置为3小时。 日志 日志发现 等待了 3小时,抛出了异常 经过排查,是因为 后端防火墙,连接空闲20分钟,连接就会被丢弃。 解决办法是,使用 socket.setKeepAlive(true); 注意HttpURLConnection的connection.setRequestProperty(\\\"Connection\\\", \\\"keep-alive\\\");是不

    2024年02月07日
    浏览(37)
  • HTTP协议Keep-Alive模式详解和HTTP头字段总结

    1、什么是Keep-Alive模式? 我们知道HTTP协议采用“请求-应答”模式,当使用普通模式,即非KeepAlive模式时,每个请求/应答客户和服务器都要新建一个连接,完成 之后立即断开连接(HTTP协议为无连接的协议);当使用Keep-Alive模式(又称持久连接、连接重用)时,Keep-Alive功能使

    2024年02月06日
    浏览(40)
  • Android后台驻留:保活和回收的机制

    众所周知,Android平台的管理机制下,App进入后台后,为了提供持续的及时服务(如推送、音乐),或进行驻留获取收益(跟踪、信息收集、广告)等,会利用一些方法来让自身保持活跃,躲过被Android系统或用户发觉、清理,实现后台驻留。 其中,后台驻留的广义概念,除了

    2024年02月07日
    浏览(50)
  • TCP keepalive

    TCP keepalive - 小不的笔记 TCP是面向连接的。创建一个TCP连接,客户端和服务端需要经历三次握手,一旦建立它的期限就是 永久 ,除非其中一方发起关闭。 理想状态下,客户端与服务端建立连接就可以一直用下去,但是在真实的互联网世界没有这么理想: NAT网关、防火墙、代理

    2024年02月12日
    浏览(33)
  • TCP长连接的连接池、容量控制与心跳保活

    TCP 本身并没有长短连接的区别,长短与否,完全取决于我们怎么用它。 短连接:每次通信时,创建 Socket;一次通信结束,调用 socket.close()。这就是一般意义上的短连接,短连接的好处是管理起来比较简单,存在的连接都是可用的连接,不需要额外的控制手段。 长连接:每次

    2023年04月23日
    浏览(32)
  • TCP详解之重传机制

    TCP 实现可靠传输的方式之一,是通过序列号与确认应答。 在 TCP 中,当发送端的数据到达接收主机时,接收端主机会返回一个确认应答消息,表示已收到消息。 但在错综复杂的网络,并不一定能如上图那么顺利能正常的数据传输,万一数据在传输过程中丢失了呢?所以TCP针

    2024年02月04日
    浏览(31)
  • TCP重传机制详解——02SACK

    Selective Acknowledgment有选择的ACK,显而易见这是在ACK的基础上的扩展。在ACK包上会携带SACK选项,表示一个接收范围,也称之为\\\"空洞\\\"。 传统的TCP在丢包时会采用超时重传的方式,即等待一段时间后重传丢失的数据段。而使用SACK机制,接收端可以选择性地向发送端反馈已经成功

    2024年04月29日
    浏览(29)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包