【行业动态】看谷歌是如何提高Push到达率的

作者：HW-XTS

谷歌I/O大会交流，虽然是16年的材料，但也可以参考，材料中的关键信息摘要如下：

1）时延分2部分：

APP Server-->(FrontEnd --->BackEnd) --->Device

FrontEnd-->BackEnd: 中位数64ms, 95分位数161ms

BackEnd -->Device：中位数160ms，80分位数348ms

2）不可达3个用户归因：Low battery / Poor signal / Data disabled

3）不可达2个客观原因：NAT / Random Failures(列举基础设施故障、运营商断网……)

4）连接被断分2种：Explicit close(polite) / Silent close(impolite，导致假连接)

假连接——影响到达率的第一大根因，可问题是，如何准确识别假连接？

5）先从移动网络场景分析，不同运营商断连原因占比不同，最好的99.4%是第一种Explicit close(polite)，也就是总是有0.6%的假连接---有可能和运营商基础设施有关

6）最差的小运营商，Explicit close(polite)只有61.7%，也就是高达38.3%的假连接

7）针对上述情况，FCM怎么办？——就一招：缩短心跳间隔！Explicit close(polite)61.7%提升到90.6%，但没说心跳间隔从多少调整到多少，应该是探测的，小于探测到的NAT老化周期

8）WIFI也有类似情况，有些WIFI在NAT断连后会分别给两方发RST报文，这种属于Explicit close(polite)，但有的不会。

Explicit close(polite)

Silent close(impolite)

9）WIFI的NAT怎么解决？——同一招：缩短心跳间隔！经过实验测试，NAT=10min的情况下，心跳间隔从15min调整到9min，连接可用性从66%提升到97%，电量还省了3%！

长心跳间隔，超过NAT时间，重连多了，也实际上导致电量消耗更多了，还不如缩短心跳间隔更省电！

还有自适应心跳方法：

红色是心跳间隔，黄色是NAT超时时间，NAT超时不断变化，心跳间隔取值也跟着变化，但是也有上限值(510s，之前有实测过）和下限值(90s）。

以达到电池和连接可用性的一个平衡，鱼和熊掌岂能兼得！

10）现网实施后，54%的用户电池改善了！72%的用户连接可用性改善了！

Hangout聊天APP消息99分位的时延下降比例变化情况。第一条竖的绿虚线表示现网优化心跳灰度实施50%之后，第二条竖的绿虚线表示100%实施。

整体下降55%——缩短心跳间隔，这是大招啊！

11)离线消息送达时延在不同国家表现，从快到慢：USA->Brazil->Global(相关于均值)->Indonesia->India

12)离线消息在一周不同天表现（奇葩视角），从快到慢：Tue->Web->Mon->Thur->Fri->Sun->Sat