当我们开始关注 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 网络诊断；
• 根据网络情况，动态设置超时时间等。