Skip to main content

2. 协议概述 (Protocol Overview)

本章描述 TCP Fast Open 的完整工作流程，包括 Cookie 请求、授予和使用过程。

客户端在首次连接到服务器时，需要先获取 TFO Cookie。

消息流程​

客户端                                服务器
   |                                    |
   |  SYN + TFO Cookie 请求 (空)        |
   |---------------------------------->|
   |                                    |
   |  SYN-ACK + TFO Cookie             |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  应用数据                          |
   |<--------------------------------->|

TCP 选项格式​

Cookie 请求选项：

  • Kind: 34 (TCP Fast Open)
  • Length: 2 (仅选项头，无 Cookie 数据)
  • Cookie: 空（表示请求 Cookie）

关键点​

  1. 透明性：不支持 TFO 的服务器会忽略该选项，连接正常建立
  2. 兼容性：客户端必须准备好回退到标准 TCP 三次握手
  3. Cookie 缓存：客户端应缓存收到的 Cookie 供后续连接使用

服务器收到 Cookie 请求后，生成并返回 Cookie。

服务器使用以下信息生成 Cookie：

  • 客户端 IP 地址
  • 服务器密钥 (Server Secret)
  • 时间戳（用于 Cookie 过期）

加密函数示例：

Cookie = AES-128(ServerSecret, ClientIP || Timestamp)

TCP 选项格式​

Cookie 授予选项：

  • Kind: 34
  • Length: 6 到 18（2 字节头 + 4 到 16 字节 Cookie）
  • Cookie: 服务器生成的加密 Token

服务器行为​

  1. MUST：在 SYN-ACK 中包含 TFO Cookie 选项
  2. SHOULD：使用加密强度足够的算法生成 Cookie
  3. MUST：定期更换服务器密钥以增强安全性

2.3. TCP Fast Open 连接 (Fast Open Connection)​

客户端在后续连接中使用缓存的 Cookie 来实现 Fast Open。

消息流程​

客户端                                服务器
   |                                    |
   |  SYN + TFO Cookie + 数据          |
   |---------------------------------->|
   |                                    | (验证 Cookie)
   |                                    | (处理数据)
   |  SYN-ACK + 数据                   |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  更多数据                          |
   |<--------------------------------->|

关键优势​

延迟节省：

  • 传统 TCP：1 RTT (握手) + 1 RTT (请求-响应) = 2 RTT
  • TCP Fast Open：1 RTT (握手+请求-响应) = 节省 1 RTT

SYN 数据限制​

为防止放大攻击，SYN 包中的数据受到限制：

  1. 最大数据长度：

    • Linux 实现：默认限制为 MSS（最大段大小）
    • 典型值：约 1460 字节（以太网 MTU 1500 - IP/TCP 头）

  2. 数据要求：

    • MUST：数据必须是幂等的（可安全重传）
    • SHOULD：数据应该是完整的请求（如完整的 HTTP 请求）

服务器验证流程​

服务器收到 Fast Open SYN 时：

1. 验证 TFO Cookie
   ├─ 有效 → 接受 SYN 数据，进入 SYN-RECEIVED 状态
   └─ 无效 → 丢弃 SYN 数据，按标准 TCP 握手处理

2. 如果 Cookie 有效
   ├─ 将 SYN 数据传递给应用层
   ├─ 应用可以立即处理并生成响应
   └─ 在 SYN-ACK 中携带响应数据（可选）

3. 完成三次握手
   └─ 收到 ACK 后，连接进入 ESTABLISHED 状态

有效期管理：

  • 典型有效期：数小时到数天
  • 更新策略：客户端可以定期请求新 Cookie
  • 过期处理：Cookie 过期后，服务器拒绝 Fast Open，客户端回退到标准握手

Cookie 可能在以下情况下失效：

  1. 时间过期：超过服务器设定的有效期
  2. 服务器密钥更换：服务器轮换加密密钥
  3. IP 地址变更：客户端 IP 地址改变（移动网络）
  4. 服务器策略：服务器主动撤销 Cookie（安全原因）

客户端缓存策略​

SHOULD 实现的功能：

  • 为每个服务器 IP:Port 缓存独立的 Cookie
  • 实现 Cookie 过期管理
  • Cookie 失效时自动重新请求
  • 支持多个服务器的 Cookie 管理

回退机制​

当 Fast Open 失败时，客户端必须能够回退：

尝试 Fast Open
   ├─ 成功 → 继续使用
   ├─ Cookie 被拒绝 → 完成标准握手，请求新 Cookie
   └─ 超时 → 重传 SYN（可能不带数据）

2.5. 协议交互总结 (Protocol Interaction Summary)​

完整生命周期​

阶段 1：初始化
   客户端 ──SYN(Cookie 请求)──> 服务器
   客户端 <──SYN-ACK(Cookie)─── 服务器
   客户端 ──ACK──────────────> 服务器
   [客户端缓存 Cookie]

阶段 2：Fast Open（多次）
   客户端 ──SYN(Cookie+Data)──> 服务器
   客户端 <──SYN-ACK(Data)───── 服务器
   客户端 ──ACK──────────────> 服务器
   [节省 1 RTT]

阶段 3：Cookie 更新（当需要时）
   重复阶段 1

性能指标​

连接类型数据传输开始时间相对性能
标准 TCP1.5 RTT基准
TFO (首次)1.5 RTT与标准 TCP 相同
TFO (后续)0.5 RTT提升 66%

兼容性矩阵​

客户端服务器结果
支持 TFO支持 TFOFast Open 成功
支持 TFO不支持 TFO回退到标准 TCP
不支持 TFO支持 TFO标准 TCP
不支持 TFO不支持 TFO标准 TCP

下一章节： 3. 协议详细说明 (Protocol Details) 将深入介绍 TFO 选项格式、状态机和实现细节。

Last updated on