IM即时通讯软件开发网络请求成功率的优化

Posted 2022-08-06 wecloud1314

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

 

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

    1）移动状态网络信号不稳定，高时延、易抖动丢包、通道狭窄；
    2）移动状态网络接入类型和接入点变化频繁；
    3）移动状态用户使用高频化、碎片化、非WIFI流量敏感。

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

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

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

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

第一类：不可改善因素：

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

第二类：可以改善因素：

    1）蜂窝/Wifi信号的强弱、连接拥堵的假连接状态；
    2）DNS故障（比如DNS劫持等）；
    3）运营商局部节点故障；
    4）自有运营负载均衡故障；
    5）业务服务器故障：HTTP响应错误，对应APM的HTTP响应错误率；
    6）业务逻辑错误：监控子类解析结果，对应APM的解析错误率监控。

对于不可改善因素：目前只能通过网络诊断识别出故障类型，引导用户手动去授权访问网络或者连接可用网络。

其中，如果是路由器故障，可以引导用户重启路由器或者切换4G。通过爱奇艺APP的数据监控，大致可以看到用户无网连接的时长占比有3.8%左右，这说明提供好的无网提示变得十分重要，而从用户使用蜂窝信号的弱信号(0格和1格信号)时长占比有9%左右时长，也可以看出移动端网络环境的复杂性。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

针对可以改善的因素，解决方法可大致分为三类：

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

为了提高网络请求成功率，首先需要建立监控体系，从而使得基线网络库能够通过网络统计模块向APM投递各种维度的网络请求数据。有了APM的数据统计后，才能有效的发现导致端上网络失败的原因，进而解决问题。

除此之外，由于端上网络请求数据巨大，存储空间的限制使得APM只能采样2%的用户，因此针对重点业务的网络请求（比如首页）则进行了全量采集，从而对成功率的优化实现更客观全面的评估。

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

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

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

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

1）HTTP/2 vs HTTP/1.1：推荐的请求策略是首次请求走H2，当失败重试时走HTTP/1.1：

HTTP/2对HTTP/1.1最大改进是共用一个TCP连接，其在网络顺畅时，为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包越少，传输失败的概率也就降低了。

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

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

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，从而提高请求的成功概率。