当前位置：首页 > ai >正文

【学习笔记】QUIC

ai 2025/6/20 18:09:05

传统的互联网多采用TCP + TLS组合来实现可靠传输与加密保护。然而，这种“分层”处理方式在连接建立时需要多次往返（TCP 三次握手 + TLS 一到两次握手），并且在 HTTP/2 多路复用场景下仍会遭遇 TCP 层的队头阻塞（Head-of-Line Blocking）。

为了突破这些瓶颈，Google 自 2012 年起在 Chrome 和其服务器生态中开始试验一种基于 UDP 的新协议，初名 QUIC，并在 2013 年向 IETF 提交草案，旨在将可靠传输与安全加密紧密集成，从而实现更低的延迟和更高的并发效率。

QUIC（Quick UDP Internet Connections）由谷歌发起的一种传输层协议。它基于UDP实现多路复用、内置加密，将连接建立与安全协商合并为一次握手，降低了网络延迟和拥塞影响。

基于UDP的多路复用
QUIC 在单个 UDP 端口上为每个逻辑流（stream）分配独立的标识与流控制，模拟 TCP 的可靠传输功能，却不会受到同一连接中其他流丢包的影响，消除了 HTTP/2 over TCP 上的队头阻塞问题。
0-RTT 与低延迟握手
借助 QUIC 与 TLS 1.3 集成，客户端在首次握手完成后可缓存“预主密钥”（pre-shared key），在后续连接时无需完整握手即可发送加密数据，支持 0-RTT，显著减少连接延迟。
内置路径迁移支持
QUIC 支持在客户端网络环境变化时（如从 Wi-Fi 切换到蜂窝网络）保持连接状态，传统 TCP 连接则需重新建立。
用户态拥塞控制
与 TCP 在内核态实现拥塞控制不同，QUIC 的拥塞和丢包检测算法均可在用户态快速更新和部署，有利于更灵活的优化和扩展。

QUIC的协议结构包括以下几个部分：

连接标识（Connection ID）： 用于在不同网络路径上路由数据包时仍能识别同一连接。
帧（Frames）与包（Packets）： QUIC 将数据映射为帧，嵌入到 UDP 包中传输；每个包可携带多个流的数据帧，并附带加密的包头和包体。
流控制（Flow Control）与重传机制： 类似于 TCP，但针对每个逻辑流而不是整个连接实施流量和拥塞管理。
加密层： QUIC 不像 TCP + TLS 那样分层，而是将 TLS 握手和记录层集成到协议首部，通过 RFC 9001 规定的方式完成密钥协商和加密。

在连接建立阶段，客户端发送包含 TLS ClientHello 的初始包，服务器在回应中返回 TLS ServerHello 及证书，并同时确认网络参数。完成这一次往返（1-RTT）即可开始加密数据传输。对于后续重连，可利用先前协商的密钥实现 0-RTT 传输。

浏览器与 CDN
Google、Facebook、Cloudflare 等公司率先将 QUIC 部署到公有服务中。截至 2023 年底，QUIC 流量已占 Google 服务器连接的一半以上，并在 CDN 网络中广泛启用 HTTP/3。
移动应用
Android 的 Cronet 库和 iOS 的 URLSession 已支持 QUIC，可为移动端应用提供更低的首包延迟和更可靠的网络连接。
企业服务
Microsoft 在 Windows Server 2022 中支持 SMB over QUIC，为企业文件共享提供了无需 VPN 的安全隧道。其他如 DNS-over-QUIC、XMPP over QUIC 等新兴协议也在标准化或试验阶段。