导致请求失败的因素

想要优化请求成功率先来了解移动端网络请求全链条可能导致请求失败的环节有哪些，这些环节往往由以下两类因素导致：

第一类，不可改善因素

iOS系统对APP的网络访问权限控制、飞行模式或者无网络连接。检测和识别这三种情况，通过适当方式提示用户。
路由器故障。

第二类，可以改善因素

蜂窝/Wifi信号的强弱、连接拥堵的假连接状态。
DNS故障。
运营商局部节点故障。
自有运营负载均衡故障。
业务服务器故障。HTTP响应错误，对应APM的HTTP响应错误率。
业务逻辑错误。监控子类解析结果，对应APM的解析错误率监控。

对于不可改善因素，目前只能通过网络诊断识别出故障类型，引导用户手动去授权访问网络或者连接可用网络。其中，如果是路由器故障，可以引导用户重启路由器或者切换4G。通过爱奇艺APP的数据监控，大致可以看到用户无网连接的时长占比有3.8%左右，这说明提供好的无网提示变得十分重要，而从用户使用蜂窝信号的弱信号(0格和1格信号)时长占比有9%左右时长，也可以看出移动端网络环境的复杂性。

1.针对可以改善的因素可大致分为三类：
2.网络层错误，对应因素1到4。主要体现为超时报错；
3.HTTP响应错误，对应因素5。HTTP状态码为400及以上；解析错误，对应因素6。由基线网络库定义的重载接口进行监控。

为了提高网络请求成功率，首先需要建立监控体系，从而使得基线网络库能够通过网络统计模块向APM投递各种维度的网络请求数据。有了APM的数据统计后，才能有效的发现导致端上网络失败的原因，进而解决问题。除此之外，由于端上网络请求数据巨大，存储空间的限制使得APM只能采样2%的用户，因此针对重点业务的网络请求（比如首页）则进行了全量采集，从而对成功率的优化实现更客观全面的评估。

基线网络库针对不同业务手段

在优化之前，通过APM的归类分析可以得出：请求失败的主要报错是超时(-1001)的占比达到九成，与此同时SSL错误，DNS解析错误占比紧随其后。根据这一数据统计，重试成为最主要的请求成功率优化的措施。经过不断探索和实践总结，基线网络库针对不同业务需求提供了四种不同的重试手段：

IP 直连重试，通过配置直连IP数来控制重试次数

Scheme不变，Host改为直接使用IP(消除域名解析风险)。由于此举需要各个业务线自己提供直连的IP，目前接入的业务主要是登录等强制要求HTTPS连接的业务。
超级管道重试，可以配置1~3次重试

公司自研基于HTTP的网关代理服务(类似于远程charles代理)。Host改为代理IP(消除域名解析风险)，Scheme改为HTTP(消除SSL风险，h2降级为HTTP1.1)。由于该措施需要付出流量成本，目前接入的业务都是关键核心业务，比如首页等。
HTTP 重试，可以配置1~3次重试

Scheme修改为HTTP(消除SSL风险，h2降级为HTTP1.1)，其他不变。鉴于其为普惠性重试手段，目前接入非关键核心的一般业务。
原url重试，可以配置1~3次重试

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

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

重试类型	成功率	备注
无重试	98.26%	-
HTTP重试	99.42%	原始URL是HTTPs会被改为HTTP，减少SSL握手带来的失败可能。同时确保HTTP1.1协议
超级管道重试	99.55%	超级管道是IP直连的HTTP请求，减少了DNS解析和SLL握手带来的失败可能。同时确保HTTP1.1协议。
2 *超级管道重试 + HTTP重试	99.76%	两次超级管道,确保超级管道的异地容灾能力被激活，HTTP重试是对超级管道的兜底策略。

网络请求成功率因素

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

1. H2 vs HTTP1.1：推荐的请求策略是首次请求走H2，当失败重试时走HTTP1.1。

H2对HTTP1.1最大改进是共用一个TCP连接，其在网络顺畅时，为H2带来了速度上的优势。但当网络变坏时，TCP包的绝对顺序编号会导致一个包的丢失而堵住后面所有的请求。这样单TCP连接反而扩大了拥堵，增大了请求失败的可能性。

NSURLSession是HTTP协议自适应的，不能控制请求使用H2或者HTTP1.1。不过由于业界事实上的标准要求H2必须是HTTPs的，这样通过将URL Scheme改为HTTP可以间接降级到HTTP1.1。

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

NSURLSession的超时实际上是TCP的包间超时，并不是整体请求耗时的超时。

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

3. 接口请求过于密集并发可能降低请求成功率

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

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

H2和HTTP1.1都是基于TCP连接的，接口数据体积越小，需要传输的TCP包越少，传输失败的概率也就降低了。目前爱奇艺APP正在从gzip转向压缩率更高的br。

提高鲁棒性并防止故障措施

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

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基础网络库的构成如下：

统一网络库提供一个网络接口层，所有业务接口都对接使用网络接口层。
统一网络库提供一个网络封装层，对接了iOS系统网络层NSURLSession、ASIHTTPRequest(基于CFNetwork)、和公司自研的长连接网关。
网络统计模块：将从业务调用开始到回调给业务方的各个环节的耗时及状态值，变成统计数据，上传到APM汇合。
网络诊断模块：对关键业务进行诊断，包括dns解析，ping，tcpconnect，trace等工具对具体IP进行分析，分析结果上传到APM汇合。
弱网检测模块：通过借鉴Facebook的弱网检测是基于网速拟合的网络等级分级，分为网络情况非常差(2G或者无网)、网络情况较差(3G)、网络情况一般、网络情况较好、网络情况非常好五个等级。
HTTPDNS模块：有效的解决了运营商劫持问题。
超级管道重试：基于HTTP的网关代理，具有异地容灾代理能力。
ipv4/ipv6模块：识别端上是ipv4 only环境、v4/v6双栈还是ipv6 only环境。
复合连接模块：可以在server IP缓存池选出最佳IP，手段包括目标IP连接竞速，IP历史请求统计数据排序。
网络日志模块：记录了最近发生的失败网络请求详细数据和网络诊断数据。随反馈一并提交，可以便捷的排查线上网络问题。

目标与优化措施

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

Multipath

当Wifi假连接的时可以走蜂窝流量，iOS9开始支持 Multipath特性。
QUIC

QUIC是基于UDP的，由于运营商对UDP有针对性的丢包，实测QUIC并没有体现出优势。然而，考虑到libcurl在2019已提供完整QUIC能力，NSURLSession不久也会支持QUIC。随着运营商对UDP包的干扰减少，QUIC的优势将得到体现。
智能调度并发

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

4 HTTPDNS的push能力

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

本文转载自公众号爱奇艺技术产品团队（ID：iQIYI-TP）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzI0MjczMjM2NA==&mid=2247486692&idx=1&sn=18b80481a1512c7eddaabd510a983377&chksm=e97690c7de0119d154db46b09ca4b504f67965d74cd6783fd57c1e1c4f1c52d8f46d4ebccaea&scene=27#wechat_redirect

创作场景

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