记一次网络性能优化
-
基于Alexa的功能认证时，遇到了PTS（Push to Stream Delay）的问题，看第三方认证文档大概意思就是，你与Alexa的云端建立连接过程不应该超过1.75s。
而做过Alexa的downchannel连接的同学都知道，这是一个长连接，只能通过系统自带的urlsession来完成。
首先通过本地log，我发现从开始发送网络请求到收到数据，最快基本都是2s左右
2021311-14294.png
而通过对Alexa的网络请求抓包
我发现charles上的数据显示是request start time 和response start time之间只相差了1s都不到。
那么问题猜测就可能出现在resume()这个方法上了，
这个方法的官方文档解释是：
新初始化的任务以挂起状态开始，因此您需要调用此方法来启动任务。
查看了很多资料，对resume方法也没有做过多解释，理论上是这个方法被调用之后，之后的所有的网络连接和操作都被系统接管了，猜测这个resume导致网络request请求延迟1s是系统要去对当前session会话做tcp三次握手连接耗时。如下图流程：
看来关于网络的抓包，charles也只能帮我到这里了，因为我现在想了解的不再是应用层的信息，我想看到这个东西关于非应用层的一些数据情况包括耗时是否使我们猜测的那样。
那只能请出wireshark了，关于wiresharkr如何抓包这里就不细说，直接看结果。
我们先来看下从代码开始resume()之后的一次网络请求：
通过上面两张图，我们可以清晰的看到整个网络链路：
- 访问HTTPS的TCP三次握手成功 消耗时间
- 和TLS握手第一阶段 Say Hello
- 和TLS握手第二阶段 交换加密
- 第一个HTTPS请求
从TCP第一次握手，我看可以看到到达时间是：
2021 11：05：59：182975000
中间经过TCP三次握手成功后
TLS握手相互say Hello完成，再到client和service两端交换加密信息，直到Server 发送它自己ChangeCipherSpec 消息，Client 和 Server 可以开始交换应用层数据。
通过第二张图我们可以看到交换应用数据，其到达时间是：
2021 11：06：00：187548000
可以看到整个链路层耗时在1s左右。
接下里我们看看我们本地的log打印
resume()开始调用时间是：
2021 11：05：58：734805
而收据接收到的时间是
2021 11：06：00：118978
可以看到代码的整个耗时大概是2s左右。
而握手完成的时间在：
2021 11：06：00：187548
这也符合了charles抓包的Alexa的request time不足1s。
根据上面的这些数据，我们现在可以确定的一件事情就是resume()方法调用之后，tcp建立连接耗时1s。
通过wireshark工具我们也可以看出，
- DNS Query需要1个RTT（Round-Trip Time，即往返时间），
- TCP要经历SYN，SYN/ACK，ACK三次握手的1.5个RTT，不过ACK和ClientHello合并了，所以就是1个RTT。
- TLS（Transport Layer Security，即传输层安全性协议）需要经过握手和密钥交换2个RTT。
综上所述，DNS，TLS，TCP握手阶段用了4个RTT才到了ApplicationData阶段。
通过上面的分析可以总结出，如果我们能尽量的将TLS和TCP的RTT减少，将会大大降低连接耗时的时间。
说了这么多，也已经知道了问题的关键点所在，那么我们该怎么处理呢？
首先我们无法去和服务端一起配合减少协议层的交互时间。那么我们应该从哪个方面去入手呢？
我们都知道iOS8就推出的URLSession就已经支持HTTS2连接了，那么就可以利用TCP连接复用的特性来处理这个问题。
既然有了思路，那么解决起来也很快呀，我们知道session每一次创建，都会为其task建立一条TCP连接，
首先我们必须让自己的session建立好连接（确认耗时时间），如果在第一个task建立连接阶段，再新增一个task，那么这两个task很显然也无法复用。所以要保证两个task添加的间隔时间大于session建立好的连接时间。
这么一分析，那么解决方案就呼之欲出了。
既然downchannel连接建立耗时超过认证时间，那么我们可以在downchannel建立之前，先让我们的session建立好tcp连接，等到真正要用到downchannel的时候就自然复用了我们的session，时间节约了1s。
