App 的网络环境测试和性能问题

从测试的角度，应该建立实时监控的 web portal。其实测试的目的除了保证产品
发布的质量。更重要的是为优化提供依据，所以 report 最后一部分都是 issue list
和 optmize advice，当然测试最难的部分也是优化

移动网络和传统网络另一个很大的区别是 Connection Migration 问题。定义一个
Socket 连接是四元组（客户端 IP，客户端 Port，服务端 IP，服务端 Port），当用
户的网络在 WIFI/4G/3G/2G 类型中切换时，其客户端 IP 会发生变化，如果此时
正在进行网络服务通讯，那么 Socket 连接自身已经失效，最终也会导致网络服
务失败。

常见的网络性能问题有如下几种：

问题一：DNS 问题

DNS 出问题的概率其实比大家感觉的要大，首先是 DNS 被劫持或者失效，2015
年初业内比较知名的就有 Apple 内部 DNS 问题导致 App Store、iTunes Connect 账
户无法登录；京东因为 CDN 域名付费问题导致服务停摆。携程在去年 11 月也遇
到过 DNS 问题，主域名被国外服务商误列入黑名单，导致主站和 H5 等所有站点
无法访问，但是 App 客户端的 Native 服务都正常，原因后面介绍。

另一个常见问题就是 DNS 解析慢或者失败，例如国内中国运营商网络的 DNS 就
很慢，一次 DNS 查询的耗时甚至都能赶上一次连接的耗时，尤其 2G 网络情况下，
DNS 解析失败是很常见的。因此如果直接使用 DNS，对于首次网络服务请求耗时
和整体服务成功率都有非常大的影响。

问题二：TCP 连接问题

DNS 成功后拿到 IP，便可以发起 TCP 连接。HTTP 协议的网络层也是 TCP 连接，
因此 TCP 连接的成功和耗时也成为网络性能的一个因素。我们发现常见的问题有
TCP 端口被封（例如上海长宽对非 HTTP 常见端口 80、8080、443 的封锁）

，以及

TCP 连接超时时长问题。端口被封，直接导致无法连接；连接超时时长过短，在
低速网络上可能总是无法连接成果；连接超时过长，又有可能导致用户长时间等
待，用户体验差。很多时候尽快失败重新发起一次连接会很快，这也是移动网络
带宽不稳定情况下的一个常见情况。

问题三：Write/Read 问题

DNS Lookup 和 TCP 连接成功后，就会开始发送 Request，服务端处理后返回
Response，如果是 HTTP 连接，业内大部分 App 是使用第三方 SDK 或者系统提供
的 API 来实现，那么只能设置些缓存策略和超时时间。iOS 上的 NSURLConnection
超时时间在不同版本上还有不同的定义，很多时候需要自己设置 Timer 来实现；
如果是直接使用 TCP 连接实现网络服务，就要自己对读写超时时间负责，与网络