导致请求失败的因素
想要优化请求成功率先来了解移动端网络请求全链条可能导致请求失败的环节有哪些，这些环节往往由以下两类因素导致：
第一类，不可改善因素
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%。
网络请求成功率因素
除了重试，还有以下因素对网络请求成功率有直接影响：
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 能力
本文转载自公众号爱奇艺技术产品团队（ID：iQIYI-TP）。
原文链接：
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论