学习：《The QUIC Transport Protocol: Design and Internet-Scale Deployment》

文章目录

一、引言
[二、IP 协议回顾：面向无连接的网络层基础](#二、IP 协议回顾：面向无连接的网络层基础)
- [2.1 IP地址与子网划分](#2.1 IP地址与子网划分)
- [2.2 ARP协议](#2.2 ARP协议)
- [2.3 DHCP 协议](#2.3 DHCP 协议)
- [2.4 IP 分片](#2.4 IP 分片)
[三、TCP 协议回顾：可靠、面向字节流的传输协议](#三、TCP 协议回顾：可靠、面向字节流的传输协议)
[四、UDP 协议回顾：无连接、轻量但不可靠](#四、UDP 协议回顾：无连接、轻量但不可靠)
[五、QUIC 协议学习](#五、QUIC 协议学习)
- [5.1 Why QUIC？](#5.1 Why QUIC？)
- [5.2 QUIC设计](#5.2 QUIC设计)
- - [5.2.1 建立连接](#5.2.1 建立连接)
  - - [Initial 1-RTT Handshake（首次连接的 1-RTT 握手）](#Initial 1-RTT Handshake（首次连接的 1-RTT 握手）)
    - [Successful 0-RTT Handshake（成功的 0-RTT 握手）](#Successful 0-RTT Handshake（成功的 0-RTT 握手）)
    - [Rejected 0-RTT Handshake（失败的 0-RTT 握手）](#Rejected 0-RTT Handshake（失败的 0-RTT 握手）)
    - 注意
  - [5.2.2 版本协商机制：乐观协商，避免冗余延迟。](#5.2.2 版本协商机制：乐观协商，避免冗余延迟。)
  - [5.2.3 流的实现](#5.2.3 流的实现)
  - - 流多路复用功能
  - [5.2.4 丢包检测和重传](#5.2.4 丢包检测和重传)
  - [5.2.5 流量控制](#5.2.5 流量控制)
  - [5.2.6 拥塞控制机制](#5.2.6 拥塞控制机制)
  - [5.2.7 连接迁移](#5.2.7 连接迁移)
- 总结

一、引言

在深入理解 QUIC 协议之前，有必要重新梳理其运行环境和前置协议体系。QUIC 基于 UDP 承载，却实现了类似 TCP 的可靠传输、拥塞控制以及更快的连接建立过程。因此，从"网络层 → 传输层 → QUIC"顺序回顾 IP、TCP、UDP，将有助于理解 QUIC 的设计动机以及其相对于传统 TCP 的创新。

二、IP 协议回顾：面向无连接的网络层基础

IP（Internet Protocol）处于网络层（L3），负责跨网络寻址与路由，是整个网络通信的核心基础。IP 本质上提供的是无连接、不可靠、尽力而为（best effort）的传输服务。

2.1 IP地址与子网划分

一个IPv4地址由网络号和主机号构成，子网掩码决定了网络部分和主机部分的边界。

例如：

复制代码

192.168.1.10 / 24

2.2 ARP协议

IP 层虽然负责跨网络寻址，但在本地链路（如 Ethernet）上发送数据包时，必须知道目标主机的 MAC 地址。ARP（Address Resolution Protocol）用于解决：

复制代码

已知 IP → 获取 MAC 地址

工作流程：广播查询+单播响应。核心是维护ARP缓存表

2.3 DHCP 协议

DHCP（Dynamic Host Configuration Protocol）负责自动分配 IP 信息和配置网络参数。核心参数：

IPv4地址
子网掩码
默认网关
DNS服务器地址
租约期限

典型流程：

Discover：客户端广播发现 DHCP 服务器
Offer：服务器提供可用 IP
Request：客户端请求该 IP
ACK：服务器确认并下发租约

2.4 IP 分片

MTU（Maximum Transmission Unit）表示链路层一次能发送的最大数据帧大小（常见值：Ethernet：1500 字节）。

如果 IP 包大于链路层 MTU，路由器必须将其切割成多个"分片"进行发送。

注意点：

IP 分片的发送与转发可能发生在多个路由器，重组（Reassembly）仅在最终接收端进行。
任意一个分片丢失 → 整个 IP 报文作废

三、TCP 协议回顾：可靠、面向字节流的传输协议

TCP（Transmission Control Protocol）位于传输层，提供面向连接、可靠、按序的字节流传输服务。它是互联网上使用最广泛的传输协议之一，为 HTTP/1.1、HTTP/2 等协议提供基础。

核心特性：

面向连接：通信前必须建立连接（三次握手），通信结束需要关闭连接（四次挥手）。
- 需要额外的 RTT维护连接状态
- 状态保存在内核，迁移困难
可靠传输
- 重传机制
- 累积 ACK
- 滑动窗口
- 流量控制
- 拥塞控制
面向字节流

四、UDP 协议回顾：无连接、轻量但不可靠

UDP（User Datagram Protocol）位于传输层，但它的设计理念完全不同：尽可能简化协议栈，让应用层自行实现可靠性与控制逻辑。

特性。

UDP 在结构上几乎完全依赖 IP，功能极为有限，仅提供：

端口（Port）抽象：实现应用级复用与分用
校验和（Checksum）：提供基础的数据完整性验证（IPv4 可选，IPv6 必选）。

UDP 是以消息为边界的协议，每次发送都是一个独立的数据报（IP层可能会进行拆分，但是UDP无感）。

五、QUIC 协议学习

学习的主要内容来源于论文：《The QUIC Transport Protocol: Design and Internet-Scale Deployment》

5.1 Why QUIC？

QUIC主要对比对象是传统的TLS/TCP体系，存在的问题：

TCP协议固化，难以升级
现有的网络体系架构中，网络中间节点（防火墙、NAT等）已经固化，难以修改（代价巨大，但收益甚微），互联网技术发展日新月异，TCP却难以修改
TCP实现固化
TCP 协议通常集成于操作系统内核，其修改与部署需依赖 OS 升级。
握手延迟
TCP 与 TLS 的分层架构导致显著的握手开销：TCP 连接建立需至少 1 个往返时间（RTT），TLS 握手额外增加 2 个 RTT。互联网中绝大多数连接（尤其是 Web 事务）均为短连接传输，这类连接受冗余握手往返延迟的影响最为严重。
队头阻塞延迟
为优化性能，HTTP/1.1 限制客户端向同一服务器的并发连接数，HTTP/2 进一步采用多路复用技术，通过单一 TCP 连接传输多个对象。但 TCP 的字节流抽象特性导致应用层无法控制通信帧结构，若某一 TCP 段丢失，后续所有应用层帧均需等待该段重传完成才能传输，形成队头阻塞，大幅增加延迟开销。

5.2 QUIC设计

5.2.1 建立连接

Initial 1-RTT Handshake（首次连接的 1-RTT 握手）

这是客户端无服务器缓存信息时的首次连接流程，耗时 1 个往返时间（RTT）：

客户端先发送Inchoate CHLO（初始客户端 Hello），仅请求服务器配置（无敏感信息）；
服务器返回REJ（配置响应），包含服务器长期公钥、证书、源地址令牌等核心配置；
客户端验证REJ中的配置后，发送Complete CHLO（完整客户端 Hello，含自身临时公钥），同时附带用初始密钥加密的请求数据（Encrypted request）；
服务器收到后，返回SHLO（服务器 Hello，含自身临时公钥），同时发送用前向安全密钥加密的响应数据（Encrypted response）；
至此，双方完成密钥协商并切换到前向安全密钥，1-RTT 内完成 "握手 + 数据传输"。

Successful 0-RTT Handshake（成功的 0-RTT 握手）

这是客户端已缓存服务器配置时的重复连接流程，无需等待服务器响应即可传输数据：

客户端直接发送Complete CHLO（完整客户端 Hello），同时附带用初始密钥加密的请求数据（Encrypted request）；
服务器验证缓存的配置有效后，直接返回SHLO（服务器 Hello）和用前向安全密钥加密的响应数据（Encrypted response）；
整个流程客户端无需等待服务器的任何前置响应，实现 "0-RTT 延迟" 传输数据。

Rejected 0-RTT Handshake（失败的 0-RTT 握手）

这是重复连接时缓存信息失效（如令牌过期、配置更新）的场景，流程退化为类首次连接：

客户端直接发送Complete CHLO和加密请求数据，但服务器发现缓存信息无效，返回REJ（重新下发配置）；
客户端收到REJ后，重新发送Complete CHLO和加密请求数据；
服务器验证新配置后，返回SHLO和响应数据，最终完成连接（此时耗时恢复为 1-RTT）。

注意

QUIC 能融合 TCP 与 TLS 握手，本质是基于 UDP 的 "用户态实现"，脱离了操作系统内核的限制。
初始密钥仅用于 "握手初期的加密（如 Complete CHLO、首个请求数据）"，服务器返回 SHLO 后会立即切换为前向安全密钥，初始密钥不会用于长期数据传输 ------ 其核心价值是 "支撑 1-RTT/0-RTT 的低延迟启动"，而非长期安全防护。
Session Ticket（会话票据）是服务器下发给客户端的 "加密状态包"，而 0-RTT 是基于该票据实现的 "提前加密数据传输"。内容包括：服务器配置信息 ：长期公钥（如 Diffie-Hellman 公钥）、加密算法套件、证书摘要等；会话关联参数 ：QUIC 的连接 ID 生成规则、传输参数（如流控窗口）；安全元数据：票据有效期（通常 7 天，TLS 1.3 限制）、服务器签名（防止篡改）；0-RTT 权限标识：是否允许客户端发送早期数据（max_early_data_size字段）。

5.2.2 版本协商机制：乐观协商，避免冗余延迟。

客户端在首次连接时，直接使用自身支持的最新版本（或与服务器兼容的版本）发起请求，假设客户端选定的版本大概率被服务器支持。
无延迟成功场景：若服务器支持该版本，连接可直接基于该版本建立，无需额外的版本协商 RTT。
仅在不兼容时触发协商：仅当服务器不支持客户端版本时，才返回版本协商包，此时仅增加 1 个 RTT 延迟 ------ 这种 "按需协商" 的模式，确保了绝大多数兼容场景下的低延迟。

5.2.3 流的实现

为避免 TCP 顺序传输机制导致的队头阻塞问题，QUIC 在单一连接内支持多路独立流（Stream），确保单个 UDP 数据包丢失仅影响该数据包中承载数据所属的流；其他流上收到的后续数据可继续重组并交付给应用程序。

QUIC 流是一种轻量级抽象，提供可靠的双向字节流服务：

支持传输任意大小的应用消息，单流最大传输容量可达 2⁶⁴字节；
轻量化特性允许在传输一系列小消息时，为每条消息分配独立流。
流通过流标识（Stream ID）唯一标识，采用静态分配规则：客户端发起的流使用奇数 ID，服务器发起的流使用偶数 ID，以避免标识冲突。

流多路复用功能

流多路复用功能通过将流数据封装到一个或多个流帧（stream frame）中实现，单个 QUIC 数据包可承载来自多个流的流帧。

5.2.4 丢包检测和重传

TCP 的核心痛点之一是 "序号既标识字节顺序，又用于重传确认"，导致重传歧义 ------ 这是 TCP 丢包恢复效率低的根本原因。QUIC 通过 "双标识体系" 彻底解决该问题。
双标识设计：

数据包序号（Packet Number）：单调递增，每个数据包（含重传包）均分配唯一序号，仅用于 "丢包检测、重传确认、RTT 估算"，不关联字节顺序。
流偏移量（Stream Offset）：每个流帧中携带，标识该帧数据在对应流中的字节位置，仅用于 "数据重组与顺序交付"，与数据包传输顺序无关。

RTT 估算逻辑：

接收方在 ACK 帧中显式携带 "数据包接收时间" 与 "ACK 发送时间" 的差值（即接收方处理延迟）。
发送方计算 RTT 时，用 "ACK 接收时间 - 数据包发送时间 - 接收方处理延迟"，得到更精准的 "网络真实 RTT"。

支持多确认块：

支持多确认块，提升乱序与丢包容忍度。
TCP SACK 最多支持 3 个确认块，若存在大量乱序（如序号 1-5、7-10、12-15、17-20 均连续，中间穿插丢失包），TCP 无法完整标识所有连续范围，导致发送方误判丢包，过度重传。
QUIC 支持最多 256 个确认块，可精准标识复杂的乱序场景，发送方仅需重传真正丢失的序号段

5.2.5 流量控制

连接级控制：保证所有流的总数据量不超过接收方缓冲区上限，避免全局溢出；
流级控制：保证单条流不会独占缓冲区，为其他流预留资源，避免流间阻塞。

5.2.6 拥塞控制机制

QUIC 协议本身未固化任何拥塞控制算法，而是通过 "可插拔接口" 实现算法解耦。

5.2.7 连接迁移

QUIC 连接通过 64 位连接标识（Connection ID） 进行唯一标识，该设计使连接能够在客户端 IP 地址或端口发生变化时保持存续。

QUIC 的连接标识（Connection ID）设计是解决 "网络切换导致连接中断" 的核心创新，其核心价值在于 "解除连接与 IP + 端口的强绑定"，从而天然支持 NAT 重绑定与连接迁移，适配移动互联网时代的高频网络切换场景。

目前存在难题：客户端主动切换网络，需客户端主动告知服务器 "新 IP / 端口"，同时需处理网络切换过程中的数据包乱序、丢失等问题。

总结

QUIC解决了传统TCP的一些痛点，性能上有了较大提升，但是在资源消耗和网络安全等方面依然存在诸多问题，需要进步和发展。