QUIC的那些事 | QUIC为什么那么快

QUIC(Quick UDP Internet Connection)是谷歌提出的一种基于UDP的低时延的互联网传输层协议,QUIC的发音类似于Quick。实际上,QUIC确实很快。

QUIC解决了现代网站应用的一系列的传输层及应用层的问题,但只需要应用开发者几乎不用做出或者只做出很小的改变。QUIC和TCP+TLS+HTTP很类似,但是基于UDP实现,基于QUIC实现的HTTP协议被提议为HTTP3。

0RTT 建立连接可以说是 QUIC 相比 HTTP2 最大的性能优势。0RTT是指传输层0RTT建立连接(QUIC基于UDP,不需要三次握手)及加密层0RTT建立加密连接(注意是对于大多数连接,不是所有连接)。

QUIC可以不用等服务端的回包就直接下发报文,而一般的TCP+TLS连接在连接建立前需要等1-3个RTT。

 

TCP+TLS交互

三次握手的时间是1RTT(客户端发送ACK后,就可以直接下发报文),流程图如图 1 所示 

QUIC的那些事 | QUIC为什么那么快_第1张图片 图 1 三次握手RTT

 

TLS1.2(TLS1.1、TLS1.0逐渐被淘汰,暂且略过)的握手流程如图 2 所示,需要2RTT(从client_hello到虚线之间)。

QUIC的那些事 | QUIC为什么那么快_第2张图片 图 2 TLS1.2握手流程

 

为了减少TLS1.2的握手时间, TLS1.2中引入了会话缓存机制,其流程图如图 3所示,握手流程为3次交互,粗略看时1.5RTT,但是对于客户端在完成最后一次向服务端发送change_cipher_spec消息后可以立刻下发报文,因此是1RTT(上下两条虚线之间部分)。

QUIC的那些事 | QUIC为什么那么快_第3张图片 图 3 TLS1.2会话缓存机制下的握手流程        

 

TCP+TLS1.2的交互流程如图 4所示,一共需要3RTT后才可以进行应用层的数据交互(SYN到Application Data之间部分)。

QUIC的那些事 | QUIC为什么那么快_第4张图片 图 4 TCP+TLS1.2流程

对于图 4,引入TLS1.2的会话缓存机制后,也需要2RTT。

 

TLS1.3(2018年8月发布)的交互流程如图 5所示,需要1RTT,TCP+TLS1.3的时间就是2RTT。

QUIC的那些事 | QUIC为什么那么快_第5张图片 图 5 TLS1.3交互流程

 

TLS1.3会话恢复时的流程如图6所示,需要0RTT,此时TCP+TLS1.3的时间是1RTT。

QUIC的那些事 | QUIC为什么那么快_第6张图片 图 6 TLS1.3会话恢复流程图

 

QUIC交互

QUIC的流程如图7所示

QUIC的那些事 | QUIC为什么那么快_第7张图片  图 7 QUIC握手流程

 

QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥,初始密钥依赖于服务器存储的一组配置参数,该参数会周期性的更新。初始密钥协商成功后,服务器会提供一个临时随机数,双方根据这个数再生成会话密钥。

 

具体握手过程如下

(1) 客户端判断本地是否已有服务器的全部配置参数,如果有则直接跳转到(5),否则继续

 

(2) 客户端向服务器发送inchoate client hello(CHLO)消息,请求服务器传输配置参数

 

(3) 服务器收到CHLO,回复rejection(REJ)消息,其中包含服务器的部分配置参数

 

(4) 客户端收到REJ,提取并存储服务器配置参数,跳回到(1)

 

(5) 客户端向服务器发送full client hello消息,开始正式握手,消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数,可以计算出初始密钥。

 

(6) 服务器收到full client hello,如果不同意连接就回复REJ,同(3);如果同意连接,根据客户端的公开数计算出初始密钥,回复server hello(SHLO)消息,SHLO用初始密钥加密,并且其中包含服务器选择的一个临时公开数。

 

(7) 客户端收到服务器的回复,如果是REJ则情况同(4);如果是SHLO,则尝试用初始密钥解密,提取出临时公开数

 

(8) 客户端和服务器根据临时公开数和初始密钥,各自基于SHA-256算法推导出会话密钥

 

(9) 双方更换为使用会话密钥通信,初始密钥此时已无用,QUIC握手过程完毕。之后会话密钥更新的流程与以上过程类似,只是数据包中的某些字段略有不同。

 

对于图 7可以进行如下分解:

1. 客户端没有缓存服务端的配置参数,此时流程如图 8所示

QUIC的那些事 | QUIC为什么那么快_第8张图片 图 8 客户端没有缓存服务端配置参数流程

 

此时的最短时间是1RTT,为什么说是最短想时间?因为服务端发送其配置参数可能需要多次交互才能完成。

 

2. 客户端缓存服务端的配置参数,此时流程如图9所示

QUIC的那些事 | QUIC为什么那么快_第9张图片 图 9客户端缓存服务端配置参数流程

 

QUIC时间分析

如果要取得0RTT的时间,客户端需要缓存已经验证的服务端配置信息,即使缓存了服务端的配置信息,也可能在于服务器的交互过程中,需要更新配置信息,此时的时间就会大于0RTT。如果客户端和服务端是第一次交互,那么必须发送CHLO信令,获取服务端配置,而这个过程就可能耗费多个RTT,因为服务端一次不一定愿意向未验证身份的客户端一次发送大量的配置信息。

 

在客户端保存的服务端的配置信息有效且足够的情况下,QUIC握手能够取得0RTT的时间,这就是QUIC快的原因。

 

参考资料

1. https://www.cnblogs.com/huanxiyun/articles/6554085.html

2. https://www.cnblogs.com/syfwhu/p/5219814.html

3. QUIC Crypto

4. https://www.cnblogs.com/mod109/p/7372577.html

 

 

扫描二维码,关注“小眼睛的梦呓”公众号,在手机端查看文章 扫描二维码,关注“清远的梦呓”公众号,在手机端查看文章

你可能感兴趣的:(QUIC,网络通信)