常见的网络性能问题有如下几种：
问题一：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或防火墙拦截，客户端最终会等待读取超时。
移动网络和传统网络另一个很大的区别是Connection Migration问题。定义一个Socket连接是四元组（客户端IP，客户端Port，服务端IP，服务端Port），当用户的网络在WIFI/4G/3G/2G类型中切换时，其客户端IP会发生变化，如果此时正在进行网络服务通讯，那么Socket连接自身已经失效，最终也会导致网络服务失败。
问题四：传输Payload过大
传的多就传的慢，如果没做过特别优化，传输Payload可能会比实际所需要的大很多，那么对于整体网络服务耗时影响非常大。