对于IM这种应用而言,应用层的网络保活的最直接办法就是心跳机制,比如主流的IM里有微信、QQ、钉钉、易信等等,可能代码实现细节有所差异,但理论上无一例外都是这样实现。(PS:没错,当初微信跟运营商间的“信令危机”就是跟这个有关)
所谓的网络心跳,通常是客户端每隔一小段时间向服务器发送一个数据包(即心跳包),通知服务器自己仍然在线(心跳包中同时可能传输一些必要的数据)。发送心跳包,从通信层面来说就是为了保持长连接,至于这个包的内容,是没有什么特别规定的,但在移动端IM中为了省流量,一般都是很小的包(比如某些第3方的IM云为了说明心跳不费流量,号称1字节的心跳包)。
但经常有人会问到,既然TCP协议本身有KeepAlive保活这个东西(见:《TCP/IP详解 卷1 - 第23章·TCP的保活定时器》),为什么还要自已在应用层去实现网络保活/心跳机制呢?
没错,通常面视即时通讯/IM方面的程序员时,这几乎是必提问题!
TCP KeepAlive的初衷
采用TCP连接的C/S模式应用中,当连接的双方在连接空闲状态时,如果任意一方意外崩溃、当机、网线断开或路由器故障,另一方无法得知TCP连接已经失效。
那么,连接的另一方并不知道对端的情况,它会一直维护这个连接。而作为“服务端”来说,长时间的积累会导致非常多的半打开连接,造成端系统资源的消耗和浪费,且有可能导致在一个无效的数据链路层面发送业务数据,结果就是发送失败。
所以各端要做到快速感知失败,减少无效链接操作,这就有了TCP的KeepAlive保活探测机制。
PS:这样宽泛的说TCP的KeepAlive机制的必要性,貌似还不是很有说服力,下节将带着具体的例子深入分析。
从NAT角度更具体地理解TCP KeepAlive的必要性
讲到TCP的KeepAlive的必要性,多数文章都是像上节这样