QUIC (读作“quick ”)是一个通用[ 1] 的传输层 [ 2] 网络协议 ,最初由Google 的Jim Roskind 设计[ 3] 。该协议于2012年实现并部署[ 4] ,2013年随着实验范围的扩大而公开发布[ 5] [ 6] [ 7] ,并向IETF 描述[ 8] 。虽然长期处于互联网草案 阶段,但从Chrome浏览器至Google服务器的连接中超过一半的连接都使用了QUIC[ 9] 。Microsoft Edge [ 10] 、Firefox [ 11] 都已支持此协议;Safari [ 12] 实现了QUIC,但默认情况下没有启用。QUIC于RFC9000中被正式标准化[ 13] 。
QUIC最初是“快速UDP互联网连接”(Quick UDP Internet Connection )的首字母缩写[ 3] [ 8] ,但在IETF标准中,QUIC不是任何内容的缩写[ 1] 。QUIC提高了目前使用TCP 的面向连接的网络应用 的性能[ 2] [ 9] 。QUIC通过UDP 协议在两个端点之间建立若干个多路连接 ,以达到在网络层淘汰TCP的目标。因为其设计目标在于取代TCP协议,该协议偶尔也被昵称为“TCP/2”[ 14] 。
QUIC与HTTP/2 的多路复用连接协同工作,允许多个数据流独立到达所有端点,因此不受涉及其他数据流的丢包 影响。与之相比,HTTP/2建立在传输控制协议 (TCP)上,如果任何一个TCP数据包延迟或丢失,所有多路数据流都会遭受队头阻塞 延迟。
QUIC的次要目标包括降低连接和传输时延 ,以及每个方向的带宽 估计以避免拥塞 。它还将拥塞控制 算法移到了两个端点的使用者空間 ,而不是内核空间,据称这将使这些算法得到更快的改进。此外,该协议还可以扩展前向纠错 (FEC),以进一步提高预期错误时的性能,这被视为协议演进的下一步。
2015年6月,QUIC规范的互联网草案 提交给IETF 进行标准化[ 15] [ 16] 。2016年,成立了QUIC工作组[ 17] 。2018年10月,IETF的HTTP工作组和QUIC工作组共同决定将QUIC上的HTTP映射称为 "HTTP/3 ",以提前使其成为全球标准[ 18] 。2021年5月IETF公布RFC9000,QUIC规范推出了标准化版本[ 13] 。
背景
传输控制协议 (TCP) 旨在为两个端点之间发送数据流提供一个接口。数据交给TCP系统,TCP系统确保数据以完全相同的形式传到另一端,否则连接将提示存在错误[ 19] 。
为此,TCP将数据分解成網路封包 ,并在每个数据包中添加少量数据。这些附加数据包括一个序列号,用于检测丢失或到达顺序不正确的数据包,以及一个校验和 ,可以检测数据包数据内的错误。当其中任何一个问题发生时,TCP使用自动重传请求 (ARQ)告诉发送方重新发送丢失或损坏的数据包[ 19] 。
在大多数实现中,TCP会将连接上的任何错误视为阻塞,停止进一步传输,直到错误得到解决或连接被视为失败。如果使用单个连接来发送多个数据流,就像在HTTP/2协议中那样,所有这些数据流都会被阻止,尽管其中只有一个可能有问题。例如,如果在下载用于收藏夹图标的GIF图像时出现一个错误,页面的其余部分将等待问题得到解决[ 19] 。
由于TCP系统被设计成类似“数据管道”或流,TCP刻意被设计成并不知晓其传输的数据之细节。如果对传输的数据存在额外需求,如需要使用TLS加密,那么此类协议必须建立在TCP的上层。每种协议都需要自己的握手过程,结果会导致在建立连接前需要大量交换数据,加之长距离通信的固有延迟,从而给整个传输过程增加大量开销[ 19] 。
介绍
QUIC与带有TLS1.2的TCP握手比较
QUIC旨在提供几乎等同于TCP连接的可靠性 ,但延迟 大大减少。它主要通过两个理解HTTP 流量的行为来实现这一点[ 19] 。
第一个变化是在连接建立期间大大减少开销 。由于大多数HTTP连接都需要TLS ,因此QUIC使协商密钥 和支持的协议成为初始握手 过程的一部分。
当客户端打开连接时,服务器 响应的数据包 包括将来的数据包加密 所需的数据。这消除了TCP上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务,并将多个步骤组合到一个请求中。
然后,这些数据既可用于初始设置中的后续请求,也可用于未来的请求。[ 19]
QUIC使用UDP协议作为其基础,不包括丢失 恢复。相反,每个QUIC流是单独控制的,并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误,协议栈 仍然可以独立地继续为其他流提供服务。
这在提高易出错链路的性能方面非常有用,因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据,但是在纠正错误之前其他的正常请求都会等待甚至重发。
QUIC在修复单个流时可以自由处理其他数据,也就是说即使一个请求发生了错误也不会影响到其他的请求。[ 20]
QUIC包括许多其他更普通的更改,这些更改也可以优化整体延迟和吞吐量 。例如,每个数据包是单独加密的,因此加密数据时不需要等待部分数据包。
在TCP下通常不可能这样做,其中加密记录在字节流 中,并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商,但QUIC旨在通过单个握手过程完成这些。[ 8]
QUIC的另一个目标是提高网络切换期间的性能,例如当移动设备的用户从WiFi热点 切换到移动网络 时发生的情况。
当这发生在TCP上时,一个冗长的过程开始了:每个现有连接一个接一个地超时 ,然后根据需要重新建立。期间存在较高延迟,因为新连接需要等待旧连接超时后才会建立。
为解决此问题,QUIC包含一个连接标识符,该标识符唯一地标识客户端与服务器之间的连接,而无论源IP地址 是什么。这样只需发送一个包含此ID的数据包即可重新建立连接,因为即使用户的IP地址发生变化,原始连接ID仍然有效。[ 21]
HTTP/3与HTTP/1.1和HTTP/2的之间的协议栈比较
QUIC在应用程序空间 中实现,而不是在操作系统内核 中实现。当数据在应用程序之间移动时,这通常会由于上下文切换而调用额外的开销。
但是在QUIC下协议栈旨在由单个应用程序使用,每个应用程序使用QUIC在UDP上托管自己的连接。最终差异可能非常小,因为整个HTTP/2 堆栈的大部分已经存在于应用程序(或更常见的库)中。
将剩余部分放在这些库中,基本上是纠错,对HTTP/2堆栈的大小或整体复杂性几乎没有影响。[ 8]
QUIC允许更容易地进行未来更改,因为它不需要更改内核就可以进行更新。
QUIC的长期目标之一是添加前向纠错 和改进的拥塞控制 。[ 21]
关于从TCP迁移到UDP的一个问题是TCP被广泛采用,并且互联网基础设施中的许多中间设备被调整为UDP速率限制甚至阻止UDP。
Google进行了一些探索性实验来描述这一点,发现只有少数连接存在此问题。[ 3] 所以Chromium的网络堆栈同时打开QUIC和传统TCP连接,并在QUIC连接失败时以零延迟回退到TCP连接。[ 22]
gQUIC与iQUIC
由Google创建并以QUIC的名称提交给IETF的协议与随后在IETF中创建的QUIC完全不同(尽管名称相同)。
最初的Google QUIC(也称为gQUIC)严格来说是通过加密UDP发送HTTP/2帧的协议,而IETF创建的QUIC是通用传输协议,也就是说HTTP以外的其他协议(如SMTP 、DNS 、SSH 、Telnet 、NTP )也可以使用它。重要的是要注意并记住其差异。
自2012年以来,Google在其服务及Chrome中使用的QUIC版本(直到2019年2月)为Google QUIC。随着时间的推移,它正在逐渐变得类似于IETF QUIC(也称为iQUIC)。
流量控制
與大多數傳輸協議一樣,QUIC 具有流量控制以保護接收端免受緩衝區overflow的影響。QUIC 是基於 UDP 傳輸,而 UDP 沒有流量控制,因此 QUIC 實現了自己的流量控制機制。與TCP不同,QUIC並非透過ACK回應目前接收到第幾筆資料,而是透過control frame實現類似於 HTTP/2 的基於信用的方案。
实现
客户端
Google Chrome 于2012年开始开发QUIC协议并且于Chromium 版本 29(2013年8月20日释出)发布。QUIC协议在当前Chrome版本中被默认开启,活跃的会话列表在chrome://net-internals/#quic
中可见。
服务端
截至2017年,有三种活跃维护中的实现。谷歌的服务器及谷歌发布的原型服务器 (页面存档备份 ,存于互联网档案馆 )使用Go语言编写的quic-go (页面存档备份 ,存于互联网档案馆 )及Caddy 的试验性QUIC支持。在2017年7月11日,LiteSpeed科技正式在他们的负载均衡 (WebADC (页面存档备份 ,存于互联网档案馆 ))及 LiteSpeed 服务器中支持QUIC。截止 17 年 12 月, 97.5%的使用 QUIC 协议的网站在 LiteSpeed 服务器中运行[ 23] 。
另有几种不再维护的社区产品,基于Chromium实现并且减少使用依赖的libquic (页面存档备份 ,存于互联网档案馆 )、提供libquic的Go语言绑定的goquic (页面存档备份 ,存于互联网档案馆 )、打包为Docker 镜像的用来转换为普通HTTP请求的反向代理quic-reverse-proxy (页面存档备份 ,存于互联网档案馆 )。
2020年12月,支持DNS-over-QUIC协议的公共DNS 解析器,由AdGuard 首次公開推出服務[ 24] 。
参见
参考资料
^ 1.0 1.1 QUIC: A UDP-Based Multiplexed and Secure Transport . IETF : sec. 1. I-D draft-ietf-quic-transport-22.
^ 2.0 2.1 Nathan Willis. Connecting on the QUIC . Linux Weekly News. [2013-07-16 ] . (原始内容存档 于2020-10-16).
^ 3.0 3.1 3.2 QUIC: Design Document and Specification Rationale . Jim Roskind, Chromium Contributor. [2015-04-29 ] . (原始内容存档 于2014-11-10).
^ First Chromium Code Landing: CL 11125002: Add QuicFramer and friends. . [2012-10-16 ] . (原始内容存档 于2020-04-13).
^ Experimenting with QUIC . Chromium Official Blog. [2013-07-16 ] . (原始内容存档 于2021-02-05).
^ QUIC, Google wants to make the web faster . François Beaufort, Chromium Evangelist.
^ QUIC: next generation multiplexed transport over UDP . YouTube. [2014-04-04 ] . (原始内容存档 于2020-11-18).
^ 8.0 8.1 8.2 8.3 QUIC: IETF-88 TSV Area Presentation (PDF) . Jim Roskind, Google. [2013-11-07 ] . (原始内容存档 (PDF) 于2014-02-11).
^ 9.0 9.1 Lardinois, Frederic. Google Wants To Speed Up The Web With Its QUIC Protocol . TechCrunch. [2016-10-25 ] . (原始内容存档 于2020-12-14).
^ Christopher Fernandes. Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5 . April 3, 2018 [2020-05-08 ] . (原始内容存档 于2020-11-23).
^ How to enable HTTP3 in Chrome / Firefox / Safari . bram.us. April 8, 2020 [2021-02-02 ] . (原始内容存档 于2021-01-28).
^ The state of QUIC and HTTP/3 2020 . www.fastly.com. [2020-10-21 ] . (原始内容存档 于2020-11-13).
^ 13.0 13.1 rfc9000 . tools.ietf.org. [2021-06-01 ] (英语) .
^ Tatsuhiro Tsujikawa. ngtcp2 . GitHub. [2020-10-17 ] . (原始内容存档 于2021-01-22).
^ Google Will Propose QUIC As IETF Standard . InfoQ. [2016-10-25 ] . (原始内容存档 于2020-10-24).
^ I-D Action: draft-tsvwg-quic-protocol-00.txt . i-d-announce (邮件列表). 17 Jun 2015 [2018-12-10 ] . (原始内容存档 于2016-05-26).
^ QUIC - IETF Working Group . datatracker.ietf.org. [2016-10-25 ] . (原始内容存档 于2021-02-05).
^ Cimpanu, Catalin. HTTP-over-QUIC to be renamed HTTP/3 . ZDNet. 12 November 2018 [2018-12-10 ] . (原始内容存档 于2018-11-13).
^ 19.0 19.1 19.2 19.3 19.4 19.5 Bright, Peter. The next version of HTTP won't be using TCP . Arstechnica. 12 November 2018 [2019-04-10 ] . (原始内容存档 于2019-04-10).
^ Behr, Michael; Swett, Ian. Introducing QUIC support for HTTPS load balancing . Google Cloud Platform Blog. Google. [16 June 2018] . (原始内容存档 于2019-04-10).
^ 21.0 21.1 QUIC at 10,000 feet . Chromium. [2019-04-10 ] . (原始内容存档 于2019-04-10).
^ Applicability of the QUIC Transport Protocol . IETF Network Working Group. 22 October 2018 [2019-04-10 ] . (原始内容存档 于2019-06-07).
^ Distribution of Web Servers among websites that use QUIC . w3techs.com. [2018-12-10 ] .
^ Darya Bugayova. AdGuard 成为世界第一个 DNS-over-QUIC 解析器 (html) . AdGuard. 2020-12-16 [2020-12-18 ] . (原始内容存档 于2020-12-17) (中文(中国大陆)) .
外部連結