TCP/IP怎么做心跳

问题
我面试时经常会问的一个问题是当TCP两端A、B建立了连接后，如果一端拔掉网线或者拔掉电源，那么另一端能够收到通知吗？
答案是不会

原因
TCP的建立连接和断开连接都是通过发送数据实现的，也就是我们常说的三次握手、四次挥手。TCP两端保存了一种数据的状态，就代表这种连接，TCP两端之间的路由设备只是将数据转发到目的地，并不知道这些数据实际代表了什么含义，也并没有在其中保存任何的状态信息，也就是说中间的路由设备没有什么连接的概念，只是将数据转发到目的地，只有数据的发送者和接受者两端真正的知道传输的数据代表着一条连接。

但是这就说明了一点，如果不发送数据那么是无法断开连接的。正常情况下当TCP的一端A调用了SOCKET的close或者进程结束，操作系统就会按照TCP协议发送FIN数据报文。B端收到后就会断开连接。但是当出现了上文所说的异常情况时：被拔掉网线或者断掉电源，总结起来就是没有机会发出断开的FIN数据报文。那么和A直连的路由设备虽然知道A设备已经断开了，但是路由设备并没有保存连接的状态信息，所以路由设备也就不可能去通知B端A端的断开。而B端没有收到断开的数据报文就会依然保持连接。所以A端拔掉网线或者断掉电源后B端是没办法收到断开连接的通知的。

解决方案

KEEP_ALIVE
TCP协议本身就提供了一种这样的机制来探测对端的存活。TCP协议有一个KEEP_LIVE开关，只要打开这个开关就会定时发送一些数据长度为零的探测心跳包，发送的频率和次数都可以设置，具体的方法在网上搜索tcp keepalive即可，网上有很多文章，这里不再赘述。

应用层心跳
除了使用TCP协议本身的保活开关机制，还可以在应用层主动发送心跳数据包，那么在应用层主动发送心跳数据包的方式和TCP协议本身的保活机制有什么区别呢？

应用层的心跳数据包会耗费更多的带宽，因为TCP协议的保活机制发送的是数据长度为零心跳包，而应用层的心跳数据包长度则必然会大于0。
应用层的心跳数据包可以带一些应用所需要的数据，随应用自己控制，而TCP协议的保活机制则是对于应用层透明的，无法利用心跳携带数据。
双向心跳
那么是否只是一端向另一端发送心跳就行了呢？显然不行。因为两端都有可能发生异常断开的情况。所以TCP连接的两端必须都向对端发送心跳。

统计在线用户

心跳包实现思路

我采用的思路是：客户端连接上服务端以后，服务端维护一个在线用户字典，客户端每隔一段时间，向服务器发送一个心跳包，服务器接收到包以后，字典数据的值都会更新为0；一旦服务端超过规定时间没有接收到客户端发来的包，字典数据将会递增加一，当字典数据的值累计大于等于三，则视为掉线。