常见的网络性能问题有如下几种:
问题一: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可能会比实际所需要的大很多,那么对于整体网络服务耗时影响非常大。