什么是QUIC协议

QUIC协议是什么

QUIC（Quick UDP Internet Connections）是 Google 提出的基于 UDP 的传输层协议，后来被 IETF 标准化为 RFC 9000。它旨在取代传统的 TCP+TLS+HTTP/2 组合，通过将 连接建立、加密、流控、多路复用 全部移入应用层，使连接更快、更可靠，特别适用于弱网和移动网络的场景。

QUIC 的核心优势包括：

• 0-RTT/1-RTT 建连：首次连接只需 1 个 RTT，重连可做到 0 RTT，大幅提升建连速度。
• 多路复用无队头阻塞：数据分成多个独立 stream，不会因一个包丢失导致整体阻塞。
• 内置加密（TLS 1.3）：无需额外的 TLS 握手，天然具备安全性。
• 更强的弱网表现：更快的丢包恢复、自适应拥塞控制、连接迁移能力强。
• 支持连接迁移：切换 Wi-Fi → 4G → 5G 时，无需重新建连（根据 Connection ID 保持会话）。

QUIC协议的工作原理

建立连接（握手）

QUIC实现了快速握手，并把握手过程分为两种情况，分别是1-RTT和0-RTT。

1-RTT

第一次握手：

• 客户端主动向服务器发送Inchoate CHLO报文
• 服务器会向客户端发送REJ报文。REJ报文包含了服务器的配置信息，如长期的Diffie-Hellman值，服务器配置的签名，source-address-token(stk, 用于验证的加密块，包含有服务器看到的客户端的IP地址和服务器当前的时间戳，之后客户端会将该stk发回)等，为了进行身份证明还会使用私钥进行签名，同时也可以防篡改；
• 在收到服务器的配置信息后，客户端会通过证书链机制验签，并实现对服务器的身份认证。

第二次握手：

• 客户端在通过对服务器的验证之后，客户端会生成一个Diffie-Hellman值。此时客户端有了自身和对方的Diffie-Hellman值，就可以计算出初始密钥（initial key, ik）；
• 客户端将包含有DH公开之的明文Complete CHLO发送至服务器；
• 客户端使用ik对请求数据加密，发送至服务器；
• 服务器收到Complete CHLO之后就可以获得客户端的Diffie-Hellman的值，就可以计算出初始密钥。
• 服务器立即向客户端发送SHLO报文（ik加密的）。SHLO报文含有一个服务器临时Diffie-Hellman值，可以用于计算前向安全的密钥（会话密钥）；
• 服务器收到加密的请求数据，使用初始密钥进行解密；
• 服务器使用会话密钥对响应数据进行加密，发回给客户端。
• 客户端在收到SHLO之后使用初始密钥解密得到服务器的临时DH公开值，根据该临时值计算出会话密钥；
• 客户端收到加密的响应数据后，使用会话密钥进行解密。

整个握手过程会在2个RTT内完成。

0-RTT

客户端在重连同一个服务器时，会使用已经缓存的服务器相关配置信息（stk，DH公开值等信息），并直接向服务器发送Complete CHLO报文，并使用ik对请求报文进行加密。但是服务器方面会标识相应的stk等信息已经过期，这时服务器会发送REJ信息，客户端需要重新与服务器进行连接。

如果没有过期的话，就可以直接建立连接，省下了重新建立连接的开销。

前向安全性

所谓前向安全性就是指，在最后一次握手时，会生成一个会话密钥sk。这样即使服务器的长期DH值被破获，且生成了初始密钥ik，也无法对会话中的数据进行解密。

多路复用功能

QUIC 基于 UDP 实现了自身的多路复用功能，它允许在同一个 QUIC 连接内复用多个独立的流（Stream）。每个流都有独立的流控、排序和重传逻辑，因此某个流的数据丢失不会阻塞其他流，从根本上解决了 TCP 中的队头阻塞问题。

QUIC 的多路复用特点：

• 独立流（Stream）：同一条 QUIC 连接可包含多个并行流，每条流由唯一的 Stream ID 标识。
• 客户端发起为奇数流 ID，服务器发起为偶数流 ID：避免冲突，简化了流的创建逻辑。
• 自动创建与关闭：在未使用过的流上首次发送数据会自动创建该流；通过 FIN 标志即可关闭，不影响整个连接。
• 按需可靠性：流内部可靠传输，但被取消的流不会强制重传所有数据。
• 帧级复用：一个 QUIC 包可承载来自多个流的帧（Frame），实现真正的包级复用。

通过这种轻量、高效的多路复用设计，QUIC 能同时处理文本消息、文件传输、心跳与状态同步等多种 IM 数据流，使弱网环境下的延迟和拥塞表现远优于基于 TCP 的方案。

报文丢失重传

TCP 依靠序列号保证数据顺序，但原包与重传包使用相同序列号，会产生“重传模糊”，接收端无法判断 ACK 属于哪次传输，通常只能依赖较长的超时机制检测丢包。QUIC 通过为每个数据包分配单调递增的包编号解决了该问题：即使是重传数据，也会使用新的编号，使 ACK 对应关系非常明确。同时，流偏移（Stream Offset）用于记录数据顺序，使排序与可靠性从包编号中解耦。QUIC 的 ACK 可携带延迟信息，并支持多个 ACK 区间，比 TCP SACK 覆盖范围更广，有助于更快完成丢包检测与重传。

流量控制(Flow Control)

QUIC 的多路复用需要避免单个流占满接收缓冲，因此引入 连接级与流级双层流量控制。流级流控限制发送方在某条 stream 上能发送的数据量，避免慢速 stream 占用过多资源；连接级流控则限制所有流的总量，保证不同流之间的公平性。QUIC 采用类似 HTTP/2 的信用机制，接收端通告可接收的最大字节偏移量，并在应用层消费数据后通过窗口更新帧扩大窗口，允许发送端继续传输。这种机制确保弱网或多流情况下依然保持良好的传输效率。

拥塞控制（Congestion Control）

QUIC支持的拥塞控制算法有：
Reno（TCP用的）、基于Pacing的拥塞控制算法（PBCCA）、TCP CUBIC等。

连接迁移

QUIC连接使用随机生成的64bit的cid唯一确定。cid允许客户机在网络之间漫游，而不受网络或传输层参数变化的影响。

cid使得客户端能够独立于网络地址转换（network address translation, NAT）之外。cid 在路由中起着重要作用，特别是用于连接标识的目的。此外，使用 cids 可以通过探测连接的新路径实现多路径。

在连接迁移期间，端点假设对等方愿意在其当前地址接受数据包。因此，端点可以迁移到新的 IP 地址，而无需首先验证对等方的 IP 地址。新的路由路径可能不支持端点的当前发送速率。在这种情况下，端点需要重新构建它的拥塞控制器。另一方面，从一个新的对等地址接收非探测包 ，确认对等地址已迁移到新的 IP 地址。

QUIC协议在IM中的应用

在 IM 系统中，长连接必须面对大量移动端场景：

• NAT 不稳定
• 移动网络频繁切换（Wi-Fi ↔ 5G）
• 高延迟、丢包、弱网环境
• 全球用户跨区域访问

QUIC 可以在这些场景中显著提升连接稳定性与消息实时性。

1，提升长连接建连速度（0-RTT 重连）

• TCP 可能需要重新握手（3 次握手 + TLS 握手）
• QUIC 可在 0-RTT 内恢复连接

这使 IM 系统的“消息恢复—状态同步”速度明显加快。

2，更稳定的长连接保活

TCP 在移动网络中常被 NAT、运营商设备清理，导致连接被动断开。而QUIC 的优势在于：

• UDP “可穿透性”较好，更不容易被 NAT 清理
• Connection ID 机制允许 NAT 映射变化后保持连接
• 若连接真的断开，QUIC 重连速度也远高于 TCP

这在弱网国家（如东南亚、印度、中东）尤为明显。

3，网络切换更平滑（Connection Migration）

传统 TCP：

• Wi-Fi → 5G 网络变化后 IP 变化
• 五元组不一致，连接立即失效，需要重连

QUIC：对于 IM 场景非常有价值 —— 走路、打车、电梯都不会导致消息发送失败。

• 使用 Connection ID
• 切换网络时无需重新握手
• 长连接保持不变，延迟几乎可忽。

4，多路复用降低消息延迟

IM 中存在多类消息：

• 文本消息
• 文件传输
• 频道消息
• 送达回执
• 在线状态同步

在 TCP 下，这些都走一条流，任何 packet 丢失都会阻塞后续传输。

QUIC 的多路复用解决了这一点： 文件传输丢包不会阻塞文本消息和在线状态包； 回执、心跳可以优先发送，这对实时消息系统极为关键。

5，更适合移动端的拥塞控制

QUIC 支持 可插拔拥塞控制算法：IM 系统可以选择更适合弱网的算法，例如 BBR（对高丢包网络表现好）。