当我们开始关注 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 发出请求。