关于Keepalive的那些事

Posted feixiangmanon

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于Keepalive的那些事相关的知识,希望对你有一定的参考价值。

服务端很多同学包括自己对keepalive理解不清晰,经常搞不清楚,TCP也有keepalive,HTTP也有keepalive,高可用也叫keepalive,经常混淆这几个概念。做下这几个概念的简述,尽管名字基本上是一样的,但是所表示意义和范畴却大相径庭。

高可用 Keepalived

Keepalived是一个基于VRRP协议来实现的服务高可用方案,可以利用其来避免IP单点故障。它的作用是检测服务器的状态,如果有一台服务器宕机,或出现故障,Keepalived将检测到,使用其他服务器代替该服务器的工作,当服务器工作正常后Keepalived自动将服务器加入到服务器群中。
Keepalived一般不会单独出现,而是与其它负载均衡技术(如lvs、haproxy、nginx)一起工作来达到集群的高可用。

一个简单的使用例子,将域名解析到一台负载均衡机器上,然后负载均衡反向代理到WEB机器上。中间的负载均衡只有一台,没法做到高可用,至少需要做到两台,那配置成两台机器之后,Keepalived就可以保证服务只有一个对外的虚拟IP,如果MASTER的负载均衡出现故障的时候,自动切换到BACKUP负载均衡上,服务不受任何影响。Keepalived来保证这些。

我们以前有过一套稍显复杂的服务配置,Keepalived给HAProxy提供高可用,然后HAProxy给Twemproxy提供高可用和负载均衡,Twemproxy给Redis集群提供高可用和负载均衡。提供负载均衡服务的基本都会保证高可用,我们使用最多的Nginx作为反向代理服务器的时候,就能保证web服务的高可用。

nginx+keepalived 搭建高可用的服务教程有很多。感兴趣的可以自己试下搭建。

TCP 的keepalive

TCP的keepalive主要目的是及时的释放服务器资源。
通过TCP协议客户端与服务器建立连接之后,如果客户端一直不发送数据,或者隔很长时间才发送一次数据,当连接很久没有数据传输时如何去确定对方还在线,到底是掉线了还是确实没有数据传输,连接是保持还是关闭,多长时间或者在什么样的机制下连接应该关闭释放资源。TCP的keepalive就是为了解决这个问题才引入的。
TCP的keepalive主要是三个参数来控制

tcp_keepalive_time 7200
心跳周期
tcp_keepalive_intvl 75
侦测包发送间隔
tcp_keepalive_probes 9
侦测包重试次数

解释下这个流程和参数。
客户端与服务器建立连接后,如果双方在tcp_keepalive_time(7200S)后,没有任何数据的传输,服务器就会每隔tcp_keepalive_intvl(75S)向客户端发送探测包,判断客户端的连接状态,大概包括客户端崩溃、强制关闭了应用、主机不可达等的异常状态。如果侦测包发送了tcp_keepalive_probes(9)次之后仍然没有收到客户端的回复(就是ack包),服务器就会认为这个连接已经不可用了,可以丢弃或者关闭了。

Nginx 的keepalive

TCP层已经有keepalive,为什么应用层的Nginx还需要keepalive?
我理解的是,使用TCP的keepalive的保证传输层连接的可用性,默认配置都是2小时的检测周期。Nginx的keepalive来保证应用层的连接的可用性。一个在第四层传输层上保证可用性,一个在第七层应用层上保证应用层协议连接的可用性。
有本书里面有提到:
为什么TCP keepalive不能替代应用层心跳?心跳除了说明应用程序还活着(进程还在,网络通畅),更重要的是表明应用程序还能正常工作。而TCP keepalive由操作系统负责探查,即便进程死锁或者阻塞,操作系统也会如常收发TCP keepalive信息,对方无法得知这一异常。

nginx keepalive跟TCP的配置基本一致,只不过名字不一样罢了。配置说明如下

so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt] 

so_keepalive=30m::10 表示开启tcp侦测,30分钟后无数据收发会发送侦测包,时间间隔使用系统默认的,发送10次侦测包。

HTTP的keepalive

HTTP的keepalive比较常见,就是将短链接变成长链接。短连接是每个请求响应,客户端和服务器都要新建一个连接,完成之后立即断开连接;当使用keepalive长连接时,客户端到服务器端的建立连接,响应完成后连接不断开,下次请求直接服用原来的连接,这样就避免了重复建立连接和断开连接的开销。

那么客户端和服务器端是怎么约定使用长连接通信还是短连接通信。
主要Connection头部

客户端请求长连接头部:Connection: keep-alive
服务端同意使用长连接的响应头部:Connection: keep-alive
两者缺一不可,如果服务器端不支持长连接:Connection: Close
如果是HTTP/1.1默认使用长连接,无论头部是不是 Connection: keep-alive

注意的点:
Connection只对当前的连接双方有效,并且Connection头部不向后传递,只标识自己的连接状态。
如果是多级代理又是什么流程?
技术图片
1客户端与代理服务器1建连的时候带了Connection: keep-alive,但是代理服务器1不支持长连接,回复了Connection: Close,所以使两者用短连接
2代理服务器1与代理服务器2建连的时候使用Connection: Close短连接,代理服务器2回复了Connection: Close,所以两者使用短连接
3代理服务器2与web机器建连的时候使用了Connection: keep-alive,web机器支持长连接,也回复了Connection: keep-alive,所以两者使用长连接

HTTP的keepalive是开发者最长遇到的,所以要格外注意。不是服务器要求使用长连接连接就是长连接,是需要双方都同意才能使用长连接通信。以前遇到过阿里云的SLB就不支持长连接,WEB服务器或者代理服务器跟SLB连接的都是短连接。

以上是关于关于Keepalive的那些事的主要内容,如果未能解决你的问题,请参考以下文章

关于 runtime.KeepAlive() 你知道多少?

聊聊 TCP 中的 KeepAlive 机制

求关于keepalive和heartbeat的详细解释?

关于操作系统TCP Keepalive功能使用的说明

关于WebSocket心跳的理解

keepalived入门之keepalive+nginx实例部署