闲说HeartBeat心跳包和TCP协议的KeepAlive机制

不少应用层协议都有HeartBeat机制，一般是客户端每隔一小段时间向服务器发送一个数据包，通知服务器本身仍然在线，并传输一些可能必要的数据。使用心跳包的典型协议是IM，好比QQ/MSN/飞信等协议。

学过TCP/IP的同窗应该都知道，传输层的两个主要协议是UDP和TCP，其中UDP是无链接的、面向packet的，而TCP协议是有链接、面向流的协议。

因此很是容易理解，使用UDP协议的客户端（例如早期的“OICQ”，据说OICQ.com这两天被抢注了来着，好古老的回忆）须要定时向服务器发送心跳包，告诉服务器本身在线。

然而，MSN和如今的QQ每每使用的是TCP链接了，尽管TCP/IP底层提供了可选的KeepAlive（ACK-ACK包）机制，可是它们也仍是实现了更高层的心跳包。彷佛既浪费流量又浪费CPU，有点莫名其妙。

具体查了下，TCP的KeepAlive机制是这样的，首先它貌似默认是不打开的，要用setsockopt将SOL_SOCKET.SO_KEEPALIVE设置为1才是打开，而且能够设置三个参数tcp_keepalive_time/tcp_keepalive_probes/tcp_keepalive_intvl，分别表示链接闲置多久开始发keepalive的ack包、发几个ack包不回复才当对方死了、两个ack包之间间隔多长，在我测试的Ubuntu Server 10.04下面默认值是7200秒（2个小时，要不要这么蛋疼啊！）、9次、75秒。因而链接就了有一个超时时间窗口，若是链接之间没有通讯，这个时间窗口会逐渐减少，当它减少到零的时候，TCP协议会向对方发一个带有ACK标志的空数据包（KeepAlive探针），对方在收到ACK包之后，若是链接一切正常，应该回复一个ACK；若是链接出现错误了（例如对方重启了，链接状态丢失），则应当回复一个RST；若是对方没有回复，服务器每隔intvl的时间再发ACK，若是连续probes个包都被无视了，说明链接被断开了。

这里有一篇很是详细的介绍文章： http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO ，包括了KeepAlive的介绍、相关内核参数、C编程接口、如何为现有应用（能够或者不能够修改源码的）启用KeepAlive机制，很值得详读。

这篇文章的2.4节说的是“Preventing disconnection due to network inactivity”，阻止因网络链接不活跃（长时间没有数据包）而致使的链接中断，说的是，不少网络设备，尤为是NAT路由器，因为其硬件的限制（例如内存、CPU处理能力），没法保持其上的全部链接，所以在必要的时候，会在链接池中选择一些不活跃的链接踢掉。典型作法是LRU，把最久没有数据的链接给T掉。经过使用TCP的KeepAlive机制（修改那个time参数），可让链接每隔一小段时间就产生一些ack包，以下降被T掉的风险，固然，这样的代价是额外的网络和CPU负担。

前面说到，许多IM协议实现了本身的心跳机制，而不是直接依赖于底层的机制，不知道真正的缘由是什么。

就我看来，一些简单的协议，直接使用底层机制就能够了，对上层彻底透明，下降了开发难度，不用管理链接对应的状态。而那些本身实现心跳机制的协议，应该是指望经过发送心跳包的同时来传输一些数据，这样服务端能够获知更多的状态。例如某些客户端很喜欢收集用户的信息……反正是要发个包，不如再塞点数据，不然包头又浪费了……

大概就是这样吧，若是有大牛知道真正的缘由，还望不吝赐教。


@2012-04-21 

p.s. 经过咨询某个作过IM的同事，参考答案应该是，本身实现的心跳机制通用，能够无视底层的UDP或TCP协议。若是只是用TCP协议的话，那么直接使用KeepAlive机制就足够了。

@2015-09-14
补充一下 @Jack的回复：
“心跳除了说明应用程序还活着（进程还在，网络通畅），更重要的是代表应用程序还能正常工做。而 TCP keepalive 有操做系统负责探查，即使进程死锁，或阻塞，操做系统也会如常收发 TCP keepalive 消息。对方没法得知这一异常。摘自《Linux 多线程服务端编程》”

1.KeepAlive机制不少状况没法检测出来，如网络链接被软件禁用等，不够可靠，网络状态复杂的状况下这种状况尤为严重。2.本身实现心跳能够加入更灵活与实用的机制，好比少了一个心跳，能够立刻再次检查，检查间隔递减，这样能够更快的感知网络状态，而不是等待固定的时间。

--

 

转载请注明出自 http://www.felix021.com/blog/read.php?2076 ，如是转载文则注明原出处，谢谢:)