移动客户端中长连接技术(一)

蔚落 2022-08-02 06:02 288阅读 0赞

前文提到用socket基于自定义的协议和TCP协议实现长连接，今天我们一步步来推演一下长连接的框架结构。  
记得小学的时候有篇文章，讲述的是手工课上，爱因斯坦做出了一个非常简单粗陋的小板凳，老师和同学们都嘲笑他：还有比这更难看的小板凳么，爱因斯坦默默拿出了之前的做的一个和第二个小板凳，说：有，这两个是我前两次做的，比这个更加的丑陋。依循大师足迹，我们也来做一做自己的小板凳。  
**第一个小板凳**  
![这里写图片描述][20150712091241400]  
Now，产品原型诞生了。基于最简单的想法，只要客户端主动发起请求，并且成功连接到服务端，那么客户端与服务端就可以通过建立的链接自有的交流了。在不需要长连接模块时，断开连接，完成了整个交互的流程。  
但是这个模型是几乎完全不能正常工作的。这涉及到计算机网络的相关知识。  
**移动网络**  
当一台手机连接上移动互联网时，运营商从其空闲的IP地址池中取出一个给该手机使用，这个IP是运营商的内网IP，用户这时也并没有真正连接上Internet，手机最终要连上Internet需要运营商的网关进行IP地址的转换(NetWork Address Translation，简称NAT)，就是将内网的IP、端口映射到外部IP地址上。运营商为了减轻网关压力，腾出更多的空间给需要的用户，在一个链路有一段时间没有通信时就会强制断开其连接，删除其NAT映射表，造成链路中断。  
所以第一个小板凳的连接很快就会被网关kill掉，为了保证数据通道的畅通，长连接采用了定期向服务器发送空闲数据包的方案来维护二者之前建立起来的长连接通路，我们称之为心跳包。  
**心跳-实时通道的守卫者**  
心跳是长链接通道联通的一个重要保证，一方面当客户端与服务器长时间彼此不发送数据时，心跳包能”欺骗”网格，让网关认为目前的通道仍然存在数据流通，是有效的。另一方面，心跳包也是客户端检测与服务端连接的有效手段，发出的心跳包，对方必须应答，如果应答超时，那就意味着当前的通道已被破会，为维护后续通讯的正常进行，长连接模块就必须重建当前通道。  
同时，心跳的数据是空的数据包，必然会带来数据量和App耗电量的增加，所以我们要尽可能的减小心跳包的大小，尽可能的降低心跳包的发送频度(以能够维持连接的最大间隔为最佳)。在实际的网络结构中，不同的网关，不同的运营商的策略也不尽相同，所以心跳包的发送频率要多测试，从中取得一个合适的数值。  
有了心跳机制和断网检测重连截止，我们的长连接就可以应用于实战了，于是我们的第二个小板凳诞生了。  
**第二个小板凳**  
![这里写图片描述][20150712091305280]  
至此，长连接已经可以投入实战了。  
**其它资料**  
Android和IOS系统上推送是服务器主动向客户端推送消息，所以它本质上就是一个长连接。  
IOS长连接是由系统来维护的，也就是说苹果的IOS系统在系统级别维护了一个客户端和苹果服务器的长链接，IOS上的所有应用上的推送都是先将消息推送到苹果的服务器然后将苹果服务器通过这个系统级别的长链接推送到手机终端上。  
这样的的几个好处为：  
1.在手机终端始终只要维护一个长连接即可，而且由于这个长链接是系统级别的不会出现被杀死而无法推送的情况。  
2.省电，不会出现每个应用都各自维护一个自己的长连接。  
3.安全，只有在苹果注册的开发者才能够进行推送，等等。  
android的长连接是由每个应用各自维护的，但是google也推出了和苹果技术架构相似的推送框架，C2DM,云端推送功能，但是由于google的服务器不在中国境内，其他的原因你懂的。所以导致这个推送无法使用，android的开发者不得不自己去维护一个长链接，于是每个应用如果都24小时在线，那么都得各自维护一个长连接，这种电量和流量的消耗是可想而知的。虽然国内也出现了各种推送平台，但是都无法达到只维护一个长连接这种消耗的级别。

参考资料：[http://blog.csdn.net/clh604/article/details/20167263][http_blog.csdn.net_clh604_article_details_20167263]

[20150712091241400]: /images/20220731/e8278dcd0a64466a82f4ee1a2985de0c.png
[20150712091305280]: /images/20220731/fef8462e37b9454ebab0c45e49f9f126.png
[http_blog.csdn.net_clh604_article_details_20167263]: http://blog.csdn.net/clh604/article/details/20167263