论文解读《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消息，并立即开始发送加密的应用数据，而无需等待服务器的响应。这种方式实现了零往返时间（0-RTT）连接，显著减少了连接建立的延迟。
• 初始密钥和最终密钥：QUIC的加密机制提供了两种密钥：
  • ​初始密钥：用于加密客户端在0-RTT握手期间发送的数据，类似于TLS的会话恢复机制。
  • ​最终密钥：在握手完成后，客户端和服务器使用各自的临时Diffie-Hellman私钥计算出最终的密钥，用于加密后续的通信数据。

3. 握手失败的处理

   如果源地址令牌或服务器配置过期，或者服务器更改了证书，握手可能会失败。此时，服务器会返回REJ消息，客户端需要重新进行初始握手。

4. 版本协商机制

   QUIC客户端和服务器在连接建立期间进行版本协商，以避免不必要的延迟。客户端在连接的第一个数据包中提议一个版本号，如果服务器不支持该版本，则会返回一个“Version Negotiation”数据包，列出服务器支持的所有版本，导致一个往返时间的延迟。这种机制鼓励服务器及时部署新版本，并防止降级攻击。

流的多路复用

1. ​流的概念

• 流的定义：QUIC引入了流（Stream）​的概念，流是一个独立的、有序的字节流，可以单向或双向传输数据。每个流都有一个唯一的标识符（Stream ID），用于区分不同的流。
• 流的作用：流允许在同一个QUIC连接中同时传输多个独立的数据流，而不会相互干扰。这种机制类似于HTTP/2中的流，但QUIC的流更加灵活和高效。

2. 流的多路复用

• 多路复用的实现：QUIC通过将多个流的数据复用到同一个连接中，避免了TCP的“队头阻塞”问题。在TCP中，如果一个数据包丢失，后续的所有数据包都会被阻塞，即使它们属于不同的流。而在QUIC中，每个流的数据是独立的，一个流的丢包不会影响其他流的传输。
• ​流控制：QUIC为每个流提供了独立的流控制机制，允许发送方和接收方动态调整每个流的数据传输速率，以避免接收方缓冲区溢出。

3. 流的类型

• 单向流和双向流：QUIC支持两种类型的流：

  • 单向流（Unidirectional Stream）：数据只能从一端流向另一端，例如客户端向服务器发送请求。
  • ​双向流（Bidirectional Stream）​：数据可以双向传输，例如客户端和服务器之间的双向通信。

• 流标识符：流标识符（Stream ID）的低位用于区分流的类型（单向或双向），高位用于区分流的方向（客户端发起或服务器发起）。

4. 流的状态管理

• ​流的状态：每个流都有自己的状态机，包括“打开”、“发送中”、“接收中”和“关闭”等状态。QUIC通过帧（Frame）来管理流的状态，例如发送“STREAM”帧来传输数据，发送“FIN”帧来关闭流。
• ​流的有序性：QUIC保证了每个流内部的数据是有序的，但不同流之间的数据可以是乱序的。这种设计使得QUIC能够更高效地利用网络资源。

5. 流的优先级

• 优先级机制：QUIC允许为每个流设置优先级，优先级高的流会优先获得带宽资源。这种机制可以用于优化应用性能，例如优先传输关键数据。
• ​动态调整：QUIC支持动态调整流的优先级，以适应应用的需求和网络条件的变化。

   前面提到，QUIC的流类似于HTTP/2的流的作用，那么两者到底有什么区别？下面有个简单的例子：

   可能还是有点不理解，这个HTTP/2基于TCP的流说是在丢包的时候会阻塞，那么它设计的流是如何加载数据的？难道这些流也是按照顺序加载的吗 还是交叉加载 还是同时加载？

   说到这里，其实QUIC流的加载方式想必大家都应该猜到了，就是同时加载的，可以类比多进程的亚子！！

身份验证和加密

   通过以下三种机制，QUIC确保了数据包的完整性和安全性，防止了中间盒（middleboxes）的篡改，并限制了协议的僵化（ossification）。

1. 全包认证与加密

• 除了少数早期的握手包和重置包外，QUIC的所有数据包都是完全认证和加密的。
• QUIC包的结构包括一个公共头部和多个帧（如下图所示）。头部中未加密的部分仅包含路由或解密所需的信息，如标志位（Flags）、连接ID（Connection ID）、版本号（Version Number）、多样化随机数（Diversification Nonce）和包号（Packet Number）。
• 标志位用于指示连接ID字段的存在和包号字段的长度，这些信息必须可见以便读取后续字段。
• 连接ID用于路由和识别目的，负载均衡器使用它来将连接流量定向到正确的服务器，服务器则使用它来定位连接状态。
• 版本号和多样化随机数字段仅出现在早期包中。服务器生成多样化随机数并在SHLO包中发送给客户端，以增加密钥生成的熵。
• 包号作为每个包的随机数，用于认证和解密包，类似于DTLS中的机制，从而支持乱序接收和快速解密。
  
     图中的红色部分表示未加密的数据，绿色部分表示加密的数据。

2. 未加密握手包的信息

• 任何在未加密握手包中发送的信息（如版本协商包中的信息）都会包含在最终连接密钥的派生中。
• 如果在网络中篡改了这些握手包，最终连接密钥会在对等方之间不同，导致连接最终失败，无法成功解密任何应用数据。

3. 重置包

• 重置包由没有连接状态的服务器发送，可能由于路由变化或服务器重启导致。
• 由于服务器没有连接密钥，重置包是未加密和未认证的。

丢失恢复

   QUIC通过改进使得其丢失恢复机制比TCP更简单且更有效。QUIC通过独特的包号、精确的RTT估计和丰富的ACK块设计，显著提高了在丢包和乱序情况下的性能。

1. TCP的丢失恢复问题

• TCP使用序列号（sequence numbers）来实现可靠性和字节顺序的传递，但这也导致了“重传歧义”（retransmission ambiguity）问题。
• 当TCP重传一个数据段时，它使用与原始数据段相同的序列号，因此接收方无法区分ACK是对原始数据段还是重传数据段的确认。这通常会导致通过昂贵的超时机制来检测丢失。区分之后，才能执行对应的拥塞控制机制。

2. QUIC的改进设计

• QUIC通过为每个数据包分配唯一的包号（packet number）来解决重传歧义问题，即使是重传的数据包也会使用新的包号。
• 这种设计使得接收方可以明确区分ACK是对原始数据包还是重传数据包的确认，从而避免了TCP中的重传歧义问题。
• QUIC使用流帧（stream frames）中的流偏移量（stream offsets）来进行数据传递的顺序控制，将传递顺序和包号的时间顺序分离，简化了丢失检测机制。

3. 精确的RTT估计

• QUIC的ACK包显式编码了从接收数据包到发送ACK之间的延迟，结合单调递增的包号，QUIC能够更精确地估计网络往返时间（RTT）。
• 精确的RTT估计有助于丢失检测，并且对延迟敏感的拥塞控制算法（如BBR和PCC）也有帮助。

4. ACK块的丰富性

   QUIC的ACK包支持多达256个ACK块，这使得QUIC在存在乱序或丢失的情况下比TCP（使用SACK机制）更具弹性。这种设计使得QUIC能够在乱序或丢失的情况下保持更多的数据在传输中。

流量控制

   在QUIC协议中，​流量控制（Flow Control）​是一个关键机制，用于防止发送方发送过多数据导致接收方缓冲区溢出。

1. 流量控制的目标

• 防止接收方过载：确保发送方不会发送超过接收方缓冲区容量的数据。
• 提高资源利用率：通过动态调整流量控制窗口，优化网络和内存资源的使用。
• ​支持多流并发：为每个流（Stream）和整个连接（Connection）分别实现流量控制。

2. ​流量控制的层次
   1. 连接级流量控制（Connection-Level Flow Control）​
      • 控制整个连接的总数据量。
      • 接收方通过MAX_DATA帧通知发送方连接级流量控制窗口的大小。
      • 发送方必须确保整个连接的数据量不超过接收方的连接级窗口。
   2. ​流级流量控制（Stream-Level Flow Control）
      • 控制单个流的数据量。
      • 接收方通过MAX_STREAM_DATA帧通知发送方每个流的流量控制窗口大小。
      • 发送方必须确保每个流的数据量不超过接收方的流级窗口。
3. 流量控制窗口

• 窗口大小
  • 接收方通过MAX_DATA和MAX_STREAM_DATA帧动态调整窗口大小。
  • 窗口大小表示接收方当前可接收的数据量。
• 窗口更新
  • 接收方在处理数据后，可以发送MAX_DATA或MAX_STREAM_DATA帧更新窗口。
  • 发送方收到窗口更新后，可以继续发送数据。

4. 流量控制的实现

• 发送方行为
  • 发送方必须确保发送的数据量不超过接收方的窗口大小。
  • 如果窗口耗尽，发送方必须等待窗口更新。
• 接收方行为
  • 接收方根据缓冲区使用情况动态调整窗口大小。
  • 接收方通过发送MAX_DATA或MAX_STREAM_DATA帧通知发送方窗口更新。

拥塞控制

   在QUIC协议中，​拥塞控制（Congestion Control）​是一个关键机制，用于防止网络过载并优化数据传输效率。

1. QUIC协议不依赖特定的拥塞控制算法

• ​核心意思：QUIC协议本身并不强制要求使用某一种拥塞控制算法，而是提供了一个可插拔的接口，允许开发者根据需求实现和实验不同的拥塞控制算法。
• ​意义：这种设计使得QUIC能够灵活适应不同的网络环境和应用场景，同时也为拥塞控制算法的创新和优化提供了便利。

2. QUIC和TCP在部署中使用相同的拥塞控制算法

• ​核心意思：在具体的部署中，QUIC和TCP都使用了Cubic算法作为拥塞控制器。
• ​意义：Cubic是一种广泛使用的拥塞控制算法，具有较好的公平性和高效性。选择Cubic作为默认算法，可以确保QUIC与现有TCP网络的兼容性和公平性。

3. 非QUIC客户端在视频播放中使用两个TCP连接

• ​核心意思：在非QUIC的客户端（如传统TCP客户端）中，视频播放时通常使用两个TCP连接来分别获取音频和视频数据。
• ​具体实现：
  • 这两个连接并没有明确指定为音频或视频连接，而是随机分配每个音频或视频数据块到其中一个连接。
• ​意义：使用两个连接可以提高带宽利用率，但也可能带来额外的开销和复杂性。

4. QUIC使用单连接和多流传输音频和视频

• ​核心意思：在QUIC中，音频和视频数据通过单个QUIC连接中的多个流​（Stream）进行传输。
• ​意义：与TCP的双连接设计相比，QUIC的单连接设计减少了连接管理的开销，同时通过多流机制实现了更高效的资源利用。

5. QUIC在拥塞避免阶段使用mulTCP变体

• ​核心意思：为了在流公平性​（Flow-Fairness）方面与TCP的双连接设计保持一致，QUIC在拥塞避免阶段使用了mulTCP的变体来增强Cubic算法。
• ​mulTCP的作用：
  • mulTCP是一种多连接拥塞控制机制，能够模拟多个TCP连接的行为。
  • QUIC通过mulTCP变体，使得单个QUIC连接在拥塞控制方面表现得像多个TCP连接，从而确保与TCP的公平性。
• ​意义：这种设计使得QUIC在视频播放等场景中能够与TCP客户端公平竞争带宽，同时避免了TCP双连接设计的复杂性。

NAT重新绑定和连接迁移

1. NAT重新绑定

• ​定义：NAT（网络地址转换）重新绑定是指当客户端的IP地址发生变化时，NAT设备将客户端的内部地址重新映射到一个新的外部地址。
• ​影响：
  • 在QUIC协议中，NAT重新绑定可能导致连接中断，因为QUIC依赖于客户端和服务器的IP地址来维护连接。
  • 如果NAT重新绑定发生在连接迁移过程中，可能会导致连接失败或数据包丢失。

2. 连接迁移

• ​定义：连接迁移是指QUIC客户端在保持与服务器的连接的同时，从一个网络接口迁移到另一个网络接口（例如，从Wi-Fi切换到蜂窝网络）。
• ​实现机制：
  • QUIC通过使用连接ID​（Connection ID）来标识连接，而不是依赖于IP地址和端口号。
  • 当客户端迁移到新的网络接口时，它会向服务器发送一个新的连接ID，服务器根据这个新的连接ID继续处理数据包。
• ​优势：
  • 连接迁移使得QUIC能够在网络环境变化时保持连接的连续性，提高了用户体验。
  • 与TCP相比，QUIC的连接迁移机制更加灵活和高效。

3. NAT重新绑定与连接迁移的关系

• ​挑战：
  • 在NAT重新绑定的情况下，连接迁移可能会变得更加复杂，因为NAT设备可能会改变客户端的IP地址。
  • QUIC需要处理NAT重新绑定带来的影响，确保连接迁移过程中数据包的正常传输。
• ​解决方案：
  • 使用连接ID（Connection ID）​
    • ​什么是连接ID：
        连接ID是一个唯一标识符，用于标识QUIC连接。它与IP地址和端口号无关。
    • ​如何工作：
        每个QUIC数据包都包含一个连接ID，服务器和客户端通过连接ID来识别数据包属于哪个连接。当客户端迁移到新的网络接口时，它会生成一个新的连接ID，并通过新的网络接口发送给服务器。服务器根据连接ID而不是IP地址来识别连接，因此即使IP地址发生变化，连接仍然可以继续。
  • 采用路径验证（Path Validation）​
    • ​什么是路径验证：
        路径验证是一种机制，用于确保客户端和服务器之间的新路径是有效的。
    • ​如何工作：
       当客户端迁移到新的网络接口时，它会向服务器发送一个 ​路径挑战帧（Path Challenge Frame） ​，其中包含一个随机值。服务器收到挑战帧后，会返回一个 ​路径响应帧（Path Response Frame）​，包含相同的随机值。客户端通过验证响应帧中的随机值，确认新路径是有效的。只有在路径验证成功后，客户端才会开始通过新路径发送数据。

使用HTTPS发现QUIC协议

1. 背景与动机

• ​问题：QUIC作为一种新的传输协议，需要一种机制来让客户端和服务器能够发现彼此是否支持QUIC，并协商是否使用QUIC进行通信。
• ​目标：通过现有的HTTP/HTTPS协议，实现QUIC的发现和协商，避免对现有基础设施的破坏性修改。

2. QUIC的发现机制

• ​Alt-Svc头部：
  • HTTP/1.1和HTTP/2协议中引入了 ​Alt-Svc​（Alternative Services）头部，用于告知客户端存在其他可用的服务（例如QUIC）。
  • 服务器在HTTP响应中包含 Alt-Svc 头部，指定支持QUIC的地址和端口号。
  • 示例：Alt-Svc: h3=":443"; ma=3600，表示服务器支持HTTP/3（基于QUIC），端口为443，缓存时间为3600秒。
• ​客户端行为：
  • 客户端在收到 Alt-Svc 头部后，会尝试使用QUIC连接到指定的地址和端口。
  • 如果QUIC连接成功，客户端会优先使用QUIC进行后续通信；如果失败，则回退到HTTP/1.1或HTTP/2。

3. QUIC的协商机制

• ​HTTP/3的标识：
  • HTTP/3基于QUIC协议，使用 h3 作为协议标识符。
  • 在 Alt-Svc 头部中，服务器通过 h3 标识符告知客户端支持HTTP/3。
• ​版本协商：
  • QUIC协议支持版本协商机制，客户端和服务器可以通过协商确定使用哪个版本的QUIC。
  • 如果客户端和服务器支持的QUIC版本不匹配，则会回退到HTTP/1.1或HTTP/2。

4. 回退机制

• ​QUIC连接失败：
  • 如果客户端尝试使用QUIC连接失败（例如服务器不支持QUIC或网络条件不允许），则会回退到HTTP/1.1或HTTP/2。
  • 这种回退机制确保了即使QUIC不可用，通信仍然可以继续进行。
• ​缓存策略：
  • 客户端会根据 Alt-Svc 头部中的缓存时间（ma 参数）缓存QUIC的支持信息。
  • 在缓存时间内，客户端会优先尝试使用QUIC；缓存过期后，客户端会重新尝试发现QUIC。

5. 安全性考虑

• ​防止降级攻击：
  • QUIC的发现和协商机制需要防止恶意攻击者强制客户端回退到不安全的协议（例如HTTP/1.1）。
  • 通过使用HTTPS和TLS加密，确保 Alt-Svc 头部的完整性和安全性。
• ​验证机制：
  • 客户端在尝试使用QUIC连接时，需要验证服务器的证书和身份，确保通信的安全性。

实验框架

  第四节“实验框架”主要描述了Google在开发和部署QUIC协议时所使用的实验框架。该框架旨在通过持续的互联网规模实验来评估QUIC的各种功能和参数，并确保其安全性和性能。

1. ​Chrome的实验框架：

• QUIC的开发依赖于Chrome的实验框架，该框架允许对新功能进行A/B测试，并在全面推出之前进行评估。
• Chrome的实验框架会随机将客户端分配到不同的实验中，并导出广泛的指标，如HTTP错误率和传输握手延迟。
• 客户端如果选择参与统计数据收集，会报告其统计数据及其分配到的实验，从而使得能够按实验切片分析指标。
• 该框架还允许快速禁用任何实验，从而保护用户免受问题实验的影响。

2. 服务器端的实验框架：

• Google的服务器端由数千台分布在全球的机器组成，这些前端服务器处理所有服务的传入TLS/TCP和QUIC连接，并在内部应用服务器之间进行负载均衡。
• 每台服务器都有能力开启或关闭特定功能，这使得能够快速禁用有问题的功能。
• 服务器报告与当前和历史QUIC连接相关的性能数据，这些数据由集中监控系统收集，并提供可视化和警报。

3. 实验框架的作用：

• 该框架使得能够安全地在全球范围内对用户进行QUIC部署，并通过持续反馈指导QUIC的设计。
• 监控广泛的指标使得能够防止回归，并避免由于快速演变而带来的不必要风险。
• QUIC实验的结果不仅以传输层面的指标（如数据包重传率）呈现，还以用户和应用为中心的性能指标（如网页搜索响应时间或视频播放的缓冲率）量化。

互联网规模部署

  QUIC的全球部署过程并非一帆风顺，但通过实验框架和快速响应机制，Google能够及时发现问题并优化协议。QUIC的逐步推广和性能改进证明了其在减少延迟、提高用户体验方面的潜力，尤其是在移动端和视频流媒体应用中。

1. QUIC的部署时间线

• ​初始阶段：QUIC于2013年6月首次添加到Chrome中，最初仅通过命令行标志启用，仅限于开发团队使用。
• ​逐步推广：2014年初，QUIC通过Chrome的实验框架对极少数用户（<0.025%）启用。随着QUIC被证明是安全和高效的，启用范围逐步扩大。
• ​全面部署：截至2017年1月，QUIC已几乎对所有Chrome用户和Android版YouTube应用启用。

2. 部署过程中的关键事件

• ​0-RTT请求的未加密数据漏洞：
  • 2015年12月，发现QUIC握手实现中的一个漏洞，可能导致0-RTT请求在极少数情况下未加密发送。
  • 作为应对措施，Google立即在全球范围内禁用QUIC，直到客户端更新修复该漏洞。
    ​
• 移动端QUIC的推广：
  • 2016年9月，YouTube应用开始使用QUIC，使得Google的QUIC出口流量从15%增加到30%以上。

3. 性能监控与指标

• 搜索延迟（Search Latency）
  • 搜索延迟是指从用户输入搜索词到所有搜索结果内容（包括图像和嵌入内容）生成并交付给客户端的延迟。
  • 通过监控搜索延迟，发现QUIC在18个月内的性能改进：
    • 2015年7月，由于基础设施变更和客户端配置错误，QUIC性能出现显著下降。
    • 2015年12月，QUIC被完全禁用，导致搜索延迟回归到基线水平。
    • 2016年7月，通过在受限边缘位置（RELs）部署UDP代理，QUIC的平均搜索延迟改进从4%提升到7%以上。
      

4. ​QUIC的全球部署效果

• QUIC的部署不仅提高了搜索延迟，还显著减少了视频播放的缓冲率。
• 通过持续的监控和优化，QUIC在全球范围内逐步展现出其性能优势，尤其是在高延迟和丢包率较高的网络环境中。

QUIC性能与实验框架

1. QUIC性能

• 目标：QUIC的开发与部署主要基于三个关键应用指标：搜索延迟（Search Latency）、视频播放延迟（Video Playback Latency）和视频缓冲率（Video Rebuffer Rate）。
• 实验设置：用户被随机分配到QUIC实验组（QUICg）或TLS/TCP对照组（TCPg）。QUICg组包括无法使用QUIC的用户，但大多数用户能够使用QUIC，且其流量主要是QUIC。
• ​应用场景：桌面用户通过Chrome访问服务，移动用户通过专用应用（如Google Search和YouTube）访问。

2. 实验设置

• 客户端：QUICg组使用QUIC，TCPg组使用HTTP/2（搜索）或HTTP/1.1（视频播放）。
• 拥塞控制：QUIC和TCP都使用Cubic算法进行拥塞控制。
• 数据来源：所有数据基于QUIC版本35，样本量超过10亿，搜索数据来自2016年12月12日至19日，视频播放数据来自2017年1月19日至26日。

3. 传输与应用指标

• 握手延迟：QUIC的0-RTT和1-RTT握手显著减少了握手延迟，尤其是在高RTT环境下。88%的QUIC连接实现了0-RTT握手，减少了至少2-RTT的延迟。
• 应用指标：网络延迟只是端到端应用延迟的一部分，但即使小幅度的延迟减少也能显著影响用户体验和收入。例如，Amazon估计每增加100ms延迟，利润减少1%。
  

4. 搜索延迟

• ​定义：搜索延迟是从用户输入搜索词到所有搜索结果（包括图片和嵌入内容）生成并交付给客户端的时间。
• ​性能提升：QUICg组的搜索延迟平均减少了8.0%（桌面）和3.6%（移动）。在高RTT环境下，QUIC的延迟减少更为显著，主要得益于0-RTT握手和更有效的丢包恢复机制。
  ​

5. 视频播放延迟

• ​定义：视频播放延迟是从用户点击播放按钮到视频开始播放的时间。
• ​性能提升：QUICg组的视频播放延迟平均减少了8.0%（桌面）和5.3%（移动）。QUIC的改进在高RTT和高丢包率环境下尤为明显。
  ​

6. 视频缓冲率

• ​定义：视频缓冲率是视频播放过程中因缓冲中断播放的频率。
• ​性能提升：QUICg组的视频缓冲率平均减少了18.0%（桌面）和15.3%（移动）。QUIC的丢包恢复机制和流控策略有效减少了缓冲中断。
  ​

7. 服务器CPU利用率

• ​QUIC的CPU开销：QUIC的加密和流控机制增加了服务器的CPU开销，但通过优化和硬件加速，QUIC的CPU利用率在可接受范围内。
• ​与TCP的对比：QUIC的CPU开销高于TCP，但其性能提升（如减少延迟和缓冲率）抵消了额外的CPU成本。

8. QUIC的已知性能限制

• ​路径MTU问题：QUIC的握手包可能超过路径的MTU，导致握手失败，客户端回退到TLS/TCP。
• ​NAT和防火墙问题：某些NAT和防火墙可能阻止QUIC流量，尤其是在UDP端口受限的环境中。
• ​移动网络问题：移动网络中的UDP流量可能受到限制或优先级较低，影响QUIC的性能。
  ​

9. 未来改进方向

• ​IETF标准化：QUIC的IETF标准化将模块化协议，分离核心协议、HTTP映射和TLS 1.3握手，进一步提升灵活性和互操作性。
• ​硬件加速：通过硬件加速进一步降低QUIC的CPU开销。
• ​路径优化：改进QUIC在MTU受限路径和移动网络中的表现，减少回退到TCP的情况。

实验和经验

1. 数据包大小选择

• 问题：选择QUIC的最大数据包大小需平衡可靠性与性能。
• 实验：
  • ​测试范围：UDP负载从1200字节到1500字节，每次增加5字节。
  • ​方法：客户端发送不同大小的UDP包至回显服务器，统计可达性。
• 结果：
  • 超过1450字节的负载（加上IP/UDP头后超过以太网MTU 1500字节）导致不可达性急剧上升（如下图）。
  • 选择1350字节作为默认QUIC负载大小，避免路径分片风险。
• 意义：确保QUIC在大多数网络中无需路径MTU发现即可可靠传输
  

2. UDP阻塞与限速

• 现状​（2016年11月数据）：
  • ​95.3%用户成功使用QUIC。
  • ​4.4%因企业防火墙或MTU过小无法使用QUIC。
  • ​0.3%遭遇网络限速（高峰时段丢包率上升、带宽下降）。
• 应对措施：
  • 对限速的自治系统（AS）手动禁用QUIC，联系运营商调整策略。
  • 合作效果：AS限速比例从2015年6月的1%降至2016年11月的0.3%。
• 启示：企业网络是QUIC部署的主要障碍，但ISP级阻塞罕见。

3. 前向纠错（FEC）的尝试与放弃

• 动机：通过冗余数据减少重传，改善延迟（基于单包丢失常见假设）。

• 实验设计：

  • 使用基于XOR的简单奇偶校验FEC，可恢复单个丢包。
  • 测试不同策略（仅保护HTTP头、全数据保护、静默期发送FEC包）。

• 结果：

  • ​搜索延迟：无显著改善。
  • ​视频播放：带宽压力增加，导致缓冲率上升。
  • ​丢包分析：仅30%的丢包事件是单包丢失（如下图），多包丢失时FEC无效。

• 结论：移除FEC支持，采用主动尾部重传策略更有效且节省带宽。
  

4. 用户态开发的优势

• 实践亮点：
  • ​测试与调试：单元测试、端到端测试及网络模拟器提前发现关键Bug。
  • ​日志记录：详细记录连接状态，帮助发现并修复Cubic算法静默期Bug，使QUIC重传率降30%、CPU利用率降17%。
  • ​快速迭代：用户态代码更新灵活，版本迭代周期短（如下图）。
• 优势：相比内核开发，用户态更灵活、易调试，加速协议优化。
  

5. 与中间件的“斗争”

• 案例：
  • ​问题：修改QUIC头部1比特导致某防火墙误判（初始包通过，后续包被阻）。
  • ​后果：客户端陷入QUIC黑洞，无法触发TCP回退。
  • ​解决：回滚修改，联系厂商更新分类器。
• 教训：
  • 中间件 协议固化（Ossification） 普遍，依赖未加密字段识别流量。
  • ​加密必要性：加密协议头部是防止中间件干扰的唯一手段。
  • ​部署悖论：协议变更需广泛兼容中间件，而中间件仅响应已部署的变更。

结束了 man!!!