QUIC浅析

在之前学习Android–网络性能优化：弱网优化（传送门：Android 网络性能优化（4）弱网优化）的过程中，挖掘出了QUIC这个东西，它是基于UDP协议的极致优化、是Http/3的实现方案，所以趁热打铁，来学习一下QUIC它神奇在什么地方。

1. 概述

QUIC 全称为 Quick Udp Internet Connection，中文直译 “快速Udp互联网连接”，英文念法同 “Quick”，最早是由Google提供的使用udp进行多路并发传输的协议。

1.1 设计背景及发展历史

2012~2013年：Google设计了一种实验性的网络传输协议，基于UDP协议，一端到一端的连线，且支持多路复用，并将其命名为QUIC。
设计的初衷是提供基于TLS/DTLS的网络安全保护，减少创建连接和数据传输的时延，双向控制带宽，以避免网络拥塞。

2015年6月：QUIC的网络草案被正式提交至 互联网工程任务组（IETF），即制定过Tcp/ip协议族标准的组织。

2018年10月：互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP（英语：HTTP over QUIC）重命名为HTTP/3以为确立下一代规范做准备。

PS：这也标志着围绕着Tcp的Http最终也依赖到Udp协议了…真可谓活久见

1.2 QUIC特性介绍

QUIC最最最突出的特点就是使用Udp，这是也是协议“快”的根本，来看看QUIC有哪些优点吧：

以下特点对比 http2+tcp+tls：

1. 减少TCP三次握手以及TLS握手时间
2. 改进的拥塞控制
3. 避免队头阻塞的多路复用
4. 连接迁移

1.3 为什么使用QUIC

quick的反义词是slow，而slow则形容了当前互联网的协议使用。
从上世纪90年代互联网兴起到现在，大部分的互联网流量传输至使用了几个网络协议，例如IPv4、TCP、SSL/TLS、DNS、HTTP。

IPv4实现了较大的进步，即IPv6，DNS也有DNSSEC来增加安全扩展，但是它们部署进度很慢，普及率不高。
TCP的改进主要是控制算法的改进，而SSL/TLS最近的改变是升级到了TLS1.3，虽然有飞跃式的进步，目前国内据我所知的App像微信、QQ有在使用。

互联网速度起飞后，用户的使用场景对传输性能的要求越来越高，另一方面上述的古老的网络协议问题层出不穷，这就导致了越来越多的矛盾和问题， 列举一下：

1. 连接建立的握手步骤多，延迟大
2. 协议历史悠久导致中间设备僵化
3. 依赖于操作系统的实现导致协议本身僵化
4. Http请求容易产生队头阻塞

而QUIC的出现是为了解决这些问题，在弱网环境下，使用QUIC，相比于原始的Http/1.1、Http/2 都有很好的表现，这也是我们需要学习QUIC的原因。

在下一节，来具体介绍下QUIC的每一个特点，以及它能解决怎样的问题。

2. QUIC特性

2.1 连接建立时延低

0RTT，这个TCP/TLS绕不开的话题，在各大介绍TLS1.3或者QUIC的文章中，TLS1.2都是首当其冲拿出来做对比的，当然也有魔改：在TLS1.2版本上实现0RTT，但我们不谈这些黑科技。

下图是HTTP Over TLS1.2首次连接的握手，其中TCP的第三次握手和TLS的第一次握手结合：

这个过程由于太长，在复杂的网络情况下的连接建立容易产生较大时延，所以优化的方向比较统一：在保证安全的情况下，尽可能减少握手交换数据，加快连接的速度

TLS1.3则实现了1RTT，甚至0RTT，而QUIC因为是基于Udp协议，所以也可做到0RTT。
这里讲一个TLS1.3和QUIC的事情，在2018年之前，因为TLS1.3还没有正式发布，所以QUIC使用的是自研的0RTT方式，叫做 QUIC crypto protocol。所以看2018年之前的文章，会发现两者达到0RTT的方式是不一样的。而在2018年TLS1.3正式发布，QUIC又和TLS同属IETF组织，所以自然而然的，QUIC统一使用TLS1.3作为安全协议。

The QUIC crypto protocol is the part of QUIC that provides transport security to a connection. The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.

感谢Google减少我们这些码农的学习成本~ 我们只需要弄清楚TLS1.3是如何实现0RTT的，就也能弄懂QUIC的了。

2.1.1 TLS1.3实现1RTT

首先看下TLS1.2协议握手图：

整个过程是2RTT，因为比较熟悉，就不再讲中间过程了。

接下来看下TLS1.3如何做到1RTT，看下面握手图：

来看下握手全程：

1. 客户端发送：①：ClientHello，包含Cipher Suite（密码套件），②：Key Share（DH密钥交换参数列表）
2. 服务端回复：①：ServerHello，包含 所选Cipher Suite，②：服务器证书，③使用证书对应的私钥对握手消息签名，将结果发出，④：选用客户端提供的DH参数生成临时公钥，并将公钥通过Key Share发送出去
   除此之外，结合选定的DH参数计算出用于加密Http的共享密钥
3. 客户端接收到 Key Share后，使用证书公钥对签名进行验证，获取服务端的公钥，并生成共享密钥
4. 双方使用生成的共享密钥进行加密传输，完成TLS握手

相比于TLS1.2，TLS1.3最大改动其实就是去掉了 RSA的密钥交换，也就是TLS握手中的唯一一次非对称加密（不算签名验证）。
所以握手的时候，就不会再去发送那些和非对称加密相关的数据了，比如 客户端服务端随机数 Server/Client KeyExchange、声明消息加密的信号 ChangeChiperSpec，还有 Pre-master Secret随机数。
TLS使用非对称加密的原因，是为了双方安全的算出 Master Secret，从而算出公共密钥。而TLS1.3版本移除掉了这个非对称加密，那就需要使用别的方式来弥补，所以使用到了 Key Share，它是一种前向安全的协议/算法，这里不多做解释，总之 DH四一中用于密钥交换的算法。

2.1.2 TLS1.3实现0RTT

因为Http是无状态的，所以就有了Cookie、Session的概念，Session ID 和 Session Ticket是会话的缓存，放在客户端和服务端的Cookie中，便于服务端来识别客户端。

在 TLS1.2中，如果客户端已经访问过了服务端，那么可以通过 Session Ticket在下次连接时快速建立握手，达到1RTT。这个行为叫做 恢复会话。

TLS1.3也是利用了这个机制实现0RTT的。客户端在第一次发送数据时，直接发送加密的应用数据，会话就正式进行。
虽然很快，但是不能保证前向安全，如果攻击者通过某种手段获取到 Session Ticket，那么该攻击者就可以解密以前的加密数据。

可以看到无论是第一次握手、还是恢复会话握手，TLS1.3都比TLS1.2少一个RTT，时间上是快了一倍，这也是为什么TLS1.3 daft草案被提出后，这么受欢迎的原因。

2.1.3 传输过程加密报文

上述说到QUIC是使用TLS1.3的，所以所有的UDP包都会经过加密，在防盗上是做足了保护。
而TCP协议的头部是没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改、注入和窃听。而QUIC的加密可以说是武装到牙齿。

2.2 无队头阻塞的多路复用

Http/2最强大的功能就是多路复用，QUIC的实现和Http/2类似，并且在其之上做了改进。我们先来看下Http2的不足之处。

2.2.1 Http2的多路复用和缺点

Http2多路复用的实现方案是：同域名请求共用一条TCP通道，这样可以减少多次Tcp握手所带来的消耗。
Http/1.1的Keep Alive实现多路复用，缺点是请求串行，如果服务器还在处理前面的请求，那么后面的请求就会阻塞，产生了 “队头阻塞” ，而Http2则通过数据流（Stream）以帧为基本协议单位，从根本上解决了这个问题。

但是即使如此，Http2的多路复用也有它的弱点：TCP的重传机制，这导致包的丢失会让整个通道停下来等待重传（停止等待协议的等待和滑动窗口的回退）。
例如下面是一个Http2的Tcp通道，客户端发送了4个数据流：stream1、2、3、4给服务端， 第一个流已经到达，但是第二个流的第三个Tcp segment丢失，那么Tcp为了保证了传输的可靠性，会重新发送 stream2、3、4，这导致了即使原来的Stream3、4已经到达了服务端，但是服务端并不会先处理，而是阻塞等待Stream2处理。

2.2.2 QUIC实现多路复用

QUIC多路复用的实现方案是：同域名请求共用一条UDP通道，这样不仅省去了TCP连接，也没有Tcp的重传机制，在一条QUIC连接上，多个请求之间是没有依赖的，一个请求的丢失不会影响到其他的请求。 如下图所示：

那就会有同学问了：那这样的话不跟udp一样传输不可靠了么？QUIC是如何保证传输可靠的？
这和QUIC的流量控制有关，来看看它的流量控制的方法把。

2.3 QUIC的可靠传输

2.3.1 单调递增的 Packet Number

QUIC使用了 Packet Number代替了 TCP的Sequence Number，并且每个 Packet Number都是严格递增。就算 Packet N丢失了，重传该Packet的Number一定是个比N大的值。这也解决了TCP重传歧义问题。如下图所示：

但是单纯依靠递增的PacketNumber是无法保证数据的顺序性和可靠性的，QUIC引入了Stream Offset的概念。
如果Packet 里的装载的如果是 Stream（请求） 的话，就需要依靠 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 按照顺序组织起来，交给应用程序处理。

2.3.2 基于 stream 和 connecton 级别的流量控制

QUIC的流量控制类似Http2，提供了 Connection 和 Stream两个级别的流量控制。 Stream可以看成是一条请求，而Connection可以看成是一条连接通道。多路复用意味着一条Connection上会有多条Stream， QUIC的流量控制就是针对于一个Connection的Stream进行调控。

下图是QUIC的流量控制策略，是针对一个Stream的：

对于单个Stream而言，起始的接收窗口就是其最大接收窗口（max receive window），随着接收者接收到一部分数据后，接收窗口变小。在接收到的数据中，有一部分是已经读取的（consumed部分），一部分是接收但并没来得及读取的（received部分）。当上图中的黄色部分达到一定的阈值后，就需要更新接收窗口并告知发送者。这个阈值定义为已读取的数据大于最大接收窗口的一半，达到后，发送 WINDOW_UPDATE帧给发送者，接收窗口更新。比如告诉发送者，窗口向后移了Bytes consumed个字节。
而对于connection级别的流量窗口，其接收窗口大小就是各个stream接收窗口大小之和。

QUIC相比于其他协议，队头阻塞问题解决的更加彻底：

1. QUIC的滑动窗口的移动之和接收到的最大字节偏移有关，而不和顺序有关。 对于TCP来说，窗口滑动的前提是此前所有的包都顺序的接收到了，否则就等待，
2. QUIC同一个Connection中的不同Stream是互相独立的，即StreamA被阻塞，并不影响StreamB、C的读取。而Tcp由于其不知道将不同Stream交给上层哪一个请求，因此同一个Connection内，StreamA被阻塞后，StreamB、C都要等待。

2.4 改进的拥塞控制算法

QUIC默认采用 Cubic 拥塞控制算法，和TCP一样，即慢开始、拥塞避免、快重传、快恢复。除此之外，也支持 CubicBytes、Reno、BBR、PCC等拥塞控制算法。而QUIC在此之上做了改进，主要有：

1. 可插拔、灵活性
   ①：应用程序层面能实现不同的拥塞控制算法，不需要依赖操作系统和内核支持。
   ②：即使是个单应用程序的不同连接也能支持配置不同的拥塞控制算法
   ③：应用程序不需要停机和升级就能实现拥塞控制变更，只需要在服务端修改一下配置，就能实现拥塞算法的切换
2. 尽可能避免超时重传
   为了尽可能的实现快重传而不是超时重传，QUIC采用了Tail Loss Probes (TLPs)实现某些情况下的快重传机制触发。

TLP算法如下图，服务器的segments 6-10丢失，客户端在等待s6时，由于没有收到后续的序列，因此无法触发快速重传机制，时间达到probe阈值（PTO）后，TLP算法对segments10进行重传，客户端收到这个重传序列，就能触发快速重传机制。而QUIC会在PTO之前就发送两个TLPs来尽可能避免等到超时再重传。

2.5 连接迁移

传统NAT遇到的问题，比如小区运营商切换端口，导致设备端判断不了新的连接标识，需要重新握手。而QUIC使用UDP，不面向连接，所以不用握手。其上层QUIC链路由于使用了64位的Connection id作为唯一标识，就不像Tcp一样使用 ip:port四元组的发生变化导致影响链路标识。因此网络连接状态不会增加额外的重连耗时。

2.6 前向纠错

QUIC采用向前纠错(FEC)方案，即每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。

但这个方案在网络好的时候会影响性能，增加带宽，所以后面被Google废弃了。

3. Android端实现QUIC

目前封装QUIC较好的库是Google的 Chromium项目，其移动端网络库是Cronet，支持Http、Http/2以及QUIC协议。我们需要安装Chromium环境，然后使用 Cronet进行源码编译，就能使用这个库。这里有官方安装文档文档：官方文档。

之后有空再实现，这几天环境一直没有装好，各种踩坑= =

4. 数据表现

下面的数据均来自于 腾讯、又拍云等大量使用QUIC的大厂的总结数据，不过数据比较老，来自18年，但具有一定的参考价值。

4.1 外网下表现

腾讯的黄钻业务、QQ会员接入了QUIC，在 腾讯浏览服务中公布了这些使用的数据

4.1.1 性能表现

可以看到主要资源拉取耗时QUIC要比Http2快100ms，而首屏和Pagefinish耗时减少约20%。

4.1.2 监控数据

QUIC对于其他协议有速度上的优势，而对业务来说稳定是首要的。腾讯浏览服务在QUIC场景搭建了完善的异常上报机制，对X5内核的QUIC业务进行监控。下面一起来看看QUIC的外网监控表现情况。

成功率监控：

这一维度主要监控QUIC的连接成功率以及竞速成功率，上图为黄钻业务06月15-17号三天成功率及竞速成功率数据，目前QUIC的连接成功率保持在98%以上，QUIC的竞速成功率在70%以上。

QUIC失败监控：

对于QUIC失败异常，X5内核提供了详细的QUIC细分错误码以分析错误原因，从上报的大盘数据来看：

• QUIC链接失败率不到2%，连接失败的情况，以QUIC连接超时为主。这种情况一般由于地区的QoS策略导致。

• QUIC失败率较高的三个省份为：贵州、广西和新疆；失败率较高的运营商为：教育网和长城宽带。

4.2 弱网下表现

Quic因为其连接建立时间短、流量控制策略效率更高，所以QUIC在弱网环境的表现比Http2要更好，而且好很多。

下面在相同丢包率5%的条件下、Http/3和Http/2 建连时间和请求时间对比：

因为Http3的建立连接平均少一个RTT，一个RTT平均为100ms，所以上图平均是快了一倍。
而在丢包率较高时，QUIC因为其优秀的流量控制，性能方面上是吊打Http2。

再来看下腾讯团队给出数据，在丢包率较高的情况下，QUC无论是0RTT还是1RTT，都比Http2要强很多。

这样看来，我们又有什么理由不去学习QUIC呢？

5. 参考文章

腾讯技术工程 科普：QUIC协议原理分析
WIKI：快速UDP网络连接
QUIC 0-RTT实现简析及一种分布式的0-RTT实现方案
GitHub：简单讲解一下 http2 的多路复用
TLS 1.3 VS TLS 1.2，让你明白 TLS 1.3 的强大
保利威视频云：QUIC有什么优点？
天下武功，唯’QUICK’不破，揭秘QUIC的五大特性及外网表现