原文链接：https://cloud.tencent.com/developer/article/1707833

导致请求失败的因素

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

第一类，不可改善因素

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% 的用户，因此针对重点业务的网络请求（比如首页）则进行了全量采集，从而对成功率的优化实现更客观全面的评估。[563513413](https://jq.qq.com/?_wv=1027&k=lzJejkSl)，不管你是大牛还是小白都欢迎入驻

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

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

爱奇艺iOS移动端网络优化实践：请求成功率优化（转载）相关推荐

爱奇艺iOS移动端网络优化实践 | 请求成功率优化篇
移动应用APP的网络优化三大重点方向即成功率.耗时与流量.其中,APP成功率即网络请求成功率,他的重要性直接体现于它能直接决定APP服务的可用性,直接影响到视频播放.广告展现.支付便捷等服务质量.本文 ...
爱奇艺海外App的网络优化实践
做海外市场,特别是目标面向全球的用户,网络的重要性不言而喻.试想一个移动端应用,打开 App 首页需要 10s 的时间,恐怕会让一半的用户流失.爱奇艺推出的国际版面向全球的用户,在面临海外网络复杂的环 ...
爱奇艺iOS稳定性测试实践
稳定性测试是长时间持续运行APP,以验证应用是否稳定的测试.它可以有效发现APP长时间运行下的偶发闪退.内存泄露.性能变差等问题.iOS端通常由苹果系统的API快速执行点击事件,开展稳定性测试,类似的 ...
录制快、回放稳，爱奇艺iOS云录制回放平台技术实践
众所周知,移动APP的周期短.迭代速度快,测试人员在保证新功能正常运行的情况下需要回归大量的历史功能,自动化回归便成为重要的回归手段之一.iOS端自动化由于以下问题,一直很难在业务线广泛开展. 落地成 ...
爱奇艺知识移动端组件化探索和实践
前言组件化对于任何一个业务场景复杂的APP以及经过多次迭代之后的产品来说都是必经之路,组件化是指解耦复杂系统时将多个功能模块拆分.重组的过程.组件化要做的不仅仅是表面上看到的模块拆分解耦,其背后还有 ...
爱奇艺iOS真机远程APP测试技术实践
背景 iOS多机远程控制技术目前业界初步也有了一些方案,可以让APP在远程iPhone上面安装操作,对于设备兼容性测试是一款很好的服务,但是就体验上还是存在UI截屏延迟,设备掉线,稳定性不高的问题,尤 ...
爱奇艺埋点投递治理实践
9月26日下午,爱奇艺技术产品团队举办了第19期"i技术会",本次技术会的主题是"数据治理探索与应用",来自快手.美团.快看的几位资深专家同大家就相关议题进行了 ...
爱奇艺PC Web NodeJS中间层实践
爱奇艺作为中国最大的互联网视频综合门户,一直致力于给用户提供更好的使用体验及观影品质.PC主站作为爱奇艺的门户,日均覆盖用户达千万级别.随着公司业务的扩展及端上对项目更新迭代的频率越来越快,对接口的性 ...
【推荐实践】爱奇艺推荐中台探索与实践
猜你喜欢 0.某视频APP推荐策略和推荐算法详解 1.如何搭建一套个性化推荐系统? 2.内容推荐策略产品经理的方法与实践 3.京东推荐算法精排技术实践 4.微博推荐算法实践与机器学习平台演进 5.腾讯 ...

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