TCP心跳检测

思考一个问题，当TCP的A，B两端建立了连接之后，如果一端拔掉网线或拔掉电源，另一端能知道嘛？（其实这个问题包含了两种情况， dead peers和网络通道中断） 答案是不能。 原因是，TCP建立连接和断开连接都是通过发送数据实现的（三次握手和四次挥手），TCP两端保存了一种数据的状态，就代表这种连接，TCP两端之间的路由设备只是将数据转发到目的地，并不知道这些数据实际代表什么含义，也没有在其中保存任何的状态信息，也就是说路由设备是没有什么连接的概念的，只做数据转发。只有数据的发送者和接收者两端知道传输的数据代表着一条连接。 这也说明了一点，如果不发送数据，是无法通知对方断开连接的。正常情况下当TCP的一端A调用socket的close或者进程结束，操作系统就会按照TCP协议发送FIN数据报文（四次挥手中的终结包），B端收到后，断开连接。但是当出现一端被拔掉网线或者电源时，就没有机会发送FIN报文。那么和A直连的路由设备虽然知道A设备已经断开了，可是由于路由设备并没有保存连接的状态信息，所以路由也就不可能去通知B端A端已经“不在线”，而B端由于并没有收到断开通知，就会依然保持连接。 B端保持连接并不是毫无代价的，如果这种异常连接很多，势必耗费大量资源，所以必须要想办法解决。 解决思路很简单，只要让B端通过这个连接主动向A端继续发送数据即可。上文说过，A端异常断开后，和A端直接连接的路由是知道的，所以当B发送的数据到达这个路由，必然就会返回B一个目的不可达，此时B就得知这条连接其实已经断开。 但是B端不知道什么时候出现这种异常，所以B需要定时发送数据已检测连接是否异常断开，这种定时发送的检测，就是我们所说的心跳检测。

客户端发起心跳：客户端每隔一段时间发送策略消息给Socket服务器，Socket服务器原路返回策略消息，如果客户端在设定时间内没有收到返回的消息，经重试机制后，判定Socket服务器已经down，关闭连接。 服务端发起的心跳：服务端实时记录每条Socket的IO操作时间，每隔一段时间获取所有Socket列表的快照，扫描每条Socket，如果该Socket的IO操作时间距当前时间已超出设定值，则判定客户端Down，关闭连接。

1.应用层自己实现的心跳包 服务器在一个Timer事件中定时，向客户端发送一个心跳包，然后启动一个低级别的线程，在该线程中不断检测客户端的回应，一段时间内未收到回应，则判定客户端掉线（反之亦然）。 2.TCP的KeepAlive保活机制 一个服务器通常会连接多个客户端，因此由用户在应用层自己实现心跳包，代码较多且稍复杂，而利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。 不论是服务端还是客户端，一方开启KeepAlive功能后，就会自动在规定时间内向对方发送心跳包，而另一方在收到心跳包后就会自动回复，以告诉对方我仍然在线。 因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不开启KeepAlive功能，要用setsockopt()函数将SOL_SOCKET.SO_KEEPALIVE设置为1才是打开。（尽管这微不足道，但在按流量计费的环境下增加了费用），另一方面，KeepAlive设置不合理时可能会 因为短暂的网络波动而断开健康的TCP连接。

1.应用层的心跳数据包会耗费更多的带宽，因为TCP协议的保活机制发送的是数据长度为零的零心跳包，而应用层的心跳数据包长度必然大于零（因为还需包含一些必要信息，如告诉服务器这个包是心跳包）。 2.应用层心跳包可以携带一些应用所需数据，随应用自己控制，而TCP保活机制是对于应用层透明的，无法利用心跳包携带数据。

转载自：【jiangdewei2012：“心跳检测”】 【太上绝情：“TCP新手误区–心跳的意义”】 【wei_xin42218802：“TCP 应用层 心跳包”】 【TCP Keepalive HOWTO：https://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/#whatis】 【梦起丶：“Qt使用TCP实现简单服务端和客户端（带心跳检测）”】