论文解读《The QUIC Transport Protocol: Design and Internet-Scale Deployment》

    整篇blog将会用通俗的语言，解读流量加密论文《The QUIC Transport Protocol: Design and Internet-Scale Deployment》

背景介绍

    QUIC传输协议的提出，主要目的是为了提高HTTPS流量的性能，并实现传输机制的快速部署和持续发展。QUIC取代了大部分HTTPS中的协议栈，包括HTTP/2、TLS、TCP，并使用UDP作为基层传输协议，如下图所示：

   QUIC是在用户空间当中进行构建的，这有助于将其作为各种应用程序的一部分进行部署，同时也方便迭代更新。

• 在操作系统中，内核空间是操作系统核心代码运行的地方，而用户空间是应用程序运行的地方。传统的TCP协议通常在内核中实现，这意味着对协议的修改需要操作系统的更新，这往往是一个缓慢且复杂的过程。而在用户空间中实现QUIC，则意味着开发者可以在应用程序层面直接修改和部署QUIC协议，而不需要依赖操作系统的更新。
• 由于QUIC在用户空间中实现，开发者可以将其作为应用程序的一部分进行集成和部署。这意味着QUIC可以更容易地嵌入到各种不同的应用程序中，而不需要修改操作系统或网络堆栈。这种灵活性使得QUIC可以快速适应不同的应用场景和需求。
• 应用程序的更新周期通常比操作系统的更新周期要短得多。因此，通过在用户空间中实现QUIC，开发者可以在更短的时间内对协议进行改进和优化，而不需要等待操作系统的更新。这使得QUIC能够更快地适应新的需求和挑战。

   由于QUIC的底层是基于UDP的，因此会允许QUIC数据包穿越中间盒，方便绕过兼容性等一般问题。

• 中间盒（Middlebox）​：中间盒是指位于网络路径中的各种设备，如防火墙、NAT（网络地址转换）设备、负载均衡器等。这些设备通常会对网络流量进行检查和修改。由于TCP协议的复杂性，中间盒往往会对TCP流量进行深度检查，这可能会导致一些性能问题或兼容性问题。
• UDP的优势：由于UDP协议相对简单，中间盒通常不会对UDP流量进行深度检查。因此，使用UDP作为底层传输协议的QUIC数据包可以更容易地穿越这些中间盒，而不会被中间盒修改或拦截。这使得QUIC在复杂的网络环境中具有更好的兼容性和性能。

   QUIC数据包经过了身份验证和加密，从而防止中间盒修改和限制协议僵化。

• 协议僵化（Protocol Ossification）​是指网络协议在实际部署和使用过程中，由于中间设备（如防火墙、NAT、负载均衡器等）的干预或限制，导致协议无法按照设计初衷灵活演进或更新的现象。

   QUIC使用加密握手，通过在重复连接上使用已知的服务器凭据并消除网络堆栈中多层的冗余握手开销，最大限度地减少了大多数连接的握手延迟；同时通过使用轻量级的数据结构抽象流来消除行首阻塞延迟，这些流在单个连接中复用，因此单个数据包的丢失只会阻塞该数据包中的数据流。

• 实际例子可以描述为：
  假设 QUIC 连接中同时传输以下数据：
  流 1：传输网页的 HTML 文件
  流 2：传输网页的 CSS 文件
  流 3：传输网页的 JavaScript 文件
  如果流 2 的某个数据包丢失，QUIC 只会阻塞流 2 的传输，而流 1 和流 3 的数据可以继续被处理。因此，浏览器可以尽快渲染 HTML 和 JavaScript，而不需要等待 CSS 文件完全到达。

   截至目前，QUIC凭借在服务端良好的响应和客户端较低的延迟，被广泛部署。它目前占谷歌总出口流量的30%以上，因此估计占全球互联网流量的7%。下图显示的是QUIC在不同时期占谷歌总出口流量的百分比：

研发QUIC的动机

   为什么需要一个新的传输协议来替代现有的TCP/TLS协议栈？

1. ​Web服务的延迟需求增长

• ​延迟敏感型Web服务的增长：随着Web服务的普及，尤其是那些对延迟敏感的应用程序（如视频流、实时通信等），降低Web延迟的需求变得前所未有的重要。Web延迟仍然是影响用户体验的主要障碍，尤其是在长尾延迟（tail latency）方面，这对Web平台的扩展性提出了挑战。
• 从非安全到安全流量的转变：互联网正在从非安全流量（HTTP）快速转向安全流量（HTTPS），这增加了额外的延迟。例如，下图展示了Google的HTTPS流量在短时间内显著增加。

2. ​TCP/TLS生态系统的根本限制

• 协议固化（Protocol Entrenchment）：尽管有许多新的传输协议被提出以满足不断变化的应用程序需求，但这些协议并未得到广泛部署。中间设备（如防火墙、NAT）往往会阻止不熟悉的流量，或者修改传输头，导致新协议的部署变得非常困难。即使是修改TCP协议，由于中间设备的固化，也变得极具挑战性，简单的协议更改可能需要十年以上的时间才能广泛部署。
• 实现固化（Implementation Entrenchment） ​：TCP通常在内核中实现，因此即使TCP的修改是可部署的，推动这些更改通常需要操作系统升级。这种将传输实现与操作系统耦合的方式限制了TCP更改的部署速度，尤其是在移动设备上，尽管其操作系统升级周期较短，但仍有大量用户落后几年。服务器端的操作系统升级虽然更快，但仍需要数月时间进行稳定性和性能测试。

3. ​握手延迟

• TCP和TLS的握手延迟：TCP连接通常需要至少一个往返时间（RTT）来建立连接，而TLS又增加了两个RTT的延迟。尽管网络带宽不断增加，但光速是恒定的，大多数互联网连接（尤其是Web上的短事务）都受到不必要的握手往返时间的显著影响。

4. ​队头阻塞（Head-of-line Blocking）​

• ​HTTP/1.1和HTTP/2的多路复用问题：为了减少延迟和开销，HTTP/1.1建议限制客户端到服务器的连接数，而HTTP/2则建议使用单个TCP连接来多路复用多个对象。然而，TCP的字节流抽象阻止应用程序控制其通信的帧结构，导致应用程序帧的交付必须等待之前丢失的TCP段的重传，从而增加了延迟。

5. ​部署传输修改的复杂性​

• 部署传输修改的复杂性：为了部署传输协议的修改，通常需要同时修改Web服务器、客户端、服务器和客户端的操作系统中的传输栈，以及中间设备。这需要协调应用程序开发者、操作系统供应商、中间设备供应商和网络运营商，部署过程复杂且耗时。

   QUIC通过加密传输头并在UDP之上构建传输功能，避免了依赖中间设备供应商和网络运营商，将传输部署的控制权交给了直接受益的应用程序。QUIC的设计目标包括：

• ​可部署性：通过使用UDP作为底层协议，QUIC可以绕过中间设备的限制。
• ​安全性：QUIC的传输头是加密的，防止中间设备修改协议。
• 减少握手和队头阻塞延迟：QUIC通过合并加密和传输握手来最小化建立连接的RTT，并通过多路复用流来避免队头阻塞。

QUICD 的设计与实现

链接建立

1. QUIC的加密和传输握手

• 握手的目的：QUIC的握手机制结合了加密和传输功能，旨在快速建立安全的传输连接。握手成功后，客户端会缓存服务器的相关信息，以便在后续连接中快速建立加密连接。

• 初始握手：当客户端首次连接到服务器时，客户端发送一个不完整的“Client Hello”（CHLO）消息，服务器会返回一个“Reject”（REJ）消息。REJ消息包含以下内容：

  • 服务器配置：包括服务器的长期Diffie-Hellman公钥。
  • 证书链：用于验证服务器的身份。
  • 服务器配置的签名：使用证书链中的私钥对服务器配置进行签名。
  • 源地址令牌：一个经过服务器加密的块，包含客户端的IP地址和时间戳。客户端在后续握手中会返回该令牌，以证明其对IP地址的所有权。

• 最终握手：客户端收到服务器配置后，验证其有效性，并发送一个完整的CHLO消息，包含客户端的临时Diffie-Hellman公钥。此时，客户端已经可以计算出初始密钥，并开始向服务器发送加密的应用数据。

2. ​0-RTT连接

• 0-RTT连接的实现：在后续连接中，客户端可以使用缓存的服务器配置和源地址令牌，直接发送完整的CHLO消息，并立即开始发送