图2-1 Line在国内的轮询策略

3、台湾(不使用GCM):

从IBG同事win和guang提供的测试数据中看到,台湾使用的策略跟国内的轮询策略类似。

2.3 微信

微信没有使用GCM,自己维护TCP长连接,使用固定心跳。

2.4心跳典型值

WhatsApp Line GCM
WiFi 4分45秒 3分20秒 15分钟
手机 络 4分45秒 7分钟 28分钟

2.5Line、WhatsApp、微信Push策略的优点

  • a)微信:当前心跳间隔比竞品短,所以微信在新消息提醒上会最及时。

  • b)使用GCM:Line和WhatsApp使用GCM策略的最大优点就是省电,以及减轻系统负荷(减少后台应用数目)。

  • c)Line:Line的轮询策略,优点是当Line处于活跃状态时,及时收消息。当Line处于不活跃状态时,省电。

2.6Line、WhatsApp微信Push策略的不足

  • a)微信当前心跳频率相对竞品较大,在耗电、耗流量,占用信令通道等方面有所影响。

  • b)Line的轮询策略,导致的问题是消息可能会延迟接收,测试发现最大延迟间隔到2.5小时。

  • c)WhatsApp和Line使用Push拉起一个定时长连接策略,缺点是要依赖Google的Push服务,如果Google的Push服务不稳定,消息也会延迟接收。

  • d)在国内的移动和联通2G 络下,由于运营商的策略,GCM长连接频繁断连,WhatsApp的Push消息很不及时,体验非常差。

3. GCM研究

3.1 GCM特点

  • a)Android2.2以下的手机不支持GCM,2.2到3.0需要安装Google Store并设置Google帐 ,4.04及以上版本不需要设置帐 也能支持。

  • b)GCM只传递数据(可以传递小于4kb的数据),对这些数据的处理可以全部由开发者控制。

  • c)Android应用不需要运行就可以接收消息(通过Android广播)。

  • d)GCM不保证发送的消息的顺序,也不保证消息一定能够推送到手机。

3.2 GCM心跳策略以及存在的问题

  • a)用心跳保活长连接,心跳间隔为WIFI下15分钟,数据 络下28分钟。

  • b)Google可以改变所有Android设备的心跳间隔值(目前还未改变过)。

  • c)GCM由于心跳间隔固定,并且较长,所以在NAT aging-time设置较小的 络(如联通2G,或有些WIFI环境下)会导致TCP长连接在下一次心跳前被 关释放。造成Push延迟接收。

3.3 GCM的可用性及稳定性

目前测试发现GCM在国内可用性不高,原因有:

  • a) Android很多被手机厂商定制化,厂商可能会去掉GCM服务。

  • b) Android2.2到3.0之间需要安装Google Store并设置Google帐 。

  • c)由于国内2G和移动3G的NAT超时时间都小于GCM心跳时间(28分钟),TCP长连接必然无法保活,每次都要等28分钟心跳失败重连后才能收到Push。

  • d)某些运营商可能限制了5228端口,移动3G/2G下,发现几乎无法连接上GCM服务器,也就无法获得GCM通知,WhatsApp放后台10分钟后,经常很长时间都收不到Push消息。

在美国3G 络下抓包的24小时,GCM的连接极其稳定,24小时内GCM长连接未曾断过,在台湾3G 络下抓包14个小时,GCM连接也只断过一次。WhatsApp用户在此类地区 络下客户端可以获得很及时的Push通知。

在中国电信3G下抓包,大部分时间GCM连接都比较稳定,只会因为偶尔的DHCP造成断连现象,由于频率很低(平均数小时才发生一次),对Push体验的影响不大。

3.4 GCM Server类型

GCM提供两种Server模型:

  • aHTTP Server :使用同步接口发送HTTP请求,一次请求可以发给最多1000个设备。

  • bXMPP Server :使用异步接口发送请求,只支持对单个设备(或同一个用户的多个关联设备发送),发送请求并发数须小于1000,支持设备到云端Server发送数据。需要Google将我们的发送Server加入白名单。

4.微信可能的改进点探讨

微信Push的优化主要有几个优化点:

  • a) 公共Push通道

  • b) 使用GCM Push作为辅助通道

  • c)自适应心跳间隔优化

4.1 公共Push通道

由于GCM在国内的可靠性很低,现在国内Android上的Push基本上是各自为政,很多软件都自己实现Push。导致手机被经常性的唤醒,耗电耗流量严重。

市面上已经有很多第三方的公共推送服务,大家可以选择一个适合自己应用的推送服务。腾讯也有信鸽和维纳斯组件,大家在选择方案的时候可以对比下。

最终因为我们国内外使用一套方案,并且是辅助公道,所以我们选择使用GCM。

4.2 使用GCM Push作为辅助通道

当前使用GCM的成本不大,可以使用GCM作为辅助通道来增加新消息的及时性。

使用GCM作为辅助通道,在支持GCM的设备上微信上传自己的注册GCM ID给微信Server。

微信Server在发现长连接失效的情况下,可以使用GCM 作为辅助通道通知客户端有新消息,客户端收到push通知后做一次sync。

只利用GCM来激活微信,不传递消息的具体数据,要控制给同一设备发送GCM通知的时间间隔(如五分钟)。

4.3 自适应心跳间隔优化

4.3.1 影响TCP连接寿命的因素

在Android下,不管是GCM,还是微信,都是通过TCP长连接来进行Push消息的,TCP长连接存活,消息Push就及时,所以要对影响TCP连接寿命的因素进行研究。

  • 1NAT超时

大部分移动无线 络运营商都在链路一段时间没有数据通讯时,会淘汰 NAT 表中的对应项,造成链路中断(NAT超时的更多描述见【附录6.1】)。NAT超时是影响TCP连接寿命的一个重要因素(尤其是国内),所以客户端自动测算NAT超时时间,来动态调整心跳间隔,是一个重要的优化点。

  • 2DHCP的租期(lease time)

目前测试发现安卓系统对DHCP的处理有Bug,DHCP租期到了不会主动续约并且会继续使用过期IP,这个问题会造成TCP长连接偶然的断连。(_租期问题的具体描述见【附录6.2】)。

  • 3、 络状态变化

手机 络和WIFI 络切换、 络断开和连上等情况有 络状态的变化,也会使长连接变为无效连接,需要监听响应的 络状态变化事件,重新建立Push长连接。

4.3.2 心跳范围选择

  • 1、前后台区分处理

为了保证微信收消息及时性的体验,当微信处于前台活跃状态时,使用固定心跳。

微信进入后台(或者前台关屏)时,先用几次最小心跳维持长链接。然后进入后台自适应心跳计算。这样做的目的是尽量选择用户不活跃的时间段,来减少心跳计算可能产生的消息不及时收取影响。

  • 2、后台自适应心跳选择区间

可根据自身产品的特点选择合适的心跳范围。

4.3.3状态转换图

图4-1 自适应心跳计算流程

自适应心跳计算流程如图4-1所示,经过该流程,会找到必然使心跳失败的curHeart(或者MaxHeart),为了保险起见,我们选择比前一个成功值稍微小一点的值作为后台稳定期的心跳间隔

影响手机 络测试的因素太多,为了尽量保证测试结果的可靠性,我们使用延迟心跳测试法。

在我们重新建立TCP连接后,先使用 短心跳连续成功三次,我们才认为 络相对稳定,可以使用curHeart进行一次心跳测试。

图4-2显示了一次有效心跳测试过程。图4-3显示了在没有达到稳定 络环境时,我们会一直使用固定短心跳直到满足三次连续短心跳成功。

使用延迟心跳测试的好处是,可以剔除偶然失败,和 络变化较大的情况(如地铁),使测试结果相对可靠(五次延迟测试确定结论)。同时在 络波动较大的情况,使用短心跳,保证收取消息相对及时。

c)运行时的动态调整策略(已经按测算心跳稳定值后)

NAT超时值算出来后,在维持心跳的过程中的策略

  • 无 络、 络时好时坏、偶然失败、NAT超时变小: 在后台稳定期发生心跳发生失败后,我们使用延迟心跳测试法测试五次。如果有一次成功,则保持当前心跳值不变;如果五次测试全失败,重新计算合理心跳值。
    该过程如图4-4所示,有一点需要注意,每个新建的长连接需要先用短心跳成功维持3次后才用successHeart进行心跳。

NAT 功能由图中的 GGSN 模块实现

大部分移动无线 络运营商都在链路一段时间没有数据通讯时,会淘汰 NAT 表中的对应项,造成链路中断。下表列出一些已测试过的 络的NAT超时时间(更多数据由于测试条件所限没有测到):

地区/ 络 NAT超时时间
中国移动3G和2G 5分钟
中国联通2G 5分钟
中国电信3G 大于28分钟
美国3G 大于28分钟
台湾3G 大于28分钟

长连接心跳间隔必须要小于NAT超时时间(aging-time),如果超过aging-time不做心跳,TCP长连接链路就会中断,Server就无法发送Push给手机,只能等到客户端下次心跳失败后,重建连接才能取到消息。

6.2 附录B——安卓DHCP的租期(lease time)问题

附录B

目前测试发现安卓系统对DHCP的处理有Bug:

  1. DHCP租期到了不会主动续约并且会继续使用过期IP,

详细描述见http://www.net.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html

这个问题导致的问题表象是,在超过租期的某个时间点(没有规律)会导致IP过期,老的TCP连接不能正常收发数据。并且系统没有 络变化事件,只有等应用判断主动建立新的TCP连接才引起安卓设备重新向DHCP Server申请IP租用。
2. 未到租期的一半时间,安卓设备重新向DHCP Server申请IP租用。从目前测试结果来看,这种现象恢复的比较快。
3. 移动2G/3G,联通2G没有抓到DHCP。
4. 美国3G下抓取24小时,没有抓到DHCP。

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年5月1日
下一篇 2021年5月1日

相关推荐