Quic协议剖析

QUIC协议剖析及性能优化

如果你的App,在不需要任何修改的情况下就能提升15%以上的访问速度。特别是弱网络的时候能够提升20%以上的访问速度。如果你的App,在频繁切换4G和WIFI网络的情况下,不会断线,不需要重连,用户无任何感知。如果你的App,既需要TLS的安全,也想实现多路复用的强大。如果你刚刚才听说HTTP2是下一代互联网协议,如果你刚刚才关注到TLS1.3是一个革命性具有里程碑意义的协议,但是这两个协议却一直在被另一个更新兴的协议所影响和挑战。如果这个新兴的协议,它的名字就叫做“快”,并且正在标准化为新一代的互联网传输协议。你愿意花一点点时间了解这个协议吗?你愿意投入精力去研究这个协议吗?你愿意全力推动业务来使用这个协议吗?这篇文章,会告诉你答案。

背景

Quic全称quick udp internet connection[1],“快速UDP互联网连接”,(和英文quick谐音,简称“快”)是由google提出的使用udp进行多路并发传输的协议,特性有点类似基于TCP和TLS协议的http2。Quic相比现在广泛应用的http2+tcp+tls协议有如下优势[2]:

  • 减少了TCP三次握手及TLS握手时间。
  • 改进的拥塞控制。
  • 避免队头阻塞的多路复用。
  • 连接迁移。
  • 前向冗余纠错。

QUIC主要原理及优化

QUIC的特性大家可能听说得比较多,比如0RTT,安全等。但是关于QUIC的原理分析文章还比较少。比如为什么能实现0RTT,里面有什么风险,QUIC如何保障可靠性,工程实现方面需要注意什么问题等。
接下去我们就给大家深度剖析一下QUIC协议的主要特性。

0RTT建连

0RTT建连可以说是QUIC相比HTTP2最大的性能优势。那什么是0RTT建连呢?这里面有两层含义。
1.传输层0RTT就能建立连接。
2.加密层0RTT就能建立加密连接。

HTTPS及QUIC建连过程

比如上图左边是HTTPS的一次完全握手的建连过程,需要3个RTT。就算是Session Resumption,也需要至少2个RTT。
而QUIC呢?只需要0个RTT就能实现数据发送,并且0RTT的成功率相比TLS的Sesison Ticket要高很多。
下面我们分别介绍一下。

传输层0RTT建连

由于QUIC是构建在UDP协议[20]上,和TCP基于四元组的连接不同[19],UDP本身就没有连接的概念,第一个包就可以直接发送数据,没有RTT的延迟。
由于这是UDP协议本身的特性,比较好理解,不多做介绍。

加密层0RTT建连

TLS1.2版本之前,TLS协议至少需要一个RTT才能建立TLS连接(TLS1.3虽然支持0RTT建连[3],但由于没有正式发布,这里暂且不表)。
那QUIC是如何实现0RTT建立加密连接的呢?这里的关键有两点[4]:
客户端缓存ServerConfig。
服务端强制使用DH密钥交换算法。
什么是ServerConfig呢?简单来说就是一个服务端生成并且通过Rejection消息发送给客户端的凭证,有点类似TLS的SessionTicket[14]。
ServerConfig里包含的内容比较多,其中KEXS规定了密钥交换算法,PUBS传递了密钥交换算法的公钥。

1RTT握手

如果客户端没有收到ServerConfig消息,根本就不知道使用何种密钥交换算法,没有公钥信息,也就不可能实现0RTT握手。
所以对于全新的连接来说,至少要1RTT才能完成握手:

QUIC 1RTT 握手

其中的Rejection就会返回ServerConfig及证书等信息。在拿到ServerConfig消息后,客户端就能根据ServerConfig里面规定的算法和公钥,计算出对称密钥,然后将客户端的公钥和应用层内容发送给服务端。
服务端接收到客户端的公钥后,也能根据算法计算出对称密钥。总共经过1个RTT完成认证和密钥协商。

0RTT握手

明白了1RTT和DH算法,0RTT的实现也就非常好理解和实现了。

QUIC 0RTT握手

0RTT的前提是客户端必须已经拥有了ServerConfig,并且要结合证书验证ServerConfig消息,验证无误后就能够获取到密钥交换算法及公钥,此时再生成一个全新的密钥b,按照DH算法和参数,就能在本地计算出对称密钥Sc。
服务端收到客户端的ClientHello后,同时也包含了客户端的公钥信息,服务端也能结合之前的公钥参数计算出Ss。

0RTT的问题

加密层虽然能够实现0RTT,优势非常明显,但也引入了几个问题。

前向加密安全

为了提升0RTT的成功率,ServerConfig需要保存一个比较长的时间。在这段时间里,如果服务端密钥a(注意不是X509证书[23]的私钥)泄露,意味着此段时间里所有加密内容都能够被解密。这就是非前向加密的安全问题[17]。那如何解决这个问题呢?协议层面提供一个密钥升级的方案。

  • 客户端在接收到ServerHello前,使用Initial Key进行加密,这个Key是非前向安全的。
  • 服务端接收到ClientHello后,立即更新私钥a和ServerHello中的公钥,并生成全新的前向加密密钥S。
  • 客户端接收到ServerHello后,立即计算生成全新的前身加密密钥S。
    此后客户端和服务端都使用这个新的密钥S进行加解密,实现了前向加密安全。

这样做的好处是:

  • 保障了前向安全。
  • 提升0RTT的成功率。因为有前向安全,所以ServerConfig可以长时间地保存在服务端和客户端地硬盘里。相比TLS协议的Session Ticket及Session ID[15],由于不能保证前向安全,出于安全起见,默认保存在内存中,每次程序重载,都需要完全握手。这也是QUIC的0RTT成功率相比TLS Session Resumption成功率要高很多的原因。
签名计算的问题及优化

从前面的描述来看,ServerConfig非常重要。这么重要的信息自然需要签名来保证权威性和信任度。ServerConfig是如何签名的呢?使用X509证书中的私钥进行RSA签名[21]或者ECDSA签名[20]。而X509证书的RSA签名的私钥长度至少是2048位,非常消耗我们的CPU资源。
根据之前的测试数据,RSA私钥签名计算会降低90%的性能[18]。那如何优化呢?使用RSA或者ECDSA异步代理计算。核心思路也是三点:

  • 算法分离。剥离私钥计算部分,不让这个过程占用本地CPU资源。
  • 异步执行。算法剥离和执行异步的,上层服务不需要同步等待这个计算过程的完成。
  • 并行计算。我们使用配置了专用硬件的私钥计算集群来完成私钥计算。

图12 QUIC接入架构中的计算集群就是用来处理高强度私钥计算的。

ServerConfig命中率问题及优化

ServerConfig到达服务端后,我们根据ServerConfig ID查找本地内存,如果找到了,即认为这个数据是可信的,能够完成0RTT握手。但是会有两个问题:

  • 进程间ID数据无法共享。
  • 多台服务器间的ID数据无法共享。

那如何提升0RTT的命中率呢?同样地,工程层面需要实现多进程共享及分布式多集群的ID共享。
图12 QUIC接入架构中的Cache集群主要就是用来提升ServerConfig命中率的。

连接迁移(Connection Migration)

一条TCP连接是由四元组标识的(源IP,源端口,目的IP,目的端口)。什么叫连接迁移呢?就是当其中任何一个元素发生变化时,这条连接依然维持着,能够保持业务逻辑不中断。当然这里面主要关注的是客户端的变化,因为客户端不可控并且网络环境经常发生变化,而服务端的IP和端口一般都是固定的。
比如大家使用手机在WIFI和4G移动网络切换时,客户端的IP肯定会发生变化,需要重新建立和服务端的TCP连接。又比如大家使用公共NAT出口时,有些连接竞争时需要重新绑定端口,导致客户端的端口发生变化,同样需要重新建立TCP连接。
针对TCP的连接变化,MPTCP[6]其实已经有了解决方案,但是由于MPTCP需要操作系统及网络协议栈支持,部署阻力非常大,目前并不适用。所以从TCP连接的角度来讲,这个问题是无解的。 那QUIC是如何做到连接迁移呢?很简单,任何一条QUIC连接不再以IP及端口四元组标识,而是以一个64位的随机数作为ID来标识,这样就算IP或者端口发生变化时,只要ID不变,这条连接依然维持着,上层业务逻辑感知不到变化,不会中断,也就不需要重连。由于这个ID是客户端随机产生的,并且长度有64位,所以冲突概率非常低。
那TGW服务端如何实现的呢?我们在TGW四层转发层面实现了根据ID进行哈希的负载均衡算法,保证将相同ID的QUIC请求落到相同的STGW上,在STGW上,我们又会优先根据ID进行处理。图示如下:

QUIC连接迁移

如上图所述,客户端最开始使用4G移动网络访问业务,源IP假设为IP1,整个访问流程使用蓝色线条标识。当用户进入WIFI网络时,源IP发生了变化,从IP1切换到了IP2,整个访问流程使用绿色线条标识。
由于接入的TGW有可能发生变化,但整个TGW集群统一使用QUIC Connection ID调度,只要QUIC连接的ID没有发生变化,能够将该请求调度到相同的STGW。同一台STGW保存了相同的Stream及Connection处理上下文,能够将该请求继续调度到相同的业务RS机器。
整个网络和IP切换过程,对于用户和业务来讲,没有任何感知。

改进的拥塞控制

TCP的拥塞控制实际上包含了四个算法:慢启动,拥塞避免,快速重传,快速恢复[24]。
QUIC协议当前默认使用了TCP协议的Cubic拥塞控制算法[7],同时也支持CubicBytes, Reno, RenoBytes, BBR, PCC等拥塞控制算法。
从拥塞算法本身来看,QUIC只是按照TCP协议重新实现了一遍,那么QUIC协议到底改进在哪些方面呢?主要有如下几点:

可插拔

什么叫可插拔呢?就是能够非常灵活地生效,变更和停止。体现在如下方面:

  • 应用程序层面就能实现不同的拥塞控制算法,不需要操作系统,不需要内核支持。这是一个飞跃,因为传统的TCP拥塞控制,必须要端到端的网络协议栈支持,才能实现控制效果。而内核和操作系统的部署成本非常高,升级周期很长,这在产品快速迭代,网络爆炸式增长的今天,显然有点满足不了需求。
  • 即使是单个应用程序的不同连接也能支持配置不同的拥塞控制。就算是一台服务器,接入的用户网络环境也千差万别,结合大数据及人工智能处理,我们能为各个用户提供不同的但又更加精准更加有效的拥塞控制。比如BBR适合,Cubic适合。
  • 应用程序不需要停机和升级就能实现拥塞控制的变更,我们在服务端只需要修改一下配置,reload一下,完全不需要停止服务就能实现拥塞控制的切换。

STGW在配置层面进行了优化,我们可以针对不同业务,不同网络制式,甚至不同的RTT,使用不同的拥塞控制算法。

单调递增的Packet Number

TCP为了保证可靠性,使用了基于字节序号的Sequence Number及Ack来确认消息的有序到达。
QUIC同样是一个可靠的协议,它使用Packet Number代替了TCP 的sequence number,并且每个Packet Number都严格递增,也就是说就算Packet N丢失了,重传的Packet N的PacketNumber已经不是N,而是一个比N大的值。而TCP呢,重传segment的sequence number和原始的segment的Sequence Number保持不变,也正是由于这个特性,引入了Tcp重传的歧义问题。

Tcp 重传歧义性

如上图所示,超时事件RTO发生后,客户端发起重传,然后接收到了Ack数据。由于序列号一样,这个Ack数据到底是原始请求的响应还是重传请求的响应呢?不好判断。
如果算成原始请求的响应,但实际上是重传请求的响应(上图左),会导致采样RTT变大。如果算成重传请求的响应,但实际上是原始请求的响应,又很容易导致采样RTT过小。
由于Quic重传的Packet和原始Packet的Pakcet Number是严格递增的,所以很容易就解决了这个问题。

Quic重传没有歧义性

如上图所示,RTO发生后,根据重传的Packet Number就能确定精确的RTT计算。如果Ack的Packet Number是N+M,就根据重传请求计算采样RTT。如果Ack的Pakcet Number是N,就根据原始请求的时间计算采样RTT,没有歧义性。
但是单纯依靠严格递增的Packet Number肯定是无法保证数据的顺序性和可靠性。QUIC又引入了一个Stream Offset的概念。
即一个Stream可以经过多个Packet传输,Packet Number严格递增,没有依赖。但是Packet里的Payload如果是Stream的话,就需要依靠Stream的Offset来保证应用数据的顺序。如图7 Stream Offset保证有序性所示,发送端先后发送了Pakcet N和Pakcet N+1,Stream的Offset分别是x和x+y。
假设Packet N丢失了,发起重传,重传的Packet Number是N+2,但是它的Stream的Offset依然是x,这样就算Packet N + 2是后到的,依然可以将Stream x和Stream x+y按照顺序组织起来,交给应用程序处理。

Stream Offset保证有序性

不允许Reneging

什么叫Reneging呢?就是接收方丢弃已经接收并且上报给SACK选项的内容[9]。TCP协议不鼓励这种行为,但是协议层面允许这样的行为。主要是考虑到服务器资源有限,比如Buffer溢出,内存不够等情况。
Reneging对数据重传会产生很大的干扰。因为Sack都已经表明接收到了,但是接收端事实上丢弃了该数据。
QUIC在协议层面禁止Reneging,一个Packet只要被Ack,就认为它一定被正确接收,减少了这种干扰。

更多的Ack块

TCP的Sack选项能够告诉发送方已经接收到的连续Segment的范围,方便发送方进行选择性重传。

由于TCP头部最大只有60个字节,标准头部占用了20字节,所以Tcp Option最大长度只有40字节,再加上TcpTimestamp option占用了10个字节[27],所以留给Sack选项的只有30个字节。

每一个Sack Block的长度是8个,加上Sack Option头部2个字节,也就意味着Tcp Sack Option最大只能提供3个Block。

但是Quic Ack Frame可以同时提供256个Ack Block,在丢包率比较高的网络下,更多的Sack Block可以提升网络的恢复速度,减少重传量。

Ack Delay时间

Tcp的Timestamp选项存在一个问题[27],它只是回显了发送方的时间戳,但是没有计算接收端接收到segment到发送Ack该segment的时间。这个时间可以简称为Ack Delay。

这样就会导致RTT计算误差。如下图:

可以认为TCP的RTT计算:

RTT = timestamp2 - timestamp1

而Quic计算如下:

RTT = timestamp2 - timestamp1 - ACK delay

当然RTT的具体计算没有这么简单,需要采样,参考历史数值进行平滑计算,参考如下公式[10]。

改进的多路复用

多路复用是HTTP2最强大的特性[8],能够将多条请求在一条TCP连接上同时发出去。但也恶化了TCP的一个问题,队头阻塞[12],如下图示:

图8 HTTP2队头阻塞

HTTP2在一个TCP连接上同时发送4个Stream。其中Stream1已经正确到达,并被应用层读取。但是Stream2的第三个tcp segment丢失了,TCP为了保证数据的可靠性,需要发送端重传第3个segment才能通知应用层读取接下去的数据,虽然这个时候Stream3和Stream4的全部数据已经到达了接收端,但都被阻塞住了。

不仅如此,由于HTTP2强制使用TLS,还存在一个TLS协议层面的队头阻塞[13]。

TLS队头阻塞

Record是TLS协议处理的最小单位,最大不能超过16K,一些服务器比如Nginx默认的大小就是16K。由于一个record必须经过数据一致性校验才能进行加解密,所以一个16K的record,就算丢了一个字节,也会导致已经接收到的15.99K数据无法处理,因为它不完整。

那QUIC多路复用为什么能避免上述问题呢?

-QUIC最基本的传输单元是Packet,不会超过MTU的大小,整个加密和认证过程都是基于Packet的,不会跨越多个Packet。这样就能避免TLS协议存在的队头阻塞

  • Stream之间相互独立,比如Stream2丢了一个Pakcet,不会影响Stream3和Stream4。不存在TCP队头阻塞。

QUIC多路复用时没有队头阻塞的问题

当然,并不是所有的QUIC数据都不会受到队头阻塞的影响,比如QUIC当前也是使用Hpack压缩算法[11],由于算法的限制,丢失一个头部数据时,可能遇到队头阻塞。
总体来说,QUIC在传输大量数据时,比如视频,受到队头阻塞的影响很小。

流量控制

UDP协议本身没有滑动窗口,也没有流量控制的机制,那QUIC是如何实现流量控制的呢?

QUIC的流量控制[24]类似HTTP2,即在Connection和Stream级别提供了两种流量控制。为什么需要两类流量控制呢?主要是因为QUIC支持多路复用:

  • Stream可以认为就是一条HTTP请求。
  • Connection可以类比一条TCP连接。多路复用意味着在一条Connetion上会同时存在多条Stream。既需要对单个Stream进行控制,又需要针对所有Stream进行总体控制。

QUIC实现流量控制的原理比较简单:

  • 通过window_update帧告诉对端自己可以接收的字节数,这样发送方就不会发送超过这个数量的数据。
  • 通过BlockFrame告诉对端由于流量控制被阻塞了,无法发送数据。
    QUIC的流量控制和TCP有点区别,TCP为了保证可靠性,窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包,就算接收到了更大序号的Segment,窗口也无法超过这个序列号。但QUIC不同,就算此前有些packet没有接收到,它的滑动只取决于接收到的最大偏移字节数。

Quic Flow Control

针对Stream:

可用窗口 = 最大窗口数-接收到的最大偏移量

针对Connnection

可用窗口 = stream1可用窗口 + stream2可用窗口 + stream N可用窗口

同样地,STGW也在连接和Stream级别设置了不同的窗口数。最重要的是,我们可以在内存不足或者上游处理性能出现问题时,通过流量控制来限制传输速率,保障服务可用性。

其他亮点

此外,QUIC还能实现前向冗余纠错,在重要的包比如握手消息发生丢失时,能够根据冗余信息还原出握手消息。
QUIC还能实现证书压缩,减少证书传输量,针对包头进行验证等。
限于篇幅,本文不再详细介绍,有兴趣的可以参考文档[25]和文档[4]。

STGW QUIC接入架构

考虑到前端接入的重要性和业务安全,下图只是简略地描述了一下STGW在协议接入特别是QUIC协议接入的架构。

QUIC接入架构

简单说一下流程:

  • 用户侧使用的各种请求,首先接入四层TGW。
  • 如果是QUIC协议,四层TGW使用ID负载均衡算法将请求转发到STGWQUIC集群。如果是非QUIC协议,使用用户配置的各种负载均衡算法进行转发。
    请求落到STGW集群后,会做一些判断,如果需要私钥计算(比如TLS完全握手),会将部分重要参数转发到私钥计算集群进行高强度计算。如果需要查询Session ID或者
  • ServerConfig ID,会做一些缓存查询。这样能够减少计算量,也能减少握手时间。
  • STGW接下去会将QUIC/HTTP2/HTTPS协议统一转换成HTTP1.1请求。由于QUIC使用的是UDP协议,HTTP1.1使用的是TCP,也就是说UDP协议的内容经过转换后会使用TCP进行转发。
  • 业务集群只需要处理HTTP1.1协议即可。如果是自定义的私有协议,我们也支持TCP/UDP透明转发,由业务自行处理。

测试结论

由于公司内网的WIFI环境不稳定,多次测试发现数据跳动较大,4G环境下的数据更加稳定可靠,所以主要结论参考4G网络下的数据。
比较4G网络下各个协议的表现,Quic的优势很明显,结论如下:

域名 元素个数 首字节时间 页面加载时间
QUICvs HTTP 3/24 +0% +36%
QUICvs HTTP 3/24 +0% +36%
QUIC vs HTTP2 3/24 +39.9% +47.5%
QUIC vs HTTPS 3/24 +47.4% +64%
QUICvs HTTP 3/12 +8% +9%
QUIC vs HTTP2 3/12 +29% +42.3%
QUIC vs HTTPS 3/12 +37.7% +52.8%

可以看出QUIC的优势非常明显,即使在元素比较少(12个元素)的情况下,相比HTTP也能提升9%,相比HTTP2提升42%,相比HTTPS提升52%。
在页面元素增多的情况下,QUIC的优势就更加明显,相比HTTP提升36%,相比HTTP2提升47%,相比HTTPS提升64%。

结论

QUIC协议非常复杂,因为它做了太多事情:

  • 为了实现传输的可靠性,它基本上实现并且改进了整个TCP协议的功能,包括序列号,重传,拥塞控制,流量控制等
  • 为了实现传输的安全性,它又彻底重构了TLS协议,包括证书压缩,握手消息,0RTT等。虽然后续可能会采用TLS1.3协议,但是事实上是QUIC推动了TLS1.3的发展。
  • 为了实现传输的并发性,它又实现了HTTP2的大部分特性,包括多路复用,流量控制等。
  • 虽然如此复杂,但是QUIC作为一个新兴的协议,已经展现了非常强大的生命力和广阔的前景。目前国内外除了Google大规模采用外,还鲜有其他互联网公司使用。
posted @ 2017-08-26 21:14  被罚站的树  阅读(883)  评论(0编辑  收藏  举报