3. QUIC连接建立：1-RTT握手、0-RTT握手与参数协商
聊到QUIC的连接建立，我总想起第一次调通QUIC握手时的场景。那时候抓包看了半天，发现它居然能在1个RTT内完成TLS握手和传输参数协商——这在TCP+TLS的世界里简直不敢想。今天我们就来拆解这个核心机制。
3.1 1-RTT握手流程：标准开局
QUIC的1-RTT握手，说白了就是客户端和服务端各发一次包，就能建立起加密连接。这比TCP的三次握手+TLS的两次握手，省了整整一个来回。
核心流程：
- 第一次飞行（Client → Server）： 客户端发送Initial包，里面包含TLS ClientHello、传输参数、以及一个随机生成的源连接ID。
- 第二次飞行（Server → Client）： 服务端回复Initial包，包含TLS ServerHello、证书、传输参数、以及服务端选择的连接ID。
- 握手完成： 双方各自计算握手密钥，后续数据全部加密传输。
嗯，这里要注意一个细节：QUIC的Initial包是明文的，但里面的TLS握手载荷是部分加密的。为什么？因为QUIC需要靠Initial包做连接迁移和版本协商，这部分元数据必须可见。
我在项目中遇到过一个问题：客户端发送的Initial包如果太大，会被中间设备分片。QUIC的解决方案是——每个Initial包必须能独立解码，所以它强制限制了Initial包的最大长度（默认1200字节）。
3.2 0-RTT握手：秒开的代价
0-RTT是QUIC最吸引人的特性之一。如果你之前和某个服务端建立过连接，下次再连时，客户端可以直接发送应用数据——不需要等握手完成。
0-RTT的适用场景：
- HTTP/3的请求复用（比如页面加载时的后续请求）
- 移动端频繁切换网络后的快速重连
- 物联网设备的状态上报
但0-RTT有个重放攻击的风险。你想想看：客户端发送的0-RTT数据是加密的，但服务端还没完成身份验证。如果攻击者截获了这个0-RTT包，然后重放给服务端，服务端会认为这是一个新的连接请求。
我曾经踩过的坑： 在实现0-RTT时，我默认允许了所有HTTP请求在0-RTT中发送。结果发现，像POST、PUT这类幂等性不保证的请求，如果被重放，会导致数据重复写入。后来我强制要求：0-RTT只允许发送GET请求和幂等操作。
QUIC协议本身提供了0-RTT拒绝机制：服务端可以在握手完成后，通过NEW_TOKEN帧告知客户端新的令牌。客户端下次连接时必须携带这个令牌，否则服务端可以拒绝0-RTT。
3.3 传输参数协商：握手中的隐形战场
QUIC的传输参数（Transport Parameters）是在握手过程中协商的。它们不像TCP那样通过选项字段传递，而是作为TLS扩展的一部分，放在加密层里。
我个人习惯把传输参数分为三类：
| 类别 | 参数示例 | 说明 |
|---|---|---|
| 连接标识 | initial_source_connection_id, original_destination_connection_id | 用于连接路由和迁移 |
| 流量控制 | initial_max_data, initial_max_stream_data_bidi_local | 控制发送窗口大小 |
| 功能开关 | disable_active_migration, max_ack_delay | 开启或关闭某些特性 |
举个例子，initial_max_data这个参数，它决定了连接级别的初始流量控制窗口。如果服务端设置了这个值为1MB，那么客户端在握手完成后，最多可以发送1MB的数据，而不需要等待服务端的流控更新。
// 传输参数编码示例（TLV格式）
TransportParameter {
TransportParameterId (i), // 参数ID
TransportParameterValue (bytes) // 参数值
}
// 常见参数ID
0x00: original_destination_connection_id
0x01: initial_source_connection_id
0x02: retry_source_connection_id
0x03: initial_max_data
0x04: initial_max_stream_data_bidi_local
0x05: initial_max_stream_data_bidi_remote
0x06: initial_max_stream_data_uni
0x07: initial_max_streams_bidi
0x08: initial_max_streams_uni
0x09: max_ack_delay
0x0a: ack_delay_exponent
0x0b: disable_active_migration
这里有个容易忽略的点：传输参数的版本兼容性。QUIC协议允许扩展新的传输参数，但旧版本的服务端遇到不认识参数时，必须忽略它，而不是拒绝连接。我见过一些实现，因为不认识某个参数就直接报错，导致握手失败。
3.4 地址验证：防止反射攻击的盾牌
地址验证（Address Validation）是QUIC防止反射攻击和放大攻击的关键机制。说白了，就是服务端要确认：这个客户端确实能收到发往这个地址的包。
QUIC提供了两种验证方式：
- 基于令牌的验证： 服务端在握手过程中，通过Retry包或NEW_TOKEN帧，给客户端一个加密令牌。客户端后续连接时必须携带这个令牌。
- 基于路径的验证： 服务端发送一个PATH_CHALLENGE帧，客户端必须回复PATH_RESPONSE帧，且内容必须匹配。
放大攻击防护： QUIC规定，服务端在未验证客户端地址之前，发送的数据量不能超过客户端发送数据量的3倍。这个限制在Initial包处理阶段尤其重要——防止攻击者伪造源地址，让服务端向受害者发送大量数据。
我记得有一次调试，发现服务端总是拒绝客户端的0-RTT请求。抓包一看，原来是客户端没有携带之前收到的retry_source_connection_id。服务端认为这个地址未经验证，直接拒绝了0-RTT。
地址验证的另一个应用场景是连接迁移。当客户端切换网络（比如从WiFi切到4G），它的源IP地址变了。QUIC会触发路径验证流程：服务端向新地址发送PATH_CHALLENGE，客户端回复后，连接才能继续使用新路径。
3.5 握手流程全景图
下面这张图展示了QUIC握手的完整流程，包括1-RTT和0-RTT两种模式：
从这张图可以清楚看到：1-RTT握手需要两次往返（Initial + Handshake），而0-RTT在第一次飞行时就携带了应用数据。但0-RTT的代价是——服务端在完成握手前，无法确认客户端的身份。
3.6 握手参数协商的实战要点
最后，我总结几个实战中容易踩的坑：
- 传输参数必须一致： 客户端和服务端各自声明自己的参数，但最终生效的是较小值。比如客户端说max_streams=100，服务端说max_streams=50，那实际就是50。
- 连接ID的随机性： 源连接ID必须足够随机，否则容易被预测，导致连接劫持。我见过一个实现直接用递增整数，结果被攻击者猜到了下一个连接ID。
- 0-RTT的令牌有效期： 服务端可以设置令牌的过期时间。如果客户端使用过期令牌，服务端应该优雅降级到1-RTT，而不是直接拒绝连接。
- 地址验证的缓存： 服务端应该缓存已验证的地址信息，避免每次连接都重新验证。但缓存时间不宜过长，否则地址变化后无法及时发现。
我的调试建议： 如果你在调试QUIC握手问题，建议先抓取Initial包和Handshake包。重点关注transport_parameters扩展中的参数值，特别是initial_max_data和max_idle_timeout。这两个参数不匹配，是导致连接异常断开的常见原因。