实现Android版的智能⼼跳机制
本⽂由开发团队⼈员编写,转⾃ WeMobileDev,感谢。
⼀引⾔
在2013年11⽉中旬时,因为基础组件组⼈⼿紧张,Leo安排我和春哥去⼴州轮岗⽀援。
刚到⼴州的时候,Ray让我和春哥对Line和WhatsApp的⼼跳机制进⾏分析。我和春哥抓包测试了差不多两个多礼拜,在我们基本上摸清了Line和WhatsApp的⼼跳机制后,Ray才告诉我们真正的任务——对的固定⼼跳进⾏优化,并告诉我们这不是⼀件容易的事情。
于是我和春哥开始构思第⼀个⽅案,我们开始想⽤统计的⽅法来解决问题,当我们拿着第⼀个⽅案和Ray讨论时,发现不能优雅应对Ray的所有提问:
•1、测试环境的准确性,失败到底是因为⽹络的特性导致还是因为⽤户当前的环境变化导致的暂时失败。
•2、临界值界定,如果⽅案选中的⼼跳值是临界值,我们该怎么办。高铁学校学费
Ray和组件组同事在⽹络⽅⾯有极其丰富的经验,虽然他没有给我们指出明确的⽅向,但提出的问题帮助我们更快的补齐需要⾯对的核⼼问题。这两个问题让我和春哥意识到如果能很好的解决,就可以给出⼀个⽐较好的⼼跳⽅案。第⼀个问题我和春哥开始就意识到,第⼆个问题我们确实在⼀开始时疏忽了。但直接解决这两个问题确实不容易,这着实让我和春哥迷茫了⼏天,有两三天在纺园我都没怎么睡着,因为想不到更好的⽅法。
直到有⼀天思路发⽣了⼀些转变,既然最优解⽐较复杂,为什么不绕过去,使⽤有损服务理念次优解呢。让复杂的事情简单化,好了,想到这⾥突然有⼀种拨开云雾的感觉。
⼆⼤体思路
•a)延迟⼼跳测试法:这是测试结果准确的前提保障,我们认为长连接建⽴后连续三次成功的短⼼跳就可以很⼤程度的保证下⼀次⼼跳环境是正常的。
•b)成功⼀次认定,失败连续累积认定:成功是绝对的,连续失败多次才可能是失败。
•c)临界值避免:我们使⽤⽐计算出的⼼跳稍微⼩⼀点的值做为稳定⼼跳避免临界值。
•d)动态调整:即使在⼀次完整的智能⼼跳计算过程中,我们没有到最好的值,我们还有机会来进⾏校正。
三拍板⽅案
当我和春哥想出第⼆个简单易⾏的⽅案后,我们⼼⾥就很有底了,去Ray讨论,Ray听完后⼀次通过,然后Ray约了Harvey,给Harvey讲完后,Harvey说听起来可以,可以试试。
然后就开始动⼿,分析竞品加确定⽅案花了差不多两个⽉。写⼼跳的主要代码,只花了⼀天时间,我记得那天是年会后的⼀天。回过头来再看这个⽅案花费的时间还是值得的,后来灰度的统计数据显⽰,70%⽤户都可以达到我们的⼼跳上限。
搞完智能⼼跳后⼀段时间在⼴州没事⼲,我就跟Ray商量,Ray让我去测试下WebView的性能瓶颈。然后我跟周斯基⼀起来做这件事,搞完了安卓客户端WebView性能瓶颈测试后,因为怀孕的⽼婆⼀个⼈在深圳,领导就安排我先回深圳了。春哥坚守着把GCM部分完成后才回深圳。
等我们的⼼跳版本正式发布后,⼀年前我在公司km上分享了智能⼼跳⽅案,吸引不少做push的同事加⼊了讨论,感觉这⽅⾯的交流还是很有必要的。
四⽅案⽬标
设计此⽅案的主要⽬标是,在尽量不影响⽤户收消息及时性的前提下,根据⽹络类型⾃适应的出保活信令TCP连接的尽可能⼤的⼼跳间隔,从⽽达到减少安卓因⼼跳引起的空中信道资源消耗,减
少⼼跳Server的负载,以及减少部分
因⼼跳引起的耗电。
主要⽅法是参考WhatsApp和Line中有价值的做法,结合影响TCP连接寿命的因素,实现Android后台⾃适应⼼跳算法。
* 有关WhatsApp、Lin的消息推送策略请参考⽂章《WhatsApp、Line、的⼼跳策略分析》;
* 有关GCM的研究结论请参考⽂章《⾕歌消息推送服务(GCM)研究(来⾃团队)》。
五⽅案需考虑到影响连接寿命的思素
在Android下,不管是GCM,还是,都是通过TCP长连接来进⾏消息收发的,TCP长连接存活,消息收发就及时,所以要对影响TCP连接寿命的因素进⾏研究。
1、NAT超时
⼤部分移动⽆线⽹络运营商都在链路⼀段时间没有数据通讯时,会淘汰 NAT 表中的对应项,造成链路中断(NAT超时的更多描述见附录9.1)。NAT超时是影响TCP连接寿命的⼀个重要因素(尤其是国内),所以客户端⾃动测算NAT超时时间,来动态调整⼼跳间隔,是⼀个重要的优化点。
2、DHCP的租期(lease time)
⽬前测试发现安卓系统对DHCP的处理有Bug,DHCP租期到了不会主动续约并且会继续使⽤过期IP,这个问题会造成TCP长连接偶然的断连。(租期问题的具体描述见附录9.2)。
3、⽹络状态变化
⼿机⽹络和WIFI⽹络切换、⽹络断开和连上等情况有⽹络状态的变化,也会使长连接变为⽆效连接,需要监听响应的⽹络状态变化事件,重新建⽴Push长连接。
六⼼跳范围选择
1、前后台区分处理:
为了保证收消息及时性的体验,当处于前台活跃状态时,使⽤固定⼼跳。进⼊后台(或者前台关屏)时,先⽤⼏次最⼩⼼跳维持长链接。然后进⼊后台⾃适应⼼跳计算。这样做的⽬的是尽量选择⽤户不活跃的时间段,来减少⼼跳计算可能产⽣的消息不及时收取影响。
邓文迪 普京
2、后台⾃适应⼼跳选择区间:
可根据⾃⾝产品的特点选择合适的⼼跳范围。
以下是状态转换⽰意图:
七⾃适应⼼跳算法量化描述
因为每个⽹络的NAT时间可能不⼀致。所以需要区分计算,数据⽹络按subType做关键字,WIFI按WIFI名做关键字。对稳定的⽹络,因为NAT⽼化时间的存在,在⾃适应计算态的时候,暂设计以下步骤在当前⼼跳区间逼近出最⼤可⽤的⼼跳。
a)变量说明:
•[MinHeart,MaxHeart]——⼼跳可选区间。
•[MinHeart,MaxHeart]——⼼跳可选区间。
•successHeart——当前成功⼼跳,初始为MinHeart
•curHeart——当前⼼跳初始值为successHeart
•heartStep——⼼跳增加步长
•successStep——稳定期后的探测步长
b)最⼤值探测步骤(⾃适应⼼跳计算流程):
⾃适应⼼跳计算流程如上图所⽰,经过该流程,会到必然使⼼跳失败的curHeart(或者MaxHeart),为了保险起见,我们选择⽐前⼀个成功值稍微⼩⼀点的值作为后台稳定期的⼼跳间隔。军区划分
影响⼿机⽹络测试的因素太多,为了尽量保证测试结果的可靠性,我们使⽤延迟⼼跳测试法。在我们重新建⽴TCP连接后,先使⽤短⼼跳连续成功三次,我们才认为⽹络相对稳定,可以使⽤curHeart进⾏⼀次⼼跳测试。图4-2显⽰了⼀次有效⼼跳测试过程。图4-3显⽰了在没有达到稳定⽹络环境时,我们会⼀直使⽤固定短⼼跳直到满⾜三次连续短⼼跳成功。
使⽤延迟⼼跳测试的好处是,可以剔除偶然失败,和⽹络变化较⼤的情况(如地铁),使测试结果相对可靠(五次延迟测试确定结论)。同时在⽹络波动较⼤的情况,使⽤短⼼跳,保证收取消息相对及时。
c)运⾏时的动态调整策略(已经按测算⼼跳稳定值后)
NAT超时值算出来后,在维持⼼跳的过程中的策略。
- ⽆⽹络、⽹络时好时坏、偶然失败、NAT超时变⼩:
在后台稳定期发⽣⼼跳发⽣失败后,我们使⽤延迟⼼跳测试法测试五次。如果有⼀次成功,则保持当前⼼跳值不变;如果五次测试全失败,重新计算合理⼼跳值。该过程如图4-4所⽰,有⼀点需要注意,每个新建的长连接需要先⽤短⼼跳成功维持3次后才⽤successHeart进⾏⼼跳。后台稳定态动态调整⼼跳策略如下图:
- NAT超时变⼤:
天气晴朗
以周为周期,每周三将后台稳定态调⾄⾃适应计算态,使⽤⼼跳延迟法往后探测⼼跳间隔。
- successHeart是NAT超时临界值:
因为我们现在选择的是⼀个⽐successHeart稍⼩的值作为稳定值,所以在计算过程中可以避开临界值。当运营商在我们后台稳定期将NAT超时调整为我们当前计算值,那么由于我们每周会去向下探索,所以下⼀周探测时也可以及时调整正确。
d)冗余Sync和⼼跳
在⽤户的⼀些主动操作以及联⽹状态改变时,增加冗余Sync和⼼跳,确保及时收到消息。
•1、当⽤户点亮屏幕的时候,做⼀次⼼跳。
•2、当切换到前台时,做⼀次Sync。
•3、联⽹时重建信令TCP,做⼀次Sync。
⼋可能存在的风险及预防措施
DHCP租期因素:
•1、问题:根据⽬前的测试结果显⽰,安卓不续约到期的IP Bug,会导致TCP连接在不确定的时间点失效,从⽽会导致⼀次⼼跳失败。
•2、预防:统计后台稳定期的⼼跳成功率,上报给后台。后台可以按地区分⽹络监控这个指标的波动,并且后台可以
•2、预防:统计后台稳定期的⼼跳成功率,上报给后台。后台可以按地区分⽹络监控这个指标的波动,并且后台可以根据不同的波动,动态调整某区域特定⽹络下可选的⼼跳区间。
9 附录
1附录A:NAT超时介绍
因为 IP v4 的 IP 量有限,运营商分配给⼿机终端的 IP 是运营商内⽹的 IP,⼿机要连接 Internet,就需要通过运营商的⽹关做⼀个⽹络地址转换(Network Address Translation,NAT)。简单的说运营商的⽹关需要维护⼀个外⽹ IP、端⼝到内⽹ IP、端⼝的对应关系,以确保内⽹的⼿机可以跟 Internet 的服务器通讯。
⼤部分移动⽆线⽹络运营商都在链路⼀段时间没有数据通讯时,会淘汰 NAT 表中的对应项,造成链路中断。歌颂老师的作文
下表列出⼀些已测试过的⽹络的NAT超时时间(更多数据由于测试条件所限没有测到):
地区/⽹络NAT超时时间中国移动3G和2G5分钟中国联通2G5分钟中国电信3G⼤于28分钟美国3G⼤于28分钟台湾3G⼤于28分钟
长连接⼼跳间隔必须要⼩于NAT超时时间(aging-time),如果超过aging-time不做⼼跳,TCP长连接链路就会中
断,Server就⽆法发送Push给⼿机,只能等到客户端下次⼼跳失败后,重建连接才能取到消息。
2附录B:安卓DHCP的租期(lease time)问题
⽬前测试发现安卓系统对DHCP的处理有Bug:
•1、DHCP租期到了不会主动续约并且会继续使⽤过期IP:
•详细描述见 www.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-
pgone的歌
11236.html。这个问题导致的问题表象是,在超过租期的某个时间点(没有规律)会导致IP过期,⽼的TCP连接不能正常收发数据。并且系统没有⽹络变化事件,只有等应⽤判断主动建⽴新的TCP连接才引起安卓设备重新向DHCP Server申请IP租⽤。
•2、未到租期的⼀半时间,安卓设备重新向DHCP Server申请IP租⽤。从⽬前测试结果来看,这种现象恢复的⽐较快。
•3、移动2G/3G,联通2G没有抓到DHCP。
•4、美国3G下抓取24⼩时,没有抓到DHCP。
anyRTC作为⾳视频实时通讯PaaS云平台,为客户提供实时⾳视频通讯引擎,以其⽀持全平台、集成简单、超低延时、⾼稳定等独有特点,服务于安防、在线教育、娱乐、社交、物联⽹等⾏业。
anyRTC同时为体制内教育《在线课堂》、《同步课堂》、《双师课堂》提供软硬件⼀体整体解决⽅案,提供定制化开发、提供私有化部署。