1 发现问题：
在第一版天马乐园app发布的时候，碰到一个问题，苹果审核app的时候，打开我们的app，发现等了很久界面都没有加载出来（大概有50s），由于苹果是在IPv6下测试的，就认为我们app没有适配IPv6被打了回来（实际上只有走底层socket通信的时候，有时候直接用了IPv4地址，这个时候就需要做IPv6的适配，一般来说上层网络API的调用，直接使用域名其实不需要做IPv6的适配，这一部分云服务提供商会帮我们处理，服务器端同学需要注意配置）。
2 分析问题：
连接美国VPN测试，结果发现通过Log调试发现主界面的一个HTTP请求（服务器在国内，使用的阿里云），从发出到app收到Respone，总共花费了50s（不设置HTTP代理的前提下），有的甚至60s。由于没有设置请求超时限制，在app没有缓存数据的情况下（苹果测试通常是卸载重装），主界面就会一直呈现loading的状态。通过Chares抓包，分析了请求，发现请求处理的时间是几十毫秒，bodySize大约300k，响应时间也是毫秒级别的。
不使用VPN，直接使用国内外网访问，Log调试同一个接口发现从请求到响应仅仅耗时2s-3s，Chares抓包分析bodySize，Request Time，Response Time基本接近。
3 问题根本原因：
经过对比连接VPN和不连接VPN两种情况，连接VPN时延相当严重，从HTTP层分析对比，根本原因就是HTTP事务的延迟。由于HTTP是短连接，每一次请求到响应，都要建立TCP连接，请求响应完之后就会断开连接。不开启Keep-Alive的情况下，下一个请求响应也是需要重新建立TCP连接，断开连接。
4 HTTP事务的时延：
如下图：
http事务时延
HTTP事务的时延由上面6个部分组成。一般来说抵达服务器，服务器进行请求，处理，到响应事务处理的时间都是很短的。最大的时延其实都是在TCP时延。这些TCP时延大小，取决的于硬件速度，网络和服务器的负载，请求和响应的body size，还有客户端和服务器之间的距离，优化网络请求，最主要的还是针对TCP连接的优化。
HTTP事务的时延主要原因：
（1）客户端首先需要根据URI确定Web服务器的IP地址和端口号，如果最近没有针对URI中的主机进行访问，那么就需要经过DNS解析，将URI中的主机名转换成对应的IP地址，这个过程会话费数十秒的时间。但是大多数的HTTP客户端都会有一个DNS缓存，用来保存近期所访问的IP地址，如果本地缓存了IP地址，那么查询就会立即完成，这一部分的时延就基本上不存在了，只有第一次访问URI的时候，会稍微花点时间。iOS客户端，如果想省略DNS解析，就直接使用IP地址，不过不建议这么做。假如后续服务器更改了IP地址，客户端也要随着更改，这样做法很不好。而且服务器这样的改动是很大可能性的。
（2）TCP连接的建立的时延。客户端发送HTTP请求到服务器，第一个阶段做DNS解析，接下来就是建立TCP连接，客户端和服务器需要经过三次握手才能建立连接。这一部分的优化有很多事情可以做，比如TCP连接建立握手，TCP慢启动拥塞控制，数据聚集的Nagle算法，TIME_WAIT时延和端口耗尽。这一部分的优化后续在TCP相关协议再继续探索。
（3）服务器请求，处理，响应的时延。客户端和服务器建立TCP连接成功之后，数据抵达服务器时候，服务器就是读取请求报文，并对请求进行处理，处理完之后回送HTTP响应，这一部分也需要花费时间。这个时间的长短，取决于服务器开发的人员对服务器代码的优化性能。
5 问题解决办法：
（1） 建立两个服务器，一个AWS，一个阿里云，默认选择AWS服务器，审核通过切回阿里云服务器。（缩短客户端和服务器之间的距离）
（2） 存一些线上数据到本地做预设数据。直接读取本地数据，用于卸载安装第一次显示主界面加载，同时请求网络，获取到新数据，清除之前的预设数据，把获取的新数据再缓存本地（优化体验，不至于App一进来就是空白）。
（3 ）设置请求超时限制。超时了，请求失败，仅仅只显示预设数据。就不会导致App一直处于Loading状态（优化体验）。
（4）分页加载，取少量数据进行展示。限制取10条数据，审核通过，解除这个限制（减少body size）。
弊端：这样设置两套服务器，在版本更新，服务器升级发布，会带来很大的维护成本，后面做了2，3，4的优化，撤销了AWS，直接使用了阿里云。
6 问题引发的思考：
出现这样的问题，一个原因测试人员测试用例覆盖不全，没有测试到这种情况。二是研发人员没有自己测试到这一点，没有经过多次连接VPN测试。在测试方面需要加强测试的用例的完整度，研发层面需要对app性能优化引起足够的重视，加强对app性能调优。
网友评论