很多人都知道TCP并不会去主动检测连接的丢失，这意味着，如果双方不产生交互，那么如果网络断了或者有一方机器崩溃，另外一方将永远不知道连接已经不可用了。检测连接是否丢失的方法大致有两种：keepalive和heart-beat。
Keepalive是很多的TCP实现提供的一种机制，它允许连接在空闲的时候双方会发送一些特殊的数据段，并通过响应与否来判断连接是否还存活着（所谓keep~~alive）。我曾经写过一篇关于keepalive的blog，但后来我也发现，其实keepalive在实际的应用中并不常见。为何如此？这得归结于keepalive设计的初衷。Keepalive适用于清除死亡时间比较长的连接。
比如这样的场景：一个用户创建tcp连接访问了一个web服务器，当用户完成他执行的操作后，很粗暴的直接拨了网线。这种情况下，这个tcp连接已经断开了，但是web服务器并不知道，它会依然守护着这个连接。如果web server设置了keepalive，那么它就能够在用户断开网线的大概几个小时以后，确认这个连接已经中断，然后丢弃此连接，回收资源。
采用keepalive，它会先要求此连接一定时间没有活动（一般是几个小时），然后发出数据段，经过多次尝试后（每次尝试之间也有时间间隔），如果仍没有响应，则判断连接中断。可想而知，整个周期需要很长的时间。
所以，如前面的场景那样，需要一种方法能够清除和回收那些在系统不知情的情况下死去了很久的连接，keepalive是非常好的选择。
但是，在大部分情况下，特别是分布式环境中，我们需要的是一个能够快速或者实时监控连接状态的机制，这里，heart-beat才是更加合适的方案。
Heart-beat（心跳），按我的理解，它的原理和keepalive非常类似，都是发送一个信号给对方，如果多次发送都没有响应的话，则判断连接中断。它们的不同点在于，keepalive是tcp实现中内建的机制，是在创建tcp连接时通过设置参数启动keepalive机制；而heart-beat则需要在tcp之上的应用层实现。一个简单的heart-beat实现一般测试连接是否中断采用的时间间隔都比较短，可以很快的决定连接是否中断。并且，由于是在应用层实现，因为可以自行决定当判断连接中断后应该采取的行为，而keepalive在判断连接失败后只会将连接丢弃。
关于heart-beat，一个非常有趣的问题是，应该在传输真正数据的连接中发送“心跳”信号，还是可以专门创建一个发送“心跳”信号的连接。比如说，A，B两台机器之间通过连接m来传输数据，现在为了能够检测A，B之间的连接状态，我们是应该在连接m中传输“心跳”信号，还是创建新的连接n来专门传输“心跳”呢？我个人认为两者皆可。如果担心的是端到端的连接状态，那么就直接在该条连接中实现“心跳”。但很多时候，关注的是网络状况和两台主机间的连接状态，这种情况下， 创建专门的“心跳”连接也未尝不可。
原文地址:http://blog.csdn.net/historyasamirror/archive/2011/05/14/6419916.aspx