维基百科

QUIC

一种计算机网络传输层协议

QUIC（读作“quick”）是一个通用[1]的传输层[2]网络协议，最初由Google的Jim Roskind设计[3]。该协议于2012年实现并部署[4]，2013年随着实验范围的扩大而公开发布[5][6][7]，并向IETF描述[8]。虽然长期处于互联网草案（英语：Internet Draft）阶段，但从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规范的互联网草案（英语：Internet Draft）提交给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]。

第一个变化是在连接建立期间大大减少开销（英语：Overhead (computing)）。由于大多数HTTP连接都需要TLS，因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时，伺服器响应的数据包包括将来的数据包加密所需的数据。这消除了TCP上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务，并将多个步骤组合到一个请求中。 然后，这些数据既可用于初始设置中的后续请求，也可用于未来的请求。[19]

QUIC使用UDP协议作为其基础，不包括丢失恢复。相反，每个QUIC流是单独控制的，并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务。 这在提高易出错链路的性能方面非常有用，因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据，但是在纠正错误之前其他的正常请求都会等待甚至重发。 QUIC在修复单个流时可以自由处理其他数据，也就是说即使一个请求发生了错误也不会影响到其他的请求。[20]

QUIC包括许多其他更普通的更改，这些更改也可以优化整体延迟和吞吐量。例如，每个数据包是单独加密的，因此加密数据时不需要等待部分数据包。 在TCP下通常不可能这样做，其中加密记录在字节流中，并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商，但QUIC旨在通过单个握手过程完成这些。[8]

QUIC的另一个目标是提高网络切换期间的性能，例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。 当这发生在TCP上时，一个冗长的过程开始了：每个现有连接一个接一个地超时（英语：Timeout (computing)），然后根据需要重新建立。期间存在较高延迟，因为新连接需要等待旧连接超时后才会建立。 为解决此问题，QUIC包含一个连接标识符，该标识符唯一地标识客户端与伺服器之间的连接，而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新建立连接，因为即使用户的IP地址发生变化，原始连接ID仍然有效。[21]

 HTTP/1Transport Layer SecurityTransmission Control ProtocolHTTP/2TLS 1.2Transmission Control ProtocolHTTP/3TLS 1.3QUICUser Datagram ProtocolInternet Protocol
HTTP/3与HTTP/1.1和HTTP/2的之间的协议栈比较

QUIC在应用程式空间（英语：Application domain）中实现，而不是在操作系统内核中实现。当数据在应用程式之间移动时，这通常会由于上下文切换而调用额外的开销。 但是在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. ^ 1.0 1.1 QUIC: A UDP-Based Multiplexed and Secure Transport. IETF: sec. 1. I-D draft-ietf-quic-transport-22. 
  2. ^ 2.0 2.1 Nathan Willis. Connecting on the QUIC. Linux Weekly News. [2013-07-16]. （原始内容存档于2020-10-16）. 
  3. ^ 3.0 3.1 3.2 QUIC: Design Document and Specification Rationale. Jim Roskind, Chromium Contributor. [2015-04-29]. （原始内容存档于2014-11-10）. 
  4. ^ First Chromium Code Landing: CL 11125002: Add QuicFramer and friends.. [2012-10-16]. （原始内容存档于2020-04-13）. 
  5. ^ Experimenting with QUIC. Chromium Official Blog. [2013-07-16]. （原始内容存档于2021-02-05）. 
  6. ^ QUIC, Google wants to make the web faster. François Beaufort, Chromium Evangelist. 
  7. ^ QUIC: next generation multiplexed transport over UDP. YouTube. [2014-04-04]. （原始内容存档于2020-11-18）. 
  8. ^ 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. ^ 9.0 9.1 Lardinois, Frederic. Google Wants To Speed Up The Web With Its QUIC Protocol. TechCrunch. [2016-10-25]. （原始内容存档于2020-12-14）. 
  10. ^ 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）. 
  11. ^ How to enable HTTP3 in Chrome / Firefox / Safari. bram.us. April 8, 2020 [2021-02-02]. （原始内容存档于2021-01-28）. 
  12. ^ The state of QUIC and HTTP/3 2020. www.fastly.com. [2020-10-21]. （原始内容存档于2020-11-13）. 
  13. ^ 13.0 13.1 rfc9000. tools.ietf.org. [2021-06-01] （英语）. 
  14. ^ Tatsuhiro Tsujikawa. ngtcp2. GitHub. [2020-10-17]. （原始内容存档于2021-01-22）. 
  15. ^ Google Will Propose QUIC As IETF Standard. InfoQ. [2016-10-25]. （原始内容存档于2020-10-24）. 
  16. ^ I-D Action: draft-tsvwg-quic-protocol-00.txt. i-d-announce (邮件列表). 17 Jun 2015 [2018-12-10]. （原始内容存档于2016-05-26）. 
  17. ^ QUIC - IETF Working Group. datatracker.ietf.org. [2016-10-25]. （原始内容存档于2021-02-05）. 
  18. ^ Cimpanu, Catalin. HTTP-over-QUIC to be renamed HTTP/3. ZDNet. 12 November 2018 [2018-12-10]. （原始内容存档于2018-11-13）. 
  19. ^ 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）. 
  20. ^ Behr, Michael; Swett, Ian. Introducing QUIC support for HTTPS load balancing. Google Cloud Platform Blog. Google. [16 June 2018]. （原始内容存档于2019-04-10）. 
  21. ^ 21.0 21.1 QUIC at 10,000 feet. Chromium. [2019-04-10]. （原始内容存档于2019-04-10）. 
  22. ^ Applicability of the QUIC Transport Protocol. IETF Network Working Group. 22 October 2018 [2019-04-10]. （原始内容存档于2019-06-07）. 
  23. ^ Distribution of Web Servers among websites that use QUIC. w3techs.com. [2018-12-10]. 
  24. ^ Darya Bugayova. AdGuard 成为世界第一个 DNS-over-QUIC 解析器 (html). AdGuard. 2020-12-16 [2020-12-18]. （原始内容存档于2020-12-17） （中文（中国大陆））. 

外部链接

编辑
检索自“https://zh.wikipedia.org/w/index.php?title=QUIC&oldid=84347241”