移动应用APP的网络优化三大重点方向即成功率、耗时与流量。其中，APP成功率即网络请求成功率，他的重要性直接体现于它能直接决定APP服务的可用性，直接影响到视频播放、广告展现、支付便捷等服务质量。本文将介绍爱奇艺APP对网络请求成功率优化的实践之路。
导致请求失败的因素
想要优化请求成功率先来了解移动端网络请求全链条可能导致请求失败的环节有哪些，这些环节往往由以下两类因素导致：
第一类，不可改善因素
- iOS系统对APP的网络访问权限控制、飞行模式或者无网络连接。检测和识别这三种情况，通过适当方式提示用户。
- 路由器故障。
第二类，可以改善因素
- 蜂窝/Wifi信号的强弱、连接拥堵的假连接状态。
- DNS故障。
- 运营商局部节点故障。
- 自有运营负载均衡故障。
- 业务服务器故障。HTTP响应错误，对应APM的HTTP响应错误率。
- 业务逻辑错误。监控子类解析结果，对应APM的解析错误率监控。
对于不可改善因素，目前只能通过网络诊断识别出故障类型，引导用户手动去授权访问网络或者连接可用网络。其中，如果是路由器故障，可以引导用户重启路由器或者切换4G。通过爱奇艺APP的数据监控，大致可以看到用户无网连接的时长占比有3.8%左右，这说明提供好的无网提示变得十分重要，而从用户使用蜂窝信号的弱信号(0格和1格信号)时长占比有9%左右时长，也可以看出移动端网络环境的复杂性。
针对可以改善的因素可大致分为三类：
- 网络层错误，对应因素1到4。主要体现为超时报错；
- 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的包间超时，并不是整体请求耗时的超时。
