Cloudflare: 通往 QUIC 之路（The Road to QUIC）

小提示：您能找到这篇{Cloudflare: 通往 QUIC 之路（The Road to QUIC）}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Cloudflare: 通往 QUIC 之路（The Road to QUIC）内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">作者：Alessandro Ghedini，原文地址：https://blog.cloudflare.com/the-road-to-quic/

< font-size: 16px;">QUIC(Quick UDP Internet Connections)是一种新的默认加密Internet传输协议，它提供了许多改进，旨在加速HTTP通信并使其更加安全，其目标是最终取代web上的TCP和TLS。在这篇博文中，我们将概述QUIC的一些关键特性，它们如何为web带来好处，以及支持这个新协议所面临的一些挑战。

< font-size: 16px;">

< font-size: 16px;">事实上，有两个协议同名：“Google QUIC”（简称gQUIC），是Google工程师几年前设计的原始协议，经过多年的试验，现在已经被IETF（互联网工程任务组）采用进行标准化。

< font-size: 16px;">“IETF-QUIC”（从现在起就是“QUIC”）已经与gQUIC有相当大的不同，因此可以将其视为一个单独的协议。从数据包的格式，到握手（handshake）和HTTP映射，QUIC改进了最初的gQUIC设计，这得益于许多组织和个人的开放协作，共同的目标是使互联网更快、更安全。

< font-size: 16px;">那么，QUIC提供了哪些改进？

< font-size: 16px;">内置安全性（和性能）

< font-size: 16px;">QUIC与现在受人尊敬的TCP的一个更根本的差别是，它的设计目标是提供一个默认安全的传输协议。QUIC通过提供安全特性来实现这一点，比如身份验证和加密，这些特性通常由比传输协议本身更高层的协议（如TLS）处理。

< font-size: 16px;">QUIC初始握手合并了TCP的典型三次握手和TLS 1.3握手，提供了端点的身份验证和密码参数的协商。对于那些熟悉TLS协议的人，QUIC用自己的帧格式替换TLS记录层，同时保持相同的TLS握手消息。

< font-size: 16px;">这不仅可以确保连接始终经过身份验证和加密，而且还可以加快初始连接的建立：与TCP和TLS 1.3握手组合起来所需的2次RTT（round-trip）相比，典型的QUIC握手只需在客户端和服务器之间进行1次RTT。

< font-size: 16px;">

< font-size: 16px;">

< font-size: 16px;">但QUIC更进一步，它还加密了额外的连接元数据（metadata），这些元数据可能被中间设备（middle-boxes）滥用来干扰连接。例如，当使用连接迁移（connection migration）时，被动路径攻击者可使用数据包编号关联多个网络路径上的用户活动（见下文）。通过加密数据包编号，QUIC确保除了连接中的端点之外，任何人都不能使用它们来关联用户的活动。

< font-size: 16px;">加密也可以是对僵化（ossification）的一种有效的补救措施，它使得协议中内置的灵活性（例如能够协商（negotiate）该协议的不同版本）。由于实现中的错误假设而无法在实践中使用（僵化（ossification）是导致TLS 1.3长时间无法部署的原因，这只有在几次修改后才可能实现，这些修改旨在防止僵化的中间设备（middle-boxes）错误地阻塞TLS协议的新修订）。

< font-size: 16px;">队头阻塞（Head-of-line blocking）

< font-size: 16px;">HTTP/2的主要改进之一是能够将不同的HTTP请求多路复用（multiplexing）到同一个TCP连接上。这允许HTTP/2应用程序并发地处理请求，并更好地利用可用的网络带宽。

< font-size: 16px;">与当时的现状相比，这是一个很大的改进，即如果应用程序希望同时处理多个HTTP/1.1请求，则需要启动多个TCP+TLS连接（例如，当浏览器需要同时获取CSS和Javascript资源来呈现网页时）。初始的握手会减慢初始页面的传输速度，这意味着需要多次刷新新页面。多路复用（Multiplexing）HTTP避免了所有这些问题。

< font-size: 16px;">

< font-size: 16px;">

< font-size: 16px;">然而，这也有一个缺点：由于多个请求/响应是通过同一个TCP连接传输的，因此它们都会受到数据包丢失（例如，由于网络拥塞）的影响，即使丢失的数据只涉及单个请求。这被称为“队头阻塞”（head-of-line blocking）。

< font-size: 16px;">QUIC更深入一点，为多路复用提供一流的支持，这样不同的HTTP流可以映射到不同的QUIC传输流，但是它们仍然共享相同的QUIC连接，因此不需要额外的握手和共享拥塞状态。但是QUIC流是独立的，这样在大多数情况下，一个流的包丢失不会影响其他流。

< font-size: 16px;">例如，这可以显著减少呈现完整网页（使用CSS、Javascript、推广软文大全图片和其他类型的资源）所需的时间，尤其是在穿越高度拥挤的网络、具有高数据包丢失率的网络时。

< font-size: 16px;">这么简单，呃？

< font-size: 16px;">为了实现它的承诺，QUIC协议需要打破许多网络应用程序认为理所当然的一些假设，这可能会使QUIC的实现和部署更加困难。

< font-size: 16px;">QUIC被设计在UDP数据报之上传输，以便于部署，并避免网络设备丢弃未知协议的数据包，因为大多数设备已经支持UDP。这也允许QUIC实现在用户态（user-space）中生存，因此，例如浏览器将能够实现新的协议特性并将其发送给用户，而不必等待操作系统的更新。（而TCP协议的更新受到网络设备和操作系统内容的约束，这也是QUIC设计在UDP之上的原因之一）

< font-size: 16px;">然而，尽管预期的目标是避免破坏，但它也使得防止滥用和正确地将数据包路由到正确的端点更具挑战性。

< font-size: 16px;">一个NAT把他们都带来，在黑暗中捆绑他们（One NAT to bring them all and in the darkness bind them）

< font-size: 16px;">典型的NAT路由器可以使用传统的4元组（源IP地址和端口、目的IP地址和端口）来跟踪经过它们的TCP连接，并通过观察在网络上传输的TCP SYN、ACK和FIN包，来检测新连接何时建立和何时终止。这使它们能够精确地管理NAT绑定的生命周期（lifetime），内部IP地址和端口之间的关联，以及外部IP地址和端口之间的关联。

< font-size: 16px;">对于QUIC，这还不可能，因为现在广泛部署的NAT路由器还不了解QUIC，所以它们通常会退回（fallback）到默认和不太精确的处理UDP流，这通常涉及使用任意的，有时非常短的超时，这可能会影响长时间运行的连接。

< font-size: 16px;">当NAT重新绑定发生时（例如由于超时），NAT外围外部的端点将看到来自不同源端口的数据包，而不是最初建立连接时观察到的源端口，这使得仅使用4元组无法跟踪连接。

< font-size: 16px;">

< font-size: 16px;">不仅仅是NAT！QUIC打算提供的特性之一称为“连接迁移”（connection migration），它允许QUIC端点随意将连接迁移到不同的IP地址和网络路径。例如，当已知的WiFi网络可用时（比如当用户进入他们最喜欢的咖啡店时），移动客户端将能够在蜂窝数据网络和WiFi之间迁移QUIC连接。

< font-size: 16px;">QUIC试图通过引入连接ID（connection ID）的概念来解决这个问题：一个由QUIC包携带的可变长度的不透明blob，可以用来标识连接。端点可以使用这个ID来跟踪它们负责的连接，而不需要检查4元组（实际上，同一个连接可能有多个ID标识，例如，在使用连接迁移（connection migration）时，为了避免链接不同的路径，但是这种行为由端点控制而不是中间设备控制）。

< font-size: 16px;">然而，这也给使用选播（anycast）寻址和ECMP路由的网络运营商带来了一个问题，在这些网络运营商中，一个目的地IP地址可能识别数百甚至数千个服务器。由于这些网络使用的边缘路由器还不知道如何处理QUIC流量，因此可能会发生属于同一QUIC连接（即具有相同连接ID）但具有不同4元组（由于NAT重新绑定或连接迁移）的UDP数据包可能最终被路由到不同的服务器，从而中断了连接。

< font-size: 16px;">

< font-size: 16px;">为了解决这一问题，网络运营商可能需要采用更智能的第4层负载平衡解决方案，这种解决方案可以在软件中实现，并且无需接触边缘路由器即可部署（例如，Facebook的Katran项目）。

< font-size: 16px;">QPACK

< font-size: 16px;">HTTP/2引入的另一个好处是头部压缩（或HPACK），它允许HTTP/2端点通过删除HTTP请求和响应中的冗余来减少通过网络传输的数据量。

< font-size: 16px;">特别是，在其他技术中，HPACK使用动态表填充了从以前的HTTP请求（或响应）发送（或接收）的头，允许端点在新的请求（或响应）中引用以前遇到的头，而不必重新传输它们。

< font-size: 16px;">HPACK的动态表需要在编码器encoder（发送HTTP请求或响应的一方）和解码器decoder（接收它们的一方）之间同步，否则解码器decoder将无法解码它接收到的内容。

< font-size: 16px;">对于TCP之上的HTTP/2，这种同步是透明的，因为传输层（TCP）负责以相同顺序发送HTTP请求和响应，更新表的指令可以由编码器encoder作为请求（或响应）本身的一部分发送，从而使编码非常简单。但对QUIC来说，这更复杂。

< font-size: 16px;">QUIC可以在不同的流上独立地传递多个HTTP请求（或响应），这意味着，尽管它负责按单流的顺序传递数据，但在多个流之间不能保证排序。

< font-size: 16px;">例如，如果客户端通过QUIC stream A发送HTTP请求A，而通过stream B发送请求B，则由于网络中的数据包重新排序或丢失，服务器可能会在请求A之前接收到请求B，并且如果请求B被用来自请电视广告 报价求A的报头编码，服务器将无法解码，因为它还没有看到请求A。

< font-size: 16px;">在gQUIC协议中，这个问题只需在同一个gQUIC流上序列化所有HTTP请求和响应头（而不是主体），这意味着无论发生什么，消息头都将按顺序传递。这是一个非常简单的方案，它允许实现（implementations）重用大量现有的HTTP/2代码，但另一方面，它增加了QUIC原本设计减少的队头阻塞（head-of-line blocking）。IETF QUIC工作组因此设计了HTTP和QUIC之间的新映射（“HTTP/QUIC”），以及一种称为“QPACK”的头压缩新方案。

< font-size: 16px;">在HTTP/QUIC映射和QPACK规范的最新草案中，每个HTTP请求/响应交换都使用自己的双向QUIC流，因此没有队头阻塞（head-of-line blocking）。另外，为了支持QPACK，每个peer方创建两个e额外的单向QUIC流，一个用于向另一个peer方发送QPACK表更新，另一个用于确认另一方接收到的更新。这样，QPACK编码器encoder只有在解码器decoder显式地确认了动态表引用之后才能使用它。

< font-size: 16px;">偏转反射（Deflecting Reflection）

< font-size: 16px;">基于UDP的协议中的一个常见问题是它们容易受到反射攻击（reflection attacks），即攻击者通过欺骗数据包的源IP地址，使其看起来像是来自受害者，从而欺骗原本无辜的服务器向第三方受害者发送大量数据。

< font-size: 16px;">

< font-size: 16px;">当服务器发送的响应恰好大于它接收到的请求时，这种攻击非常有效，在这种情况下，我们称之为“放大”。

< font-size: 16px;">TCP通常不用于此类攻击，因为在其握手(SYN,SYN+ACK,…)过程中传输的初始数据包具有相同的长度，因此它们不会提供任何潜在放大攻击的风险。

< font-size: 16px;">另一方面，QUIC的握手是非常不对称的：就像TLS一样，在它的第一次传输中，QUIC服务器通常发送自己的证书链（certificate chain），它可能非常大，而客户端只需发送几个字节（TLS ClientHello消息嵌入QUIC包中）。因此，客户端发送的初始QUIC包必须填充到特定的最小长度（即使包的实际内容要小得多）。然而，这种缓解仍然不够，因为典型的服务器响应跨越多个数据包，因此仍然可以远远大于填充的客户端数据包。

< font-size: 16px;">QUIC协议还定义了一个显式的源地址验证（source-address verification）机制，在该机制中，服务器不发送长响应，只发送一个很小的“重试（retry）”包，其中包含一个唯一的加密令牌，然后客户端必须在新的初始包中向服务器回显。这样，服务器就有了更高的信心，即客户机不会欺骗自己的源IP地址（因为它收到了重试数据包（retry packet）），并且可以完成握手。这种缓解的缺点是，它将初始握手持续时间从1次RTT增加到2次。

< font-size: 16px;">另一种解决方案包括减少服务器对反射攻击（reflection attack）变得不那么有效的响应，例如使用ECDSA证书（通常比RSA证书小得多）。我们还一直在尝试使用现成的压缩算法（如zlib和brotli）压缩TLS证书的机制，这是gQUIC最初引入的一个特性，但目前在TLS中还没有。

< font-size: 16px;">UDP性能

< font-size: 16px;">QUIC经常出现的一个问题是现在广泛部署的硬件和软件无法理解它。我们已经在另一个C端的路由器上测试了数据的传输性能。我们已经了解了QUIC如何尝试处理像路由器这样的网络中间设备，但是另一个潜在的问题是在QUIC端点上通过UDP发送和接收数据的性能。多年来，人们做了大量的工作来尽可能地优化TCP的实现，包括在软件（如操作系统）和硬件（如网络接口）中构建卸载功能，但目前还没有一种方法可用于UDP。

< font-size: 16px;">然而，等QUIC实现时也能利用这些功能，这只是时间问题。例如，最近在Linux上实现UDP通用分段卸载的工作，它允许应用程序以单个UDP段（或足够接近）的代价在用户态（user-space）和内核态（kernel-space）网络堆栈之间捆绑和传输多个UDP段，除了在Linux上添加零拷贝套接字支持之外，还允许应用程序避免将用户态（user-space）内存复制到内核空间的成本。

< font-size: 16px;">结论

< font-size: 16px;">与HTTP/2和TLS 1.3一样，QUIC将提供许多新特性，这些特性旨在提高web站点的性能和安全性，以及其他基于Internet的资产。IETF工作组目前正准备在今年年底发布QUIC规范的第一版，Cloudflare的工程师们已经在努力工作，为我们所有的客户提供QUIC的好处。