移动端网络常见问题及优化对策

当我们开始关注 App 的用户体验后，网络通畅性和界面的流畅性是保证 App 好用的重要指标。近期对项目中的网络数据进行了简单的分析，又对业界的一些方案做了调研，故写此文做一下知识梳理。

当我们使用

App 的 时候，如经常遇到加载失败或者小圈转个不停的情况，那么很可能 App

的网络性能出现了问题，急需研发同学来进行优化。而对于开发人员来说，定位网络问题又是十分艰难，因为出现网络问题的用户往往遥在天边，你没办法进行调试定位。那么建立完善的网络监控体系就显得十分重要，通过海量数据的分析来对网络问题精确定位。

通过对数据的分析以及调研、用户反馈，发现移动端网络常常存在如下的问题：

网络成功率低，经常请求失败

用户反馈 DNS 劫持，数据被篡改，出现广告和请求超时等情况

网络延迟较长，且存在较多的长尾数据

经过数据分析，发现长连的时间明显比短连的时间少 100ms 左右（短连指的是，经过DNS解析、 TCP 握手、 SSL 握手等一系列的过程建立连接，长连指的是直接复用前者的连接通道）

网络经常出现抖动，本来大部分请求都是 100ms 左右，突然冒出来一两千毫秒的，甚至有10、20秒的延迟情况

HTTP

1.1的head of blocking 情况存在，一个网络抖动，很容易影响后续的请求，导致一连串的延迟较高请求（head of

blocking：指的是在 HTTP 1.1 中，如果你发出1、2、3 三个网络请求，那么 Response 的顺序 2、3

要在第一个网络请求之后）

传输的 Payload 太大，延迟高，易超时

苹果要求HTTPS ，此时加入的 SSL 握手较耗时

针对上面一系列的问题，业界已经有很多解决方案，我在这里简单列举一些

面对这样的网络，如何解决？

对于

DNS 劫持的情况，业界的主要做法是 HTTPDNS 或者内置 Server IP 列表。客户端直接访问 HttpDNS

接口，获取业务在域名配置管理系统上配置的访问延迟最优的IP，获取到IP后就直接往此IP发送业务协议请求，不需要使用本地运营商解析域名，所以从根本避免了劫持问题，同时可以降低网络延迟，提高连接成功率。而建立

Server IP 列表，是在本地缓存一个 IP 的映射表，此表可在App启动时动态下发更新，访问服务器时直接拿出 IP 发出请求。

传输的

Payload 也直接影响了延迟，并且对成功率有影响，对于数据的压缩，业界很多公司已经开始使用 ProtoBuf

协议，对于优化的百分比我还没有准确的说数据结论，但是从大家的反馈来说，优化效果明显。对于数据的压缩，还可以考虑接入 HTTP

2.0，毕竟这是一个趋势，也有较多公司已经加入 HTTP 2.0，HTTP 2.0 通过头部压缩等方式也帮你减小了传输的 Payload。

上面的问题其实很多是涉及到长连与短连的问题，对这个问题有较多的问题可以考虑

域名合并：淘宝、美团等公司公布的方案中都有提到，就是将公司原来很多域名的情况，合并为较少的几个域名，为什么这么做呢？HTTP 的通道复用是基于域名划分的，如果域名只有几个，那么多数请求都可以在长连接通道进行，这样就可以降低延迟、增加成功率。

尽早建立长连接，这样其他的业务请求就可以复用长连接通道，加快访问速度。对于建立连接的时机，可以考虑多个方面，比如冷启动，前后台切换、网络切换等

考虑接入

HTTP2.0，他们两个都解决了 HTTP 1.1 的head of

blocking，降低了网络延迟，提供了更强大的多路复用技术，还加入了流量控制、新的二进制格式、Server

Push、请求优先级和依赖等特性。或者接入 SPDY ，但是目前觉得好像直接上 HTTP 2.0 比较合适

建立多通道，比如携程、美团等公司都有自己TCP、UDP通道，具有多域名共用通道，成功率三个九等诱人的功效。同时各大厂也对新的网络协议，比如 QUIC，进行尝试。Facebook还出一分享，对 QUIC 改进，实现 TLS 的 0-RTT

再者还有一些其他可以考虑的点

加入 CDN 加速，动静资源分离

对于埋点的数据，也可以合并请求，减少流量

App 网络诊断

根据网络情况，动态设置超时时间等

原文地址:移动端网络常见问题及优化对策