产品解决方案安全专区定价 WeTest生态支持与服务关于WeTest

QUIC协议的分析，性能测试以及在QQ会员实践

服务端性能 2018-05-10 19:19 54076

基于高效的UDP协议有没有一种相对可靠的应用层协议呢？

WeTest 导读

你听过HTTPS、HTTP2.0、SPDY，但是这些应用层协议都是基于可靠的传输层协议TCP来实现的。那么，基于高效的UDP协议有没有一种相对可靠的应用层协议呢？

Why QUIC?

你听过HTTPS、HTTP2.0、SPDY，但是这些应用层协议都是基于可靠的传输层协议TCP来实现的。那么，基于高效的UDP协议有没有一种相对可靠的应用层协议呢？

图1 why quic?

What is QUIC?

Quick UDP Internet Connection(QUIC)协议是Google公司提出的基于UDP的高效可靠协议。

说它高效，是因为使用了无连接的UDP而不是迭代周期更长的需要修改系统内核网络栈的TCP协议。
说它可靠，是因为将改进了的可靠TCP的协议特征用到了QUIC上。

同时，也复用和改进了HTTP2的典型特征，譬如二进制分帧，多路复用，header压缩等。

图2 what's quic?

How QUIC works?

建立连接

一、基于TCP+TLS的HTTP2建连

出于HTTP的明文和无法验证服务器的真实性，在TCP的基础上引入了TLS协议，目前广泛使用的HTTPS是基于TCP+TLS协议，HTTP2也被主流浏览器默认支持TLS。

但对于建立连接的耗时而言，TCP本身就需要握手时延，而TLS协议为了使得客户端和服务器端在不安全的网络通信中协商出后续安全通信所需的加密私钥，更是要经过额外2次RTT(RoundTrip Time往返时间)

图3 TCP+TLS建连过程

除了TCP建立连接过程，TLS握手过程要经过如下步骤：

1、客户端提供加密套件（算法）列表，版本等信息

2、服务器端提供自己的证书，选择的加密套件，非对称加密公钥（自己保留私钥）等

3、客户端提供自己的证书，用服务器公钥和加密套件加密的自己的私钥

4、服务端用保留的私钥解密客户端传来的加密私钥，得到的私钥即为后续加密传输使用的对称密钥，最后完成握手

此时，双方协商出了对称密钥。基于TCP+TLS的HTTP2建连过程结束，大约需要耗时200-300ms。

二、 QUIC建连

为了保证安全，QUIC也是加密传输数据的，所以在QUIC的建连过程中也需要双方协商出一个加密私钥。但与TLS不同，QUIC采用的加密算法仅需要一个RTT就能实现密钥交换，并且该算法也被用于目前正在草案阶段的TLS1.3协议。该就是Diffie-Hellman密钥交换算法。

图4 Diffie-Hellman算法

可以看到，客户端和服务端各自保留了自己的私钥a和b，通过交换各自的公钥B和A，以及基底G和很大的质数P，双方就能计算出相等的私钥S，这个S就是加密传输的对称密钥。

另外，根据离散对数的不可逆，即使拿到G,P,和质数B，也很难推导出私钥b（同理私钥a），也就保证了计算密钥的安全。

该过程对应到QUIC建连的过程中如下图。

图5 1RTT建连

1、客户端发起Inchoate client hello

2、服务器返回Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到server config中传给客户端

3、客户端发起client hello，包括客户端公钥信息

此时，双方各自计算出了对称密钥。QUIC的1RTT建连过程结束，平均只耗时100ms以内。

后续发起连接的过程中，一旦客户端缓存或持久化了server config，就可以复用并结合本地生成的私钥进行加密数据传输了，不需要再次握手，从而实现0RTT建立连接。

协商升级

一般情况下，Chrome浏览器和服务器端协商使用QUIC协议要经过如下步骤：

1、客户端发出tcp请求

2、服务端如果支持quic可以通过响应头alt-svc告知客户端

3、客户端同时发起tcp连接和quic连接竞赛

4、一旦quic建立连接获胜则采用quic协议发送请求

5、如遇网络或服务器不支持quic/udp，客户端标记quic为broken

6、传输中的请求通过tcp重发

7、5min后尝试重试quic，下一次尝试增大到10min

8、一旦再次成功采用quic并把broken标记取消

其中，支持quic的alt-svc头部信息如下图示，ma为有效时间（单位秒），v为支持的quic版本信息。

图6 alt-svc头信息

研究过程中发现，除了alt-svc header，http2.0下服务端还可以通过支持alt-svc frame来让客户端在第一次请求的时候就走新协议，比通过header让浏览器第二次才能请求新协议更高效，这个留给后续研究。

连接迁移

TCP使用四元组（源IP，源端口，目的IP，目的端口）来标识一条连接，当四元组中的IP或端口任一个发生变化了连接就需要重新建立，从而不具备连接迁移的能力。

而QUIC使用了connection id对连接进行唯一标识。即使网络从4G变成了wifi，只要两次连接中的connection id不变，并且客户端或者服务器能通过校验，就不需要重新建立连接，连接迁移就能成功。

改进的多路复用

在SPDY协议出现以前，每个HTTP请求都需要建立一条TCP连接，那么如果希望请求并行，就需要同时开启多条TCP连接（都是有建连代价的）。而大多数浏览器对于同一个域名可以建立的最大TCP连接数是有限制的，所以，如果超出限制，更多的请求资源是无法并行的。

SPDY协议以来提出的多路复用，是让所有请求基于一条TCP连接，解决了上述的问题但同时引入了新的问题——队头阻塞，如果某个资源的某个包丢失了，因为TCP是保证时序的，就会在接收端形成队头阻塞，TCP此时无法区分各个资源的包是否关联，因此会停止处理所有资源直到丢包恢复。

图7 基于TCP的多路复用

QUIC也有多路复用，但是QUIC是基于UDP的，UDP不需要保证包的时序，只会在接收包的时候对包进行重组，因而不存在等待丢包恢复的队头阻塞问题，这样某个资源的包丢失只会影响自身不会影响到其他资源的继续传输，所以是改进的多路复用。

图8 基于QUIC的多路复用

双级别流量控制

QUIC是多路复用的，多条stream可以建立在一条connection上，所以QUIC的流量控制不仅基于单个stream，还基于connection。

stream级别的流控能够控制单stream的数据发送情况。另外，接收窗口的收缩取决于最大接收字节的偏移而不是所有已接受字节的总和，它不像tcp流控，不会受到丢失数据的影响。

图9 stream流控

如果满足(flow control receive offset - consumed bytes) < (max receive window / 2)
会触发WINDOW_UPDATE frame的发送来增大发送窗口大小。

图10 WINDOW_UPDATE触发前

图11 WINDOW_UPDATE触发后

connection级别流控算法和stream一致，各项数值是所有stream的总和。

connection级别的流控存在的必要是，即使做好了stream流控，但如果stream过多也会导致connection过度消耗带宽和系统资源；而且即使某一条stream过慢，其他stream依然能触发

connection级别的WINDOW_UPDATE，从而不会被影响。

图12 connection流控

拥塞控制

我们知道TCP有多种拥塞控制算法，当遇到网络拥塞会通过减包等方式来避免网络环境恶化。但是，UDP本身是没有拥塞控制的，一旦不加约束的使用会导致侵占其他“守规矩”的网络协议的带宽。

所以，为了避免上述情况，基于UDP的QUIC协议借鉴了TCP的一些优秀的拥塞控制算法，如默认使用Cubic，同时，为了避免AIMD机制带来的带宽利用率低，采用了packet pacing来探测网络带宽。

思路是，QUIC会通过追踪包的到达时间来预测当前带宽的使用情况，以决定是否提高，保持或者减少发送包的速率来避免网络拥塞。

图13 packet pacing

丢包恢复

类似拥塞控制，除了基于TCP的一些丢包恢复机制，如：TLP，FACK。QUIC的丢包恢复也在一些方面做了改进。

比如：通过引入严格递增的sequence number使得计算RTT更加精确。更精确的RTT也意味更精确的RTO和超时重传机制。

还比如我们知道TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。

除了上述基于TCP的改进的丢包恢复特性以外，早期的QUIC版本还有一个丢包恢复机制，就是FEC（Forward Error Correction），这个特性虽然目前处于正在改造阶段（可能会浪费带宽并且作用不是很明显），但是依然是一个有意思的解决方案。FEC的思路是通过在一组包（一般是10个）中，通过增加一个FEC包，并用FEC和每个包进行XOR，如果一旦有丢包，那么将FEC包和其余包XOR，得到的FEC包就是那个丢包，所以一组包最多只能恢复一个丢包。

更多特性

除了上述的主要特性，QUIC还有一些其他特性，如：

● 通过header stream保证流顺序

● 底层保证连接持久

● 源地址令牌防止地址欺骗

● 握手时压缩证书避免放大攻击

在此不深入研究，大家有兴趣可以翻阅Google相关的文档查阅。

业界应用情况

● Google超过50%的请求来自QUIC

● 目前Youtube有20%的流量来自QUIC

● 微博移动端全面支持QUIC协议

测试demo

● 客户端
最新版本PC Chrome（控制开启/关闭quic）

● 服务器
经stgw改造支持quic的nginx

● 页面地址（机器被回收，后续会更换机器供测试）
https://stgwquic.kof.qq.com/club/platform/act/gift/test1.html
https://stgwquic.kof.qq.com/club/platform/act/gift/test2.html
https://stgwquic.kof.qq.com/club/platform/act/gift/test3.html

● 网络
公司staffwifi

● 抓包工具
wireshark

● 效果对比

图15 HTTP1.1协议的页面

图16 HTTP2协议的页面

图17 QUIC协议的页面

图18页面请求20个，大小2MB

图 19 页面请求15个，大小465KB

公司业务接入步骤

● 客户端支持
X5内核团队（移动端）

依赖用户浏览器支持QUIC情况（PC端）

● 服务端支持

STGW团队

● 业务自身
按照路径灰度，控制灰度策略

QQ会员页面接入效果

以上测试demo数据是基于公司良好的网络情况下测试得到的，在实际运用过程中，大家可能更关心在复杂的网络环境下QUIC的表现。于是QQ会员团队通过灰度现网的一个页面来考察QUIC在现网的性能情况。

● 页面情况
Android日PV100w，页面大小95KB
总请求30个，其中主资源请求1个，CDN请求24个，其他请求5个
展示部分依赖php直出和js渲染

● 灰度情况
QUIC请求1个（php页面主资源），HTTP2请求29个

● 灰度策略
客户端每天放量，对比灰度过程中页面主资源的HTTP2和QUIC的性能数据

● 灰度效果

图20 QQ会员页面QUIC灰度情况

● 效果说明
因为建连依赖于1RTT和0RTT机制，使得QUIC建连平均耗时仅需46ms，比HTTP2的225ms减少180ms左右。

由于目前灰度量只占到总请求量的10%，因此更严谨的性能对比数据有待进一步提高灰度范围，以上仅作现阶段参考。

但依然可以看到QUIC在现网环境总体表现忧于HTTP2。

注意问题

在实践QUIC的过程中，我们也遇到了一些需要注意的问题。

● QUIC支持头部alt-svc的缓存机制面向整个域名
业务即使只在一个页面路径下加了支持头部（STGW可以是路径级别支持，X5只能是域名级别支持），浏览器也会根据头部的缓存时长作用于用户访问该域名下的其他页面，但STGW可能只支持了路径级别。所以灰度过程中，尽量使用有独立域名的页面。从而保证尽量不影响其他页面的请求情况（虽然QUIC请求失败会降级H2），尽量减少ma缓存时间。

● 客户端对于QUIC的协商机制有待改善
在X5目前的实现机制中，无论如何首次请求都会基于HTTP2，后续才会尝试QUIC，但如果缓存时间设置的不够长（譬如1天），会使得用户一般1天内很难通过再次请求走到QUIC。所以，目前我们做的是推动X5在请求时候让白名单链接直接尝试QUIC。同时，避免缓存时间随着用户退出手Q而失效，推动让其落地。

● 目前客户端基于X5的QUIC与一些基于缓存和预加载的页面秒开方案冲突
如果你们的页面是基于X5内核，但是使用了上述类似的技术，那么存在一个问题是原本直接通过X5走QUIC协议的页面不直接走X5了，而是基于你当前方案的缓存或者自定义的webview请求方式。于是通过统计数据会发现QUIC的请求量很少，因为上述技术目前还不支持QUIC协议。当前的做法是在QUIC和该方案中二选一。

● CDN请求灰度需要自支持
由于CDN请求不基于STGW代理，因而需要CDN团队针对业务方域名灰度支持，目前CDN整体处于运营商灰度QUIC阶段。在此之前如果需要灰度CDN请求就需要业务方自己处理转发。

● 运营商的Qos影响需要更完善的上报数据进行评估
使用QUIC协议比较担心的一个问题就是在网络质量差的情况下运行商Qos会对其产生怎样的影响。从目前整体的统计数据，包括慢速用户占比等情况来看，影响不是很大。后续需要推动各方完善上报监控该情况下耗时。

未来工作List

● 和X5团队一起解决首次请求必走HTTP2请求问题

● 和X5团队一起解决alt-svc缓存有效期落地问题

● 和终端团队一起解决秒开方案下Webview对QUIC的支持，争取既能使用QUIC协议又能使用秒开方案

● 配合CDN团队验证QUIC扩大灰度的支持效果

● 推动各方更细粒度的数据统计完善

参考资料

http://www.chromium.org/quic

https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit

QUIC Crypto Adam Langley Wan-Teh Chang