网络通信（网络保活）

最新推荐文章于 2024-05-03 06:02:57 发布

十维之眼

最新推荐文章于 2024-05-03 06:02:57 发布

阅读量886

点赞数

分类专栏：网络通信文章标签：网络

原文链接：http://www.52im.net/thread-209-1-1.html

版权

网络通信专栏收录该内容

5 篇文章 1 订阅

订阅专栏

转载：微信团队原创分享，Android版微信后台保活实战分享(网络保活篇)

哪些部分需要“保活”？

按照我们的理解包含两部分：

网络连接保活：
如何保证消息接收实时性。这是本文要讨论的内容。
进程保活：
尽量保证应用的进程不被Android系统回收。详见本文下篇《微信团队原创分享：Android版微信后台保活实战分享（进程保活篇）》

网络连接保活概述

网络保活，业界主要手段有：

a. GCM；
b. 公共的第三方push通道(信鸽等)；
c. 自身跟服务器通过轮询，或者长连接。

国产机器大多缺乏GMS，在国内GCM也不稳定(心跳原因)，第三方通道需要考虑安全问题和承载能力，最后微信选择使用自己的长连接。而国外， GCM作为辅助，微信无法建立长连接时，才使用GCM。

之前看到大家在聊各种Java网络框架，而微信实际上都是没用上的。早年的微信，直接通过Java socket 实现。微信v5.0后，考虑各系统平台的统一，开始使用自研c++组件。

长连接实现包括几个要素：

a. 网络切换或者初始化时 server ip 的获取。
b. 连接前的 ip筛选，出错后ip 的抛弃。
c. 维护长连接的心跳。
d. 服务器通过长连notify。
e. 选择使用长连通道的业务。
f. 断开后重连的策略。

我们重点讨论心跳和 notify 机制。

网络连接保活实施：心跳机制

心跳的目的很简单：通过定期的数据包，对抗NAT超时。以下是部分地区网络NAT 超时统计：

上表说明：

a. GCM无法适应国内2G环境(GCM 28分钟心跳)。
b. 为了兼容国内网络要求，我们至少5分钟心跳一次。

老版本的微信是4.5分钟发送一次心跳，运行良好。

（有关GCM的研究详见《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》）

心跳的实现：

a. 连接后主动到服务器Sync拉取一次数据，确保连接过程的新消息。
b. 心跳周期的Alarm 唤醒后，一般有几秒的cpu 时间，无需wakelock。
c. 心跳后的Alarm防止发送超时，如服务器正常回包，该Alarm 取消。
d. 如果服务器回包，系统通过网络唤醒，无需wakelock。

流程基于两个系统特性：

a. Alarm唤醒后，足够cpu时间发包。
b. 网络回包可唤醒机器。

特别是b项，假如Android封堵该特性，那就只能用GCM了。API level >= 23的doze就关闭所有的网络， alarm等。但进入doze条件苛刻，现在6.0普及低，至今微信没收到相关投诉。另Google也最终加入REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限。
（有关微信Android端心跳的具体技术实现详见《微信对网络影响的技术试验及分析（论文全文）》、《移动端IM实践：实现Android版微信的智能心跳机制》）

网络连接保活实施：动态心跳

4.5min心跳周期是稳定可靠的，但无法确定是最大值。通过终端的尝试，可以获取到特定用户网络下，心跳的最大值。

引入该特性的背景：

a. 运营商的信令风暴
b. 运营商网络换代，NAT超时趋于增大
c. Alarm耗电，心跳耗流量。

动态心跳引入下列状态：

a. 前台活跃态：亮屏，微信在前台，周期minHeart (4.5min) ，保证体验。
b. 后台活跃态：微信在后台10分钟内，周期minHeart ，保证体验。
c. 自适应计算态：步增心跳，尝试获取最大心跳周期(sucHeart)。
d. 后台稳定态：通过最大周期，保持稳定心跳。

自适应计算态流程：

在自适应态：

a. curHeart初始值为minHeart ，步增(heartStep)为1分钟。
b. curHeart 失败5次，意味着整个自适应态最多只有5分钟无法接收消息。
c. 结束后，如果sucHeart > minHeart，会减去10s(避开临界)，为该网络下的稳定周期。
d. 进入稳定态时，要求连接连续三次成功minHeart心跳周期，再使用sucHeart。

稳定态的退出：

sucHeart 会对应网络存储下来，重启后正常使用。考虑到网络的不稳定，如NAT超时变小，用户地理位置变换。当发现sucHeart 连续5次失败， sucHeart 置为minHeart ，重新进入自适应态。

网络连接保活实施：notify机制

网络保活的意义在于消息实时。通过长连接，微信有下列机制保证消息的实时。

1Sync

通过Sync CGI直接请求后台数据。Sync 通过后台和终端的seq值对比，判断该下发哪些消息。终端正常处理消息后，seq更新为最新值。

2Sync 的主要场景

a. 长连无法建立时，通过Sync 定期轮询
b. 微信切到前台时，触发Sync(保命机制)
c. 长连建立完成，立即触发Sync，防止连接过程漏消息
d. 接收到Notify 或者 gcm 后，终端触发Sync 接收消息.

3Notify

类似于GCM。通过长连接，后台发出仅带seq的小包，终端根据seq决定是否触发Sync拉取消息。

4NotifyData

在长连稳定， Notify机制正常的情况下(保证seq的同步)。后台直接推送消息内容，节省1个RTT (Sync) 消息接收时间。终端收到内容后，带上seq回应NotifyAck，确认成功。这里会出现Notify和NotifyData状态互相切换的情况：

如NotifyData 后，服务器在没收到NotifyAck，而有新消息的情况下，会切换回到Notify，Sync可能需要冗余之前NotifyData的消息。终端要保证串行处理NotifyData和Sync ，否则seq可能回退。

5GCM

只要机器上有GMS ，启动时就尝试注册GCM，并通知后台。服务器会根据终端是否保持长连，决定是否由GCM通知。GCM主要针对国外比较复杂的网络环境。

QA环节

Q：在智能心跳自适应阶段，如果5次心跳失败是否会促发重连？因为5次心跳都失败的话连接是不是已经断开了？
A：这里可能刚才描述不够清晰，任何一次心跳失败后，必然就已经断开重连了，所以每次心跳失败，对应一次重连操作。

Q：在某些网络下，经常出现网络闪断的情况，这种情况下势必会引起频繁的socket重连，微信有没有遇到类似的情况？有没有什么优化的方法，求指教。
A：这种情况是有的，微信在前台时，我们会比较积极的更换ip重试，或者换短连ip。在后台时，如果出现频繁，会加上比较长的间隔。

Q：多端同时登录情况(手机，电脑同时登录)，假如有一端网络情况不好，怎么保证收到消息一致性？
A：多终端登录消息一致的问题，是由后台保证的，实际原理也就是上面提到的seq。

Q：有没有遇到过有一些端口被运营商封了的情况？我们之前有一些用户就是死活连不上某个端口。
A：服务器给我们开的端口有好几个，比如80/8080/443等，而且允许服务器下发，所以实际上现在服务器会用哪些端口，终端这边都无需关注了。

Q：再问一个问题，服务端主动notify的话，时间间隔是如何选择的？因为这个关系到用户的流量消耗。
A：notifydata是实时的，只要你的状态允许，你的好友给你发消息的时候就会立即在服务器转换成notifydata给到你，所以这里的频率并不在于时间间隔，而在于你接收消息然后返回ack的间隔。流量消耗上，实际要比触发sync更少。

Q：这种保活机制会极大的增加app的耗电量，在可以通过GCM稳定唤醒app的场景下，是否可以停用后台保活，从而省电？
A：其实心跳机制真的不会带来多少耗电，一个心跳包发出和接收，实际的消耗远远低于您收发一条消息。心跳间隔时间微信实际不会使用任何cpu的。唤醒机制靠的是网络回包。GCM唤醒这种模式国外有app是这样做的，但还是因为国内GCM不靠谱，另外这种模式要比notify，notifydata都慢。