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

1、引言

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

我们平时看到的移动网络主要有如下三个典型特点：

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

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

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

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

正是由于上述特点，移动端应用在进行网络数据通信时会面临各种复杂多变的问题。

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

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

本文已同步发布于我的“即时通讯技术圈”公众号。

2、导致移动端网络请求失败的因素

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

这些环节往往由以下两类因素导致：

第一类：不可改善因素：

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%的用户，因此针对重点业务的网络请求（比如首页）则进行了全量采集，从而对成功率的优化实现更客观全面的评估。

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

在优化之前，通过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%。

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

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

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%》）。

5、提高鲁棒性并防止故障的优化措施

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

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）网络日志模块：记录了最近发生的失败网络请求详细数据和网络诊断数据。随反馈一并提交，可以便捷的排查线上网络问题。

6、未来的目标与可能的优化措施

为了持续优化网络成功率，下一步目标是扣除无网情况，重点业务成功率达到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）

7、参考资料

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

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

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

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

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

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

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

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