QUIC
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]都支持它,但默认情况下没有启用。
網際網路套組 |
---|
應用層 |
傳輸層 |
網路層 |
連結層 |
虽然它的名字最初是作为 “快速UDP互联网连接”的首字母缩写提出的[3][8],但IETF使用的QUIC一词并不是首字母缩写,它只是协议的名称[1]。QUIC提高了目前使用TCP的面向连接的网络应用的性能[2][9]。它通过使用用户数据报协议(UDP)在两个端点之间建立若干个多路连接来实现这一目标,其目的是为了在网络层淘汰TCP,以满足许多应用的需求,因此该协议偶尔也会获得 “TCP/2”的昵称[13]。
QUIC与HTTP/2的多路复用连接协同工作,允许多个数据流独立到达所有端点,因此不受涉及其他数据流的丢包影响。相反,HTTP/2建立在传输控制协议(TCP)上,如果任何一个TCP数据包延迟或丢失,所有多路数据流都会遭受队头阻塞延迟。
QUIC的次要目标包括降低连接和传输时延,以及每个方向的带宽估计以避免拥塞。它还将拥塞控制算法移到了两个端点的使用者空間,而不是内核空间,据称这将使这些算法得到更快的改进。此外,该协议还可以扩展前向纠错(FEC),以进一步提高预期错误时的性能,这被视为协议演进的下一步。
2015年6月,QUIC规范的互联网草案提交给IETF进行标准化[14][15]。2016年,成立了QUIC工作组[16]。2018年10月,IETF的HTTP工作组和QUIC工作组共同决定将QUIC上的HTTP映射称为 "HTTP/3",以提前使其成为全球标准[17]。
背景
传输控制协议 (TCP) 旨在为两个端点之间发送数据流提供一个接口。数据交给TCP系统,TCP系统确保数据以完全相同的形式传到另一端,否则连接将提示存在错误[18]。
为此,TCP将数据分解成網路封包,并在每个数据包中添加少量数据。这些附加数据包括一个序列号,用于检测丢失或到达顺序不正确的数据包,以及一个校验和,可以检测数据包数据内的错误。当其中任何一个问题发生时,TCP使用自动重传请求(ARQ)告诉发送方重新发送丢失或损坏的数据包[18]。
在大多数实现中,TCP会将连接上的任何错误视为阻塞,停止进一步传输,直到错误得到解决或连接被视为失败。如果使用单个连接来发送多个数据流,就像在HTTP/2协议中那样,所有这些数据流都会被阻止,尽管其中只有一个可能有问题。例如,如果在下载用于收藏夹图标的GIF图像时出现一个错误,页面的其余部分将等待问题得到解决[18]。
由于TCP系统被设计成看起来像一个“数据管道”,或流,它故意包含很少的对它传输的数据的理解。如果数据有额外的要求,如使用TLS加密,这必须由运行在传输控制协议之上的系统设置,使用传输控制协议与连接另一端的类似软件进行通信。每种设置任务都需要自己的握手过程。这通常需要多次往返请求和响应,直到建立连接。由于长距离通信的固有延迟,这会给整个传输增加大量开销[18]。
介绍
QUIC旨在提供几乎等同于TCP连接的可靠性,但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点[18]。
第一个变化是在连接建立期间大大减少开销。由于大多数HTTP连接都需要TLS,因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时,服务器响应的数据包包括将来的数据包加密所需的数据。这消除了TCP上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务,并将多个步骤组合到一个请求中。 然后,这些数据既可用于初始设置中的后续请求,也可用于未来的请求。[18]
QUIC使用UDP协议作为其基础,不包括丢失恢复。相反,每个QUIC流是单独控制的,并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误,协议栈仍然可以独立地继续为其他流提供服务。 这在提高易出错链路的性能方面非常有用,因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据,但是在纠正错误之前其他的正常请求都会等待甚至重发。 QUIC在修复单个流时可以自由处理其他数据,也就是说即使一个请求发生了错误也不会影响到其他的请求。[19]
QUIC包括许多其他更普通的更改,这些更改也可以优化整体延迟和吞吐量。例如,每个数据包是单独加密的,因此加密数据时不需要等待部分数据包。 在TCP下通常不可能这样做,其中加密记录在字节流中,并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商,但QUIC旨在通过单个握手过程完成这些。[8]
QUIC的另一个目标是提高网络切换期间的性能,例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。 当这发生在TCP上时,一个冗长的过程开始了:每个现有连接一个接一个地超时,然后根据需要重新建立。期间存在较高延迟,因为新连接需要等待旧连接超时后才会建立。 为解决此问题,QUIC包含一个连接标识符,该标识符唯一地标识客户端与服务器之间的连接,而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新建立连接,因为即使用户的IP地址发生变化,原始连接ID仍然有效。[20]
QUIC在应用程序空间中实现,而不是在操作系统内核中实现。当数据在应用程序之间移动时,这通常会由于上下文切换而调用额外的开销。 但是在QUIC下协议栈旨在由单个应用程序使用,每个应用程序使用QUIC在UDP上托管自己的连接。最终差异可能非常小,因为整个HTTP/2堆栈的大部分已经存在于应用程序(或更常见的库)中。 将剩余部分放在这些库中,基本上是纠错,对HTTP/2堆栈的大小或整体复杂性几乎没有影响。[8]
QUIC允许更容易地进行未来更改,因为它不需要更改内核就可以进行更新。 QUIC的长期目标之一是添加前向纠错和改进的拥塞控制。[20]
关于从TCP迁移到UDP的一个问题是TCP被广泛采用,并且互联网基础设施中的许多中间设备被调整为UDP速率限制甚至阻止UDP。 Google进行了一些探索性实验来描述这一点,发现只有少数连接存在此问题。[3]所以Chromium的网络堆栈同时打开QUIC和传统TCP连接,并在QUIC连接失败时以零延迟回退到TCP连接。[21]
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)。
流量控制
Google BBR
BBR 算法主要出发点是,数据包丢失可能并不意味着网络拥塞。例如,一瞬间的无线电干扰,数据包就可能会丢失。Cubic 和其他基于拥塞的算法不区分这种虚假的损失和真正的拥塞,在两种情况下都降低了它们的发送速率。另一方面,BBR不那么容易受到惊吓。
因此,即使面对次优的网络条件,BBR也能提供持续的吞吐量性能。
实现
客户端
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 服务器中运行[22]。
另有几种不再维护的社区产品,基于Chromium实现并且减少使用依赖的libquic 页面存档备份,存于、提供libquic的Go语言绑定的goquic 页面存档备份,存于、打包为Docker镜像的用来转换为普通HTTP请求的反向代理quic-reverse-proxy 页面存档备份,存于。
参考资料
- QUIC: A UDP-Based Multiplexed and Secure Transport. IETF: sec. 1. I-D draft-ietf-quic-transport-22.
- Nathan Willis. . Linux Weekly News. [2013-07-16]. (原始内容存档于2020-10-16).
- . Jim Roskind, Chromium Contributor. [2015-04-29]. (原始内容存档于2014-11-10).
- . [2012-10-16]. (原始内容存档于2020-04-13).
- . Chromium Official Blog. [2013-07-16]. (原始内容存档于2021-02-05).
- . François Beaufort, Chromium Evangelist.
- . YouTube. [2014-04-04]. (原始内容存档于2020-11-18).
- (PDF). Jim Roskind, Google. [2013-11-07]. (原始内容存档 (PDF)于2014-02-11).
- Lardinois, Frederic. . TechCrunch. [2016-10-25]. (原始内容存档于2020-12-14).
- Christopher Fernandes. . April 3, 2018 [2020-05-08]. (原始内容存档于2020-11-23).
- . bram.us. April 8, 2020 [2021-02-02]. (原始内容存档于2021-01-28).
- . www.fastly.com. [2020-10-21]. (原始内容存档于2020-11-13).
- Tatsuhiro Tsujikawa. . GitHub. [2020-10-17]. (原始内容存档于2021-01-22).
- . InfoQ. [2016-10-25]. (原始内容存档于2020-10-24).
- . i-d-announce (邮件列表). 17 Jun 2015 [2018-12-10]. (原始内容存档于2016-05-26).
- . datatracker.ietf.org. [2016-10-25]. (原始内容存档于2021-02-05).
- Cimpanu, Catalin. . ZDNet. 12 November 2018 [2018-12-10]. (原始内容存档于2018-11-13).
- Bright, Peter. . Arstechnica. 12 November 2018 [2019-04-10]. (原始内容存档于2019-04-10).
- Behr, Michael; Swett, Ian. . Google Cloud Platform Blog. Google. [16 June 2018]. (原始内容存档于2019-04-10).
- . Chromium. [2019-04-10]. (原始内容存档于2019-04-10).
- . IETF Network Working Group. 22 October 2018 [2019-04-10]. (原始内容存档于2019-06-07).
- . w3techs.com. [2018-12-10].
- Darya Bugayova. (html). AdGuard. 2020-12-16 [2020-12-18]. (原始内容存档于2020-12-17) (中文(中国大陆)).
外部連結
- Chromium: QUIC, a multiplexed stream transport over UDP 页面存档备份,存于
- QUIC: Design Document and Specification Rationale页面存档备份,存于, Jim Roskind's original document (2012/2013)
- Daniel Stenberg: HTTP/3 explained 页面存档备份,存于
- Linux Weekly News: Connecting on the QUIC 页面存档备份,存于 (2013)
- QUIC: 页面存档备份,存于, IETF-88 TSV Area Presentation (2013-11-07)
- Chromium Blog: Experimenting with QUIC 页面存档备份,存于 (2013)
- QUIC: next generation multiplexed transport over UDP 页面存档备份,存于 (Google Developers, 2014)
- HTTP over UDP: an Experimental Investigation of QUIC页面存档备份,存于
- Multipath QUIC 页面存档备份,存于 (extension to QUIC)
- Innovating Transport with QUIC: Design Approaches and Research Challenges页面存档备份,存于 (2017)