从测试的角度，应该建立实时监控的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连接实现网络服务，就要自己对读写超时时间负责，与网络连接超时时长参数类似，太小了在低速网络很容易读写失败，太大了又可能影响用户体验，因此需要非常小心地处理。
我们还遇到另一类问题，某些酒店Wi-Fi对使用非80、8080和443等常见HTTP端口的服务进行了限制，即使发送Request是正常的，服务端能够正常收到，但是Response却被酒店网络proxy或防火墙拦截，客户端最终会等待读取超时。
问题四：传输Payload过大
传的多就传的慢，如果没做过特别优化，传输Payload可能会比实际所需要的大很多，那么对于整体网络服务耗时影响非常大。
问题五：复杂的国内外网络情况
国内运营商互联和海外访问国内带宽低传输慢的问题也令人难非常头疼。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。