TCP keepalive 和 http keep-alive 以及心跳保活

HTTP的长连接和短连接本质上是TCP长连接和短连接。

短连接
短连接,顾名思义,与长连接的区别就是,客户端收到服务端的响应后,立刻发送FIN消息,主动释放连接。也有服务端主动断连的情况,凡是在一次消息交互(发请求-收响应)之后立刻断开连接的情况都称为短连接。

长连接/http keep-alive
也叫持久连接,即一个TCP连接服务多次请求,在TCP层握手成功后,不立即断开连接,并在此连接的基础上进行多次消息(包括心跳)交互,直至连接的任意一方(客户端OR服务端)主动断开连接,此过程称为一次完整的长连接。

在HTTP/1.0中得到了初步的支持,客户端在请求header中携带Connection:Keep-Alive,即是在向服务端请求持久连接。如果服务端接受持久连接,则会在响应header中同样携带Connection: Keep-Alive,这样客户端便会继续使用同一个TCP连接发送接下来的若干请求。(Keep-Alive的默认参数是[timout=5, max=100],即一个TCP连接可以服务至多5秒内的100次请求)

HTTP/1.1开始,即使请求header中没有携带Connection: Keep-Alive,传输也会默认以持久连接的方式进行,只有加入"Connection: close "后,才关闭。

http keepalive是客户端浏览器与服务端httpd守护进程协作的结果。

TCP中的KeepAlive
  TCP协议的实现中,提供了KeepAlive报文,用来探测连接的对端是否存活。在应用交互的过程中,可能存在以下几种情况:

客户端或服务器意外断电,死机,崩溃,重启;

中间网络已经中断,而客户端与服务器并不知道;

利用保活探测功能,可以探知这种对端的意外情况,从而保证在意外发生时,可以释放半打开的TCP连接。TCP保活报文交互过程如下:


image.png

有了TCP提供了KeepAlive机制, 为什么还需要应用层的心跳保活:

  • (1) Keep Alive机制开启后,TCP层将在定时时间到后发送相应的KeepAlive探针以确定连接可用性。默认时间为7200s(两小时),失败后重试10次,每次超时时间75s。显然默认值无法满足移动网络下的需求;

  • (2) 即便修改了(1)中的默认值,也不能很好的满足业务需求。TCP的KeepAlive用于检测连接的死活而不能检测通讯双方的存活状态。比如某台服务器因为某些原因导致负载超高,无法响应任何业务请求,但是使用TCP探针则仍旧能够确定连接状态,这就是典型的连接活着但业务提供方已死的状态,对客户端而言,这时的最好选择就是断线后重新连接其他服务器,而不是一直认为当前服务器是可用状态,一直向当前服务器发送些必然会失败的请求。

  • (3) socks代理会让Keep Alive失效。socks协议只管转发TCP层具体的数据包,而不会转发TCP协议内的实现细节的包。所以,一个应用如果使用了socks代理,那么TCP的KeepAlive机制就失效了。

  • (4) 部分复杂情况下Keep Alive会失效,如路由器挂掉,网线直接被拔除等;

因此,KeepAlive并不适用于检测双方存活的场景,这种场景还得依赖于应用层的心跳。应用层心跳也具备着更大的灵活性,可以控制检测时机,间隔和处理流程,甚至可以在心跳包上附带额外信息。

影响心跳频率的关键因素

应用层心跳是检测连接有效性以及判断双方是否存活的有效方式。但是心跳过于频繁会带来耗电和耗流量的弊病,心跳频率过低则会影响连接检测的实时性。业内关于心跳时间的设置和优化,主要基于如下几个因素:

  • 1.NAT超时–大部分移动无线网络运营商在链路一段时间没有数据通讯时,会淘汰 NAT表中的对应项,造成链路中断;
  • 2.DHCP租期–DHCP租期到了需要主动续约,否则会继续使用过期IP导致长连接偶然的断连;
  • 3.网络状态变化–手机网络和WIFI网络切换、网络断开和连上等情况有网络状态的变化,也会使长连接变为无效连接;

理想的情况下,客户端应当以略小于NAT超时时间的间隔来发送心跳包。根据微信团队测试的一些数据,一些常用网络的NAT超时时间如下表所示:

image.png

Tcp keepAlive 和Http中Keep-Alive的关系
HTTP协议的Keep-Alive意图在于连接复用,同一个连接上串行方式传递请求-响应数据

TCP的KeepAlive机制意图在于保活、心跳,检测连接错误

如何快速区分当前连接使用的是长连接还是短连接
1、凡是在一次完整的消息交互(发请求-收响应)之后,立刻断开连接(有一方发送FIN消息)的情况都称为短连接;

2、长连接的一个明显特征是会有心跳消息(也有没有心跳的情况),且一般心跳间隔都在30S或者1MIN左右,用wireshark抓包可以看到有规律的心跳消息交互(可能会存在毫秒级别的误差)。

什么时候用长连接,短连接?
1、需要频繁交互的场景使用长连接,如即时通信工具(微信/QQ,QQ也有UDP),相反则使用短连接,比如普通的web网站,只有当浏览器发起请求时才会建立连接,服务器返回相应后,连接立即断开。

2、维持长连接会有一定的系统开销,用户量少不容易看出系统瓶颈,一旦用户量上去了,就很有可能把服务器资源(内存/CPU/网卡)耗尽,所以使用需谨慎。

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

短连接和长链接 图:


image.png

参考:https://caofengbin.github.io/2018/03/16/dhcp-and-nat/#4-%E5%BD%B1%E5%93%8D%E5%BF%83%E8%B7%B3%E9%A2%91%E7%8E%87%E7%9A%84%E5%85%B3%E9%94%AE%E5%9B%A0%E7%B4%A0

https://blog.csdn.net/hengyunabc/article/details/44310193

http://wingjay.com/2018/12/05/android-arch-long-link/

https://www.levicc.com/2018/06/30/yi-dong-duan-wang-luo-you-hua/

能被我参考的都很优秀,哈哈

你可能感兴趣的:(TCP keepalive 和 http keep-alive 以及心跳保活)