关于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的那些事

高可用 Keepalived

TCP 的keepalive

Nginx 的keepalive

HTTP的keepalive

最新文章

热门文章