爱奇艺移动端网络优化实践分享：网络请求成功率优化篇

本文原始内容由爱奇艺技术产品团队原创分享，本次有修订和改动。

一、引言

因为移动网络的复杂性特色，编写高质量、体验好的具有网络通讯能力的移动端应用（尤为是即时通信这类网络质量高度敏感的应用）有很大的挑战性。

咱们平时看到的移动网络主要有以下三个典型特色：

1）移动状态网络信号不稳定，高时延、易抖动丢包、通道狭窄；

2）移动状态网络接入类型和接入点变化频繁；

3）移动状态用户使用高频化、碎片化、非WIFI流量敏感。

（▲ 上述文字，引用自《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》）

正是因为上述特色，移动端应用在进行网络数据通讯时会面临各类复杂多变的问题。

不管后面的技术有多复杂，但对于普通用户使用APP来讲，能顺畅的完成网络请求，是理所固然的事。换句话说，APP网络请求成功率，重要性直接体如今它能直接决定APP服务的可用性，直接影响到数据通讯、视频播放、广告展示、支付便捷等服务质量。

本文将以爱奇艺的iOS端APP为例，分享对移动网络请求成功率优化方面的技术实践之路。

本文已同步发布于个人“即时通信技术圈”公众号。

二、致使移动端网络请求失败的因素

想要优化移动端网络请求成功率，先来了解移动端网络请求全链条可能致使请求失败的环节有哪些。

这些环节每每由如下两类因素致使：

 

 

第一类：不可改善因素：

1）iOS系统对APP的网络访问权限控制、飞行模式或者无网络链接。检测和识别这三种状况，经过适当方式提示用户；

2）路由器故障。

第二类：能够改善因素：

1）蜂窝/Wifi信号的强弱、链接拥堵的假链接状态；

2）DNS故障（好比DNS劫持等）；

3）运营商局部节点故障；

4）自有运营负载均衡故障；

5）业务服务器故障：HTTP响应错误，对应APM的HTTP响应错误率；

6）业务逻辑错误：监控子类解析结果，对应APM的解析错误率监控。

对于不可改善因素：目前只能经过网络诊断识别出故障类型，引导用户手动去受权访问网络或者链接可用网络。

其中，若是是路由器故障，能够引导用户重启路由器或者切换4G。经过爱奇艺APP的数据监控，大体能够看到用户无网链接的时长占比有3.8%左右，这说明提供好的无网提示变得十分重要，而从用户使用蜂窝信号的弱信号(0格和1格信号)时长占比有9%左右时长，也能够看出移动端网络环境的复杂性。

 

 

针对能够改善的因素，解决方法可大体分为三类：

1）网络层错误，对应因素1到4。主要体现为超时报错；

2）HTTP响应错误，对应因素5。HTTP状态码为400及以上；

3）解析错误，对应因素6。由基线网络库定义的重载接口进行监控。

为了提升网络请求成功率，首先须要创建监控体系，从而使得基线网络库可以经过网络统计模块向APM投递各类维度的网络请求数据。有了APM的数据统计后，才能有效的发现致使端上网络失败的缘由，进而解决问题。

除此以外，因为端上网络请求数据巨大，存储空间的限制使得APM只能采样2%的用户，所以针对重点业务的网络请求（好比首页）则进行了全量采集，从而对成功率的优化实现更客观全面的评估。

三、在基线网络库这一层针对不一样业务提供不一样的补偿思路

在优化以前，经过APM的归类分析能够得出：请求失败的主要报错是超时(-1001)的占比达到九成，与此同时SSL错误，DNS解析错误占比紧随其后。根据这一数据统计，重试成为最主要的请求成功率优化的措施。

通过不断探索和实践总结，基线网络库针对不一样业务需求提供了四种不一样的重试手段。

1）IP直连重试，经过配置直连IP数来控制重试次数：

Scheme不变，Host改成直接使用IP(消除域名解析风险)。因为此举须要各个业务线本身提供直连的IP，目前接入的业务主要是登陆等强制要求HTTPS链接的业务。

2）超级管道重试，能够配置1~3次重试：

公司自研基于HTTP的网关代理服务(相似于远程charles代理)。Host改成代理IP(消除域名解析风险)，Scheme改成HTTP(消除SSL风险，h2降级为HTTP1.1)。因为该措施须要付出流量成本，目前接入的业务都是关键核心业务，好比首页等。

3）HTTP重试，能够配置1~3次重试：

Scheme修改成HTTP(消除SSL风险，h2降级为HTTP1.1)，其余不变。鉴于其为普惠性重试手段，目前接入非关键核心的通常业务。

4）原url重试，能够配置1~3次重试：

Scheme和host等都不变，一般意义上理解的重试，单纯的再请求一次。此举目前不是推荐重试手段，由业务方自主决定。

 

除了单个重试手段能够重试屡次，基础网络库也支持多种重试手段的组合，四种重试手段的优先次序为：IP直连重试 > 超级管道重试 > HTTP重试 > 原URL重试。扣除无网状况，首页推荐页CARD接口成功率经过组合重试在2020第一季度末达到了99.76%。

四、其它影响移动端网络请求成功率的因素

除了重试，还有如下因素对网络请求成功率有直接影响。

1）HTTP/2 vs HTTP/1.1：推荐的请求策略是首次请求走H2，当失败重试时走HTTP/1.1：

HTTP/2对HTTP/1.1最大改进是共用一个TCP链接（详见《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》），其在网络顺畅时，为HTTP/2带来了速度上的优点。但当网络变坏时，TCP包的绝对顺序编号会致使一个包的丢失而堵住后面全部的请求。这样单TCP链接反而扩大了拥堵，增大了请求失败的可能性。

NSURLSession是HTTP协议自适应的，不能控制请求使用HTTP/2或者HTTP/1.1。不过因为业界事实上的标准要求HTTP/2必须是HTTPs的，这样经过将URL Scheme改成HTTP能够间接降级到HTTP/1.1。

2）适当的超时设置是一个重要影响因素：

NSURLSession的超时其实是TCP的包间超时，并非总体请求耗时的超时。

 

推荐的超时设置策略是：首次请求的超时能够小一点，而重试的超时应该大一些。

3）接口请求过于密集并发可能下降请求成功率：

好比播放记录的upload接口在加上屡次重试后，成功率仍然只有98.2%。APM监控此接口在IPv4环境失败率只有0.47%，而IPv6失败率高达7.07%。经过端上优化请求策略，下降接口的并发密度后，IPv6环境和IPv4环境同时提升到99.85%的成功率。

4）接口数据体积越小，请求成功率越高：

HTTP/2和HTTP/1.1都是基于TCP链接的，接口数据体积越小，须要传输的TCP包越少，传输失败的几率也就下降了。目前爱奇艺APP正在从gzip转向压缩率更高的br（指的是Brotli压缩算法，详见：《启用 Brotli 压缩算法，对比 Gzip 压缩 CDN 流量再减小 20%》）。

五、提升鲁棒性并防止故障的优化措施

在通过各类优化措施提升网络成功率后，咱们还经过下面几个措施成功的防止线上故障形成的成功率瞬时降低，提升了网络请求的鲁棒性。

1）超级管道自己的鲁棒性：

下面案例显示使用了超级管道重试的接口错误率只有3.95%，而没有使用超级管道重试的接口错误率高达28.96%。这个案例的时间点尚未使用异地容灾IP，在叠加异地容灾IP以后，错误率曲线几乎能够抹平。

 

 

2）HTTP重试和原URL重试在v4v6双栈环境下，优先IPv4：

因为IPv6仍在建设中，有些接口在IPv6的表现弱于IPv4，那么能够指定重试走IPv4。

3）TLS1.3– 1RTT的节省：

TLS1.3将SSL握手2个RTT降为1个RTT，下降了SSL握手失败的几率。iOS12.2开始，NSURLSession支持TLS1.3。只须要服务器升级支持TLS1.3便可，端上无须改动。

4）IP复合链接竞速：

使用TCP链接测速，目的是剔除坏IP，选择最优IP，从而提升请求的成功几率。

经上述措施的持续优化，爱奇艺APP在2020Q1末，扣除无网状况后，业务成功率达到了99.7%，而网络层成功率达到了99.77%。

▲ 业务成功率 = 网络层成功率+HTTP响应成功率+解析成功率

在完成优化后，爱奇艺APP基础网络库的构成以下：

 

如上图所示，基础网络库各模板的功能做用以下：

1）统一网络库：提供一个网络接口层，全部业务接口都对接使用网络接口层；

2）统一网络库：提供一个网络封装层，对接了iOS系统网络层NSURLSession、ASIHTTPRequest(基于CFNetwork)、和公司自研的长链接网关；

3）网络统计模块：将从业务调用开始到回调给业务方的各个环节的耗时及状态值，变成统计数据，上传到APM汇合；

4）网络诊断模块：对关键业务进行诊断，包括dns解析，ping，tcpconnect，trace等工具对具体IP进行分析，分析结果上传到APM汇合；

5）弱网检测模块：经过借鉴Facebook的弱网检测是基于网速拟合的网络等级分级，分为网络状况很是差(2G或者无网)、网络状况较差(3G)、网络状况通常、网络状况较好、网络状况很是好五个等级；

6）HTTPDNS模块：有效的解决了运营商劫持问题；

7）超级管道重试：基于HTTP的网关代理，具备异地容灾代理能力；

8）ipv4/ipv6模块：识别端上是ipv4 only环境、v4/v6双栈仍是ipv6 only环境；

9）复合链接模块：能够在server IP缓存池选出最佳IP，手段包括目标IP链接竞速，IP历史请求统计数据排序；

10）网络日志模块：记录了最近发生的失败网络请求详细数据和网络诊断数据。随反馈一并提交，能够便捷的排查线上网络问题。

六、将来的目标与可能的优化措施

为了持续优化网络成功率，下一步目标是扣除无网状况，重点业务成功率达到99.9%。后续考虑的优化措施以下。

1）Multipath：

当Wifi假链接的时能够走蜂窝流量，iOS 7开始支持Multipath特性（详见：《揭开 iOS 7 之 Multipath TCP 的面纱》）。

2）QUIC：

QUIC是基于UDP的，因为运营商对UDP有针对性的丢包，实测QUIC并无体现出优点。然而，考虑到libcurl在2019已提供完整QUIC能力，NSURLSession不久也会支持QUIC。随着运营商对UDP包的干扰减小，QUIC的优点将获得体现。

若是对QUIC协议感兴趣，能够读一读下面这些文章：

3）智能调度并发：

更精准更灵敏的弱网识别，弱网下对关键核心业务进行倾斜。

4）HTTPDNS的push能力：

HTTPDNS打通APM的质量监控体系后，经过push及时下线故障IP。

（本文已同步发布于：http://www.52im.net/thread-2981-1-1.html）

七、参考资料

[1] 现代移动端网络短链接的优化手段总结：请求速度、弱网适应、安全保障

[2] 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”

[3] 移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结

[4] 全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等

[5] 美图App的移动端DNS优化实践：HTTPS请求耗时减少近半

[6] 百度APP移动端网络深度优化实践分享(一)：DNS优化篇

[7] 百度APP移动端网络深度优化实践分享(二)：网络链接优化篇

[8] 百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇