TCP keepalive机制

首先，我想说的是，SO_Keeplive是实现在服务器侧，客户端被动响应，缺省超时时间为120分钟，这是RFC协议标准规范。SO_Keeplive是实现在TCP协议栈（四层），应用层的心跳实现在第七层，本质没有任何区别，但应用层需要自己来定义心跳包格式。之所以实现在服务器侧，是因为与客户端相比，服务器侧的寿命更长，因为服务器侧需要不间断地提供服务，而客户端可能由于用户下班而合上电脑（TCP没有来得及发送FIN关闭连接），这样的话，服务器侧就会有很多不可用的TCP连接（established)，这样的连接依然会占用服务器内存资源，于是就设计这个keepalive 来检测客户端是否可用，如果几次重传keepalive ，客户端没有相应，删除连接，释放资源。需要指出的是，超时时间是指TCP连接没有任何数据、控制字传输的时间，如果有任何数据传输，会刷新定时器，重新走表。TCP心跳是一个备受争议的实现，只是一个option，不是强制标准。之所以应用层需要独立实现自己的心跳，是因为超时时间较长，无法给应用层提供快速的反馈。所以类似BGP协议就独立实现了自己的keepalive，最小可以设置一秒钟，三次没有应答即可以Reset连接，最快三秒可以检测到失效。而三秒依然太慢，可以用另外一个协议BFD来提供更快发现链路失效，最快可以配置成10ms，三次超时（30ms)就可以完成失效检测。

通过上面的介绍，感觉TCP keepalive已经很牛逼了，但为什么还会提到应用层的心跳呢？

目前了解的原因包括两个：

TCP keepalive处于传输层，由操作系统负责，能够判断进程存在，网络通畅，但无法判断进程阻塞或死锁等问题。
客户端与服务器之间有四层代理或负载均衡，即在传输层之上的代理，只有传输层以上的数据才被转发，例如socks5等
所以，基于以上原因，有时候还是需要应用程序自己去设计心跳规则的。
可以服务端负责周期发送心跳包，检测客户端，也可以客户端负责发送心跳包，或者服服务端和客户端同时发送心跳包。

可以根据具体的应用场景进行设计。

//代码层面的设置步骤：

int keepAlive = 1;    // 非0值，开启keepalive属性

int keepIdle = 60;    // 如该连接在60秒内没有任何数据往来,则进行此TCP层的探测

int keepInterval = 5; // 探测发包间隔为5秒

int keepCount = 3