编辑｜小智
本文紧张先容 QUIC 协议产生的背景和核心特性。
写在前面
如果你的 App，在不须要任何修正的情形下就能提升 15% 以上的访问速率。特殊是弱网络的时候能够提升 20% 以上的访问速率。
如果你的 App，在频繁切换 4G 和 WIFI 网络的情形下，不会断线，不须要重连，用户无任何感知。如果你的 App，既须要 TLS 的安全，也想实现 HTTP2 多路复用的强大。
如果你刚刚才听说 HTTP2 是下一代互联网协议，如果你刚刚才关注到 TLS1.3 是一个革命性具有里程碑意义的协议，但是这两个协议却一贯在被另一个更新兴的协议所影响和寻衅。
如果这个新兴的协议，它的名字就叫做“快”，并且正在标准化为新一代的互联网传输协议。
你乐意花一点点韶光理解这个协议吗？你乐意投入精力去研究这个协议吗？你乐意全力推动业务来利用这个协议吗？
QUIC 概述
Quic 全称 quick udp internet connection [1]，“快速 UDP 互联网连接”，（和英文 quick 谐音，简称“快”）是由 google 提出的利用 udp 进行多路并发传输的协议。
Quic 比较现在广泛运用的 http2+tcp+tls 协议有如下上风 [2]：
减少了 TCP 三次握手及 TLS 握手韶光。
改进的拥塞掌握。
避免队头壅塞的多路复用。
连接迁移。
前向冗余纠错。
为什么须要 QUIC
从上个世纪 90 年代互联网开始兴起一贯到现在，大部分的互联网流量传输只利用了几个网络协议。利用 IPv4 进行路由，利用 TCP 进行连接层面的流量掌握，利用 SSL/TLS 协议实现传输安全，利用 DNS 进行域名解析，利用 HTTP 进行运用数据的传输。
而且近三十年来，这几个协议的发展都非常缓慢。TCP 紧张是拥塞掌握算法的改进，SSL/TLS 基本上勾留在原地，几个小版本的改动紧张是密码套件的升级，TLS1.3[3] 是一个飞跃式的变革，但截止到本日，还没有正式发布。IPv4 虽然有一个大的进步，实现了 IPv6，DNS 也增加了一个安全的 DNSSEC，但和 IPv6 一样，支配进度较慢。
随着移动互联网快速发展以及物联网的逐步兴起，网络交互的场景越来越丰富，网络传输的内容也越来越弘大，用户对网络传输效率和 WEB 相应速率的哀求也越来越高。
一方面是历史悠久利用广泛的古老协议，其余一方面用户的利用场景对传输性能的哀求又越来越高。如下几个由来已久的问题和抵牾就变得越来越突出。
协议历史悠久导致中间设备僵化。
依赖于操作系统的实现导致协议本身僵化。
建立连接的握手延迟大。
队头壅塞。
这里分小节大略解释一下：
中间设备的僵化
可能是 TCP 协议利用得太久，也非常可靠。以是我们很多中间设备，包括防火墙、NAT 网关，整流器等涌现了一些约定俗成的动作。
比如有些防火墙只许可通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法利用新的传输格式。整流器和中间代理有时候出于安全的须要，会删除一些它们不认识的选项字段。
TCP 协议本来是支持端口、选项及特性的增加和修正。但是由于 TCP 协议和有名端口及选项利用的历史太悠久，中间设备已经依赖于这些潜规则，以是对这些内容的修正很随意马虎遭到中间环节的滋扰而失落败。
而这些滋扰，也导致很多在 TCP 协议上的优化变适合心谨慎，步履维艰。
依赖于操作系统的实现导致协议僵化
TCP 是由操作系统在内核西方栈层面实现的，运用程序只能利用，不能直接修正。虽然运用程序的更新迭代非常快速和大略。但是 TCP 的迭代却非常缓慢，缘故原由便是操作系统升级很麻烦。
现在移动终端更加盛行，但是移动端部分用户的操作系统升级依然可能滞后数年韶光。PC 真个系统升级滞后得更加严重，windows xp 现在还有大量用户在利用，只管它已经存在快 20 年。
做事端系统不依赖用户升级，但是由于操作系统升级涉及到底层软件和运行库的更新，以是也比较守旧和缓慢。
这也就意味着纵然 TCP 有比较好的特性更新，也很难快速推广。比如 TCP Fast Open。它虽然 2013 年就被提出了，但是 Windows 很多系统版本依然不支持它。
建立连接的握手延迟大
不管是 HTTP1.0/1.1 还是 HTTPS，HTTP2，都利用了 TCP 进行传输。HTTPS 和 HTTP2 还须要利用 TLS 协议来进行安全传输。这就涌现了两个握手延迟：
1.TCP 三次握手导致的 TCP 连接建立的延迟。
2.TLS 完备握手须要至少 2 个 RTT 才能建立，简化握手须要 1 个 RTT 的握手延迟。
对付很多短连接场景，这样的握手延迟影响很大，且无法肃清。
队头壅塞
队头壅塞紧张是 TCP 协议的可靠性机制引入的。TCP 利用序列号来标识数据的顺序，数据必须按照顺序处理，如果前面的数据丢失，后面的数据就算到达了也不会关照运用层来处理。
其余 TLS 协议层面也有一个队头壅塞，由于 TLS 协议都是按照 record 来处理数据的，如果一个 record 中丢失了数据，也会导致全体 record 无法精确处理。
概括来讲，TCP 和 TLS1.2 之前的协议存在着构造性的问题，如果连续在现有的 TCP、TLS 协议之上实现一个全新的运用层协议，依赖于操作系统、中间设备还有用户的支持。支配本钱非常高，阻力非常大。
以是 QUIC 协议选择了 UDP，由于 UDP 本身没有连接的观点，不须要三次握手，优化了连接建立的握手延迟，同时在运用程序层面实现了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并发性，只须要用户端和做事真个运用程序支持 QUIC 协议，完备避开了操作系统和中间设备的限定。
QUIC 核心特性
连接建立延时低
0RTT 建连可以说是 QUIC 比较 HTTP2 最大的性能上风。那什么是 0RTT 建连呢？这里面有两层含义。
传输层 0RTT 就能建立连接。
加密层 0RTT 就能建立加密连接。
图 1 HTTPS 及 QUIC 建连过程
比如上图左边是 HTTPS 的一次完备握手的建连过程，须要 3 个 RTT。就算是 Session Resumption[14]，也须要至少 2 个 RTT。
而 QUIC 呢？由于建立在 UDP 的根本上，同时又实现了 0RTT 的安全握手，以是在大部分情形下，只须要 0 个 RTT 就能实现数据发送，在实现前向加密 [15] 的根本上，并且 0RTT 的成功率比较 TLS 的 Sesison Ticket[13] 要高很多。
改进的拥塞掌握
TCP 的拥塞掌握实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速规复 [22]。
QUIC 协议当前默认利用了 TCP 协议的 Cubic 拥塞掌握算法 [6]，同时也支持 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 的 Packet Number 已经不是 N，而是一个比 N 大的值。而 TCP 呢，重传 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不变，也正是由于这个特性，引入了 Tcp 重传的歧义问题。
图 2 Tcp 重传歧义性
如上图所示，超时势宜 RTO 发生后，客户端发起重传，然后吸收到了 Ack 数据。由于序列号一样，这个 Ack 数据到底是原始要求的相应还是重传要求的相应呢？不好判断。
如果算成原始要求的相应，但实际上是重传要求的相应（上图左），会导致采样 RTT 变大。如果算成重传要求的相应，但实际上是原始要求的相应，又很随意马虎导致采样 RTT 过小。
由于 Quic 重传的 Packet 和原始 Packet 的 Pakcet Number 是严格递增的，以是很随意马虎就办理了这个问题。
图 3 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 来担保运用数据的顺序。如缺点! 未找到引用源。所示，发送端先后发送了 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 按照顺序组织起来，交给运用程序处理。
图 4 Stream Offset 担保有序性
不许可 Reneging
什么叫 Reneging 呢？便是吸收方丢弃已经吸收并且上报给 SACK 选项的内容 [8]。TCP 协议不鼓励这种行为，但是协议层面许可这样的行为。紧张是考虑到做事器资源有限，比如 Buffer 溢出，内存不足等情形。
Reneging 对数据重传会产生很大的滋扰。由于 Sack 都已经表明吸收到了，但是吸收端事实上丢弃了该数据。
QUIC 在协议层面禁止 Reneging，一个 Packet 只要被 Ack，就认为它一定被精确吸收，减少了这种滋扰。
更多的 Ack 块
TCP 的 Sack 选项能够见告发送方已经吸收到的连续 Segment 的范围，方便发送方进行选择性重传。
由于 TCP 头部最大只有 60 个字节，标准头部占用了 20 字节，以是 Tcp Option 最大长度只有 40 字节，再加上 Tcp Timestamp option 占用了 10 个字节 [25]，以是留给 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 选项存在一个问题 [25]，它只是回显了发送方的韶光戳，但是没有打算吸收端吸收到 segment 到发送 Ack 该 segment 的韶光。这个韶光可以简称为 Ack Delay。
这样就会导致 RTT 打算偏差。如下图：
可以认为 TCP 的 RTT 打算：
而 Quic 打算如下：
当然 RTT 的详细打算没有这么大略，须要采样，参考历史数值进行平滑打算，参考如下公式 [9]。
基于 stream 和 connecton 级别的流量掌握
QUIC 的流量掌握 [22] 类似 HTTP2，即在 Connection 和 Stream 级别供应了两种流量掌握。为什么须要两类流量掌握呢？紧张是由于 QUIC 支持多路复用。
Stream 可以认为便是一条 HTTP 要求。
Connection 可以类比一条 TCP 连接。多路复用意味着在一条 Connetion 上会同时存在多条 Stream。既须要对单个 Stream 进行掌握，又须要针对所有 Stream 进行总体掌握。
QUIC 实现流量掌握的事理比较大略：
通过 window_update 帧见告对端自己可以吸收的字节数，这样发送方就不会发送超过这个数量的数据。
通过 BlockFrame 见告对端由于流量掌握被壅塞了，无法发送数据。
QUIC 的流量掌握和 TCP 有点差异，TCP 为了担保可靠性，窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间涌现丢包，就算吸收到了更大序号的 Segment，窗口也无法超过这个序列号。
但 QUIC 不同，就算此前有些 packet 没有吸收到，它的滑动只取决于吸收到的最大偏移字节数。
图 5 Quic Flow Control
针对 Stream：
针对 Connection：
同样地，STGW 也在连接和 Stream 级别设置了不同的窗口数。
最主要的是，我们可以在内存不敷或者上游处理性能涌现问题时，通过流量掌握来限定传输速率，保障做事可用性。
没有队头壅塞的多路复用
QUIC 的多路复用和 HTTP2 类似。在一条 QUIC 连接上可以并发发送多个 HTTP 要求 (stream)。但是 QUIC 的多路复用比较 HTTP2 有一个很大的上风。
QUIC 一个连接上的多个 stream 之间没有依赖。这样如果 stream2 丢了一个 udp packet，也只会影响 stream2 的处理。不会影响 stream2 之前及之后的 stream 的处理。
这也就在很大程度上缓解乃至肃清了队头壅塞的影响。
多路复用是 HTTP2 最强大的特性 [7]，能够将多条要求在一条 TCP 连接上同时发出去。但也恶化了 TCP 的一个问题，队头壅塞 [11]，如下图示：
图 6 HTTP2 队头壅塞
HTTP2 在一个 TCP 连接上同时发送 4 个 Stream。个中 Stream1 已经精确到达，并被运用层读取。但是 Stream2 的第三个 tcp segment 丢失了，TCP 为了担保数据的可靠性，须要发送端重传第 3 个 segment 才能关照运用层读取接下去的数据，虽然这个时候 Stream3 和 Stream4 的全部数据已经到达了吸收端，但都被壅塞住了。
不仅如此，由于 HTTP2 逼迫利用 TLS，还存在一个 TLS 协议层面的队头壅塞 [12]。
图 7 TLS 队头壅塞
Record 是 TLS 协议处理的最小单位，最大不能超过 16K，一些做事器比如 Nginx 默认的大小便是 16K。由于一个 record 必须经由数据同等性校验才能进行加解密，以是一个 16K 的 record，就算丢了一个字节，也会导致已经吸收到的 15.99K 数据无法处理，由于它不完全。
那 QUIC 多路复用为什么能避免上述问题呢？
QUIC 最基本的传输单元是 Packet，不会超过 MTU 的大小，全体加密和认证过程都是基于 Packet 的，不会超过多个 Packet。这样就能避免 TLS 协议存在的队头壅塞。
Stream 之间相互独立，比如 Stream2 丢了一个 Pakcet，不会影响 Stream3 和 Stream4。不存在 TCP 队头壅塞。
图 8 QUIC 多路复用时没有队头壅塞的问题
当然，并不是所有的 QUIC 数据都不会受到队头壅塞的影响，比如 QUIC 当前也是利用 Hpack 压缩算法 [10]，由于算法的限定，丢失一个头部数据时，可能碰着队头壅塞。
总体来说，QUIC 在传输大量数据时，比如视频，受到队头壅塞的影响很小。
加密认证的报文
TCP 协议头部没有经由任何加密和认证，以是在传输过程中很随意马虎被中间网络设备修改，注入和窃听。比如修正序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。
但是 QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经由认证的，报文 Body 都是经由加密的。
这样只要对 QUIC 报文任何修正，吸收端都能够及时创造，有效地降落了安全风险。
如下图所示，赤色部分是 Stream Frame 的报文头部，有认证。绿色部分是报文内容，全部经由加密。
连接迁移
一条 TCP 连接 [17] 是由四元组标识的（源 IP，源端口，目的 IP，目的端口）。什么叫连接迁移呢？便是当个中任何一个元素发生变革时，这条连接依然坚持着，能够保持业务逻辑不中断。当然这里面紧张关注的是客户真个变革，由于客户端不可控并且网络环境常常发生变革，而做事真个 IP 和端口一样平常都是固定的。
比如大家利用手机在 WIFI 和 4G 移动网络切换时，客户真个 IP 肯定会发生变革，须要重新建立和做事真个 TCP 连接。
又比如大家利用公共 NAT 出口时，有些连接竞争时须要重新绑定端口，导致客户真个端口发生变革，同样须要重新建立 TCP 连接。
针对 TCP 的连接变革，MPTCP[5] 实在已经有理解决方案，但是由于 MPTCP 须要操作系统及网络协议栈支持，支配阻力非常大，目前并不适用。
以是从 TCP 连接的角度来讲，这个问题是无解的。
那 QUIC 是如何做到连接迁移呢？很大略，任何一条 QUIC 连接不再以 IP 及端口四元组标识，而因此一个 64 位的随机数作为 ID 来标识，这样就算 IP 或者端口发生变革时，只要 ID 不变，这条连接依然坚持着，上层业务逻辑感知不到变革，不会中断，也就不须要重连。
由于这个 ID 是客户端随机产生的，并且长度有 64 位，以是冲突概率非常低。
其他亮点
此外，QUIC 还能实现前向冗余纠错，在主要的包比如握手发生丢失时，能够根据冗余信息还原出握手。
QUIC 还能实现证书压缩，减少证书传输量，针对包头进行验证等。
限于篇幅，本文不再详细先容，有兴趣的可以参考文档 [23] 和文档 [4] 和文档 [26]。
参考线索
[1]. https://www.chromium.org/quic
[2]. https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit
[3]. E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3”, draft-ietf-tls-tls13-21, https://tools.ietf.org/html/draft-ietf-tls-tls13-21, July 03, 2017
[4]. Adam Langley,Wan-Teh Chang, “QUIC Crypto”，https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit, 20161206
[5]. https://www.multipath-tcp.org/
[6]. Ha, S., Rhee, I., and L. Xu, \"大众CUBIC: A New TCP-Friendly High-Speed TCP Variant\"大众, ACM SIGOPS Operating System Review , 2008.
[7]. M. Belshe,BitGo, R. Peon, “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, May 2015
[8]. M. Mathis,J. Mahdavi,S. Floyd,A. Romanow,“TCP Selective Acknowledgment Options”, rfc2018, https://tools.ietf.org/html/rfc2018, October 1996
[9]. V. Paxson，M. Allman，J. Chu，M. Sargent，“Computing TCP's Retransmission Timer”， rfc6298, https://tools.ietf.org/html/rfc6298, June 2011
[10]. R. Peon,H. Ruellan,“HPACK: Header Compression for HTTP/2”,RFC7541,May 2015
[11]. M. Scharf, Alcatel-Lucent Bell Labs, S. Kiesel, “Quantifying Head-of-Line Blocking in TCP and SCTP”, https://tools.ietf.org/id/draft-scharf-tcpm-reordering-00.html, July 15, 2013
[12]. Ilya Grigorik，“Optimizing TLS Record Size & Buffering Latency”, https://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/, October 24, 2013
[13]. J. Salowey,H. Zhou,P. Eronen,H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State”, RFC5077, January 2008
[14]. Dierks, T. and E. Rescorla, \"大众The Transport Layer Security (TLS) Protocol Version 1.2\公众, RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[15]. Shirey, R., \"大众Internet Security Glossary, Version 2\"大众, FYI , RFC 4949, August 2007
[16]. 罗成，“HTTPS性能优化”， http://www.infoq.com/cn/presentations/performance-optimization-of-https，February.2017
[17]. Postel, J., \"大众Transmission Control Protocol\公众, STD 7, RFC793, September 1981.
[18]. J. Postel,“User Datagram Protocol”, RFC768,August 1980
[19]. Q. Dang, S. Santesson,K. Moriarty,D. Brown.T. Polk, “Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA”,RFC5758, January 2010
[20]. Bassham, L., Polk, W., and R. Housley, \"大众Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile\公众, RFC 3279, April 2002
[21]. D.Cooper,S.Santesson, S.Farrell,S. Boeyen,R. Housley,W.Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC5280, May 2008
[22]. M. Allman,V. Paxson,E. Blanton, \公众TCP Congestion Control”,RFC5681, September 2009
[23]. Robbie Shade, “Flow control in QUIC”, https://docs.google.com/document/d/1F2YfdDXKpy20WVKJueEf4abn_LVZHhMUMS5gX6Pgjl4/edit#, May, 2016,
[24]. ianswett , “QUIC fec v1”, https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit#heading=h.xgjl2srtytjt, 2016-02-19
[25]. D.Borman,B.Braden,V.Jacobson,R.Scheffenegger, Ed. “TCP Extensions for High Performance”,rfc7323, https://tools.ietf.org/html/rfc7323,September 2014
[26]. 罗成，“WEB加速，协议先行”， https://zhuanlan.zhihu.com/p/27938635，july, 2017
作者先容
罗成，腾讯资深研发工程师。目前紧张卖力腾讯 stgw(腾讯安全云网关）的干系事情，整体推进腾讯内部及腾讯公有云，稠浊云的七层负载均衡及全站 HTTPS 接入。对 HTTPS，SPDY，HTTP2，QUIC 等运用层协议、高性能做事器技能、云网络技能、用户访问速率、分布式文件传输等有较深的理解。
