Netty 心跳检测机制_super.usereventtriggered

心跳检测机制

目的：就是用于检测 检测通信对方是否还"在线"，如果已经断开，就要释放资源 或者 尝试重连。

大概的实现原理就是：在服务器和客户端之间一定时间内没有数据交互时, 即处于 idle 状态时, 客户端或服务器会发送一个特殊的数据包给对方, 当接收方收到这个数据报文后, 也立即发送一个特殊的数据报文, 回应发送方, 此即一个 PING-PONG 交互。双方都可以知道连接的有效性。

我们可以通过两种方式实现心跳机制:

• 使用 TCP 协议层面的 keepalive 机制。

• 在应用层上实现自定义的心跳机制(就是，自己编写程序，规定双方心跳交互的规则)。

但是，大部分都是在应用层自己实现这个机制。

应用层实现心跳机制好处：

• 一是灵活, 应用层心跳规则可以自由定义，可实现各时间间隔（秒级、毫秒级）的检测，包里还可以携带额外的信息。
• 二是通用, 应用层的心跳规则不依赖于底层协议。如果后期想把TCP改为UDP，协议层不提供心跳机制了，但应用层的心跳依旧是通用的。

TCP协议的 KeepAlive 机制

TCP 长连接

在 TCP 协议层面上, 提供了 keepalive 机制, 用于检测 TCP 连接的死活。

tcp-keepalive 机制，由操作系统内核实现；

默认不开启, 需要自行开启。

开启之后有三个参数会生效，来决定一个 keepalive 的行为：

net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
1
2
3

tcp_keepalive_time： 在 TCP 保活打开的情况下，最后一次数据交换到 TCP 发送第一个保活探测包的间隔，即允许的持续空闲时长，或者说每次正常发送心跳的周期，默认值为7200s（2 小时）；

tcp_keepalive_probes： 在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包次数，默认值为 9（次）；

tcp_keepalive_intvl：在 tcp_keepalive_time 之后，没有接收到对方确认，继续发送保活探测包的发送频率，默认值为 75s。

修改系统 tcp-keepalive 参数配置

Linux环境下，修改/etc/sysctl.conf文件

# 表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是7200秒（2小时），改为5秒钟。
net.ipv4.tcp_keepalive_time = 5

# 如果对方不予应答，探测包的发送次数
net.ipv4.tcp_keepalive_probes = 5

# 探测消息发送的频率
net.ipv4.tcp_keepalive_intvl = 1
1
2
3
4
5
6
7
8

使用场景

比如 HTTP/1.0 通过在 header 头中添加 Connection:Keep-Alive参数，如果当前请求需要保活则添加该参数作为标识，否则服务端就不会保持该连接的状态，发送完数据之后就关闭连接。

HTTP/1.1 以后 Keep-Alive 是默认打开的。

比如 监控系统，IM系统，即时报价系统，推送服务等等。像这些场景都是比较注重实时性，如果每次发送数据都要进行一次DNS解析，建立连接的过程肯定是极其影响体验。

TCP keepalive 的缺点

1. 首先，它不是 TCP 的标准协议, 并且是默认关闭的。

2. TCP keepalive 机制依赖于操作系统的实现, 默认的 keepalive 心跳时间是 2个小时, 并且对 keepalive 的修改需要系统调用(或者修改系统配置), 灵活性不够。

3. TCP keepalive 与 TCP 协议绑定, 因此如果需要更换为 UDP 协议时, keepalive 机制就失效了。

4. TCP KeepAlive 仅限于 检测连接的死活。

   例如：某台服务器因为某些原因导致负载超高，CPU 100%，无法响应任何业务请求，但是使用 TCP 探针则仍旧能够确定连接状态，这就是典型的连接活着但业务提供方已死的状态，对客户端而言，这时的最好选择就是断线后重新连接其他服务器，而不是一直认为当前服务器是可用状态一直向当前服务器发送些必然会失败的请求。

Netty 提供了 tcp-keepalive 的设置

// 主从线程池
NioEventLoopGroup bossGroup 
1