Apr 20

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

felix021 @ 2012-4-20 01:12 [IT » 网络] 评论(9) , 引用(0) , 阅读(33448) | Via 本站原创 | |
很多应用层协议都有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 多线程服务端编程》”

转载请注明出自 ,如是转载文则注明原出处,谢谢:)
RSS订阅地址: http://www.felix021.com/blog/feed.php
xx
2017-9-28 17:11
lovelovelovelovelovelovelovelovelovelovelove
tttttttttttttttttt
2017-9-28 17:10
dogcrybad
老虎油
2016-7-26 10:30
tcp确认对方掉线了,会有什么反馈?
felix021 回复于 2016-7-28 10:56
没有验证过,不过我猜,由于对方是掉线,所以没有机会发出RST包,本地在超时以后会通知上层应用,recv调用失败,errno可能被设置为EBADF之类的吧。
Jack Email Homepage
2015-9-10 22:24
心跳除了说明应用程序还活着(进程还在,网络通畅),更重要的是表明应用程序还能正常工作。而 TCP keepalive 有操作系统负责探查,即便进程死锁,或阻塞,操作系统也会如常收发 TCP keepalive 消息。对方无法得知这一异常。摘自《Linux 多线程服务端编程》,给博主参考。smile
felix021 回复于 2015-9-14 16:30
赞,非常感谢~
pjiamu
2014-3-14 19:36
1.KeepAlive机制很多情况无法检测出来,如网络连接被软件禁用等,不够可靠,网络状态复杂的情况下这种情况尤其严重。2.自己实现心跳可以加入更灵活与实用的机制,比如少了一个心跳,可以马上再次检查,检查间隔递减,这样可以更快的感知网络状态,而不是等待固定的时间。
felix021 回复于 2014-3-17 10:33
多谢指教
107x@163.com
2013-2-19 14:43
以下是一篇关于socket通信的文章,连接老是发不了,看的时候把 - 去掉即可
107x@163.com
2013-2-19 14:39
http://www.cnblogs.com/d-i-y-un-p-e-ng/ar-c-h-ive/2011/07/21/2112380.html
107x@163.com
2013-2-19 14:30
应用级别的心跳优点在于它们能够使你了解两端的应用都是否存活,而不在于只是通信软件.
lovelucy Email Homepage
2012-4-20 14:05
TCP 的 keep alive 非常耗费资源。一般来说服务器的CPU计算资源远比内存和IO多,所以我看到很多web服务器都把keep alive设得很低,这样在有需要时重新建立连接,消耗CPU以求得更多可以使用的内存。可能和你说的不是一个东西……
felix021 回复于 2012-4-20 14:40
问题是,比起底层的协议来说,在应用层实现的心跳肯定更耗资源啊。所以我觉得关键是,耗这个资源有没有必要;如果耗了资源,怎样尽量提高被消耗资源的利用率,对吧。
分页: 1/1 第一页 1 最后页
发表评论
表情
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
打开HTML
打开UBB
打开表情
隐藏
记住我
昵称   密码   *非必须
网址   电邮   [注册]