Skip to main content

附录 A. 与 TCP Cookies (SYN Cookies) 的比较

本附录详细比较 TCP Fast Open (TFO) 和 TCP SYN Cookies 两种机制，帮助理解它们的不同目标和应用场景。

A.1. 概述 (Overview)​

虽然 TFO 和 SYN Cookies 都使用 "Cookie" 概念，但它们服务于完全不同的目的：

TFO (TCP Fast Open):
目标：减少连接延迟，提升性能
机制：预先分配的 Cookie，允许 SYN 数据
状态：有状态（缓存 Cookie）

SYN Cookies:
目标：防御 SYN Flood 攻击，保护服务器
机制：无状态响应，在 ISN 中编码信息
状态：无状态（不保存 SYN-RECEIVED 状态）

A.2. 设计目标比较 (Design Goals Comparison)​

TCP Fast Open (TFO)​

主要目标：

  1. 性能优化：减少 TCP 连接建立的延迟
  2. 向后兼容：与现有 TCP 实现共存
  3. 安全性：不降低 TCP 的安全性

使用场景：

  • 正常网络条件下
  • 客户端和服务器都支持 TFO
  • 对延迟敏感的应用（Web、API）

TCP SYN Cookies​

主要目标：

  1. 防御 SYN Flood：抵御 DoS 攻击
  2. 无状态设计：不消耗服务器资源
  3. 紧急措施：在攻击时自动启用

使用场景：

  • SYN Flood 攻击期间
  • 服务器资源紧张时
  • 作为最后防线的保护机制

A.3. 技术机制对比 (Technical Mechanisms)​

TFO Cookie：

# 预先生成，持久化存储
TFO_Cookie = Encrypt(ServerSecret, ClientIP || Timestamp)

特点：
- 服务器主动生成并发送给客户端
- 客户端缓存 Cookie 供后续连接使用
- Cookie 有明确的过期时间（小时到天）
- 使用强加密算法（如 AES-128）

SYN Cookie：

# 动态编码在 ISN 中，无需存储
SYN_Cookie = Hash(ServerIP, ServerPort, ClientIP, ClientPort, 
                  Timestamp, ServerSecret) + MSS_encoding

特点：
- 在收到 SYN 时即时计算
- 编码在初始序列号 (ISN) 中
- 极短的有效期（分钟级）
- 使用快速哈希函数

状态管理​

TFO 状态管理：

客户端：
  ├─ 缓存每个服务器的 Cookie
  ├─ 跟踪 Cookie 过期时间
  └─ 存储在持久化存储（如磁盘）

服务器：
  ├─ 正常的 TCP 连接状态（TCB）
  ├─ 验证收到的 Cookie
  └─ 可选：跟踪 Cookie 使用统计

SYN Cookies 状态管理：

客户端：
  └─ 无需特殊处理（标准 TCP）

服务器：
  ├─ 不创建 SYN-RECEIVED 状态
  ├─ 在 ACK 中验证返回的序列号
  └─ 验证通过后才创建 ESTABLISHED 状态

连接建立流程​

TFO 连接建立：

客户端                                服务器
   |                                    |
   | SYN + TFO Cookie + Data           |
   |---------------------------------->|
   |                                    | (验证 Cookie，接受数据)
   |                                    | (创建 TCB，进入 SYN-RECEIVED)
   | SYN-ACK (+ 可选数据)              |
   |<----------------------------------|
   |                                    |
   | ACK                                |
   |---------------------------------->|
   |                                    | (进入 ESTABLISHED)
   
优势：节省 1 RTT，数据可在握手期间传输

SYN Cookies 连接建立：

客户端                                服务器
   |                                    |
   | SYN                                |
   |---------------------------------->|
   |                                    | (计算 SYN Cookie)
   |                                    | (不创建 TCB)
   | SYN-ACK (ISN = SYN Cookie)        |
   |<----------------------------------|
   |                                    |
   | ACK (ACK = ISN + 1)               |
   |---------------------------------->|
   |                                    | (验证 SYN Cookie)
   |                                    | (创建 TCB，进入 ESTABLISHED)
   
优势：无状态，不消耗内存，抵御 SYN Flood

A.4. 功能特性对比 (Feature Comparison)​

特性TFOSYN Cookies说明
主要目标性能优化安全防护设计初衷不同
SYN 数据传输✓ 支持✗ 不支持TFO 核心特性
状态类型有状态无状态SYN Cookies 无状态是关键
连接延迟减少 1 RTT标准 3-wayTFO 性能优势
服务器资源正常消耗极低消耗SYN Cookies 节省资源
TCP 选项保留完整保留仅 MSSSYN Cookies 限制
窗口缩放✓ 支持✗ 受限SYN Cookies 丢失选项
SACK 支持✓ 支持✗ 受限同上
时间戳选项✓ 支持✗ 受限同上
ECN 支持✓ 支持✗ 受限同上
Cookie 有效期小时-天分钟TFO Cookie 持久化
客户端缓存✓ 需要✗ 不需要TFO 需要客户端支持
攻击防护中等极强SYN Cookies 专为防御设计
部署复杂度中等低SYN Cookies 更简单

A.5. 性能影响对比 (Performance Impact)​

正常条件下​

TFO：

首次连接：
   延迟：1.5 RTT（与标准 TCP 相同）
   
后续连接：
   延迟：0.5 RTT（节省 1 RTT）
   性能提升：15-40%（HTTP 请求）

SYN Cookies：

所有连接：
   延迟：1.5 RTT（与标准 TCP 相同）
   
副作用：
   - 丢失 TCP 选项（窗口缩放、SACK 等）
   - 可能影响长连接性能
   - MSS 编码限制（只能表示有限的 MSS 值）

攻击条件下​

TFO：

SYN Flood 下：
   问题：
   - 仍需验证 Cookie（消耗 CPU）
   - 可能接受 SYN 数据（消耗内存）
   - 攻击者可能滥用 Cookie 机制
   
   对策：
   - 限制 SYN 数据大小
   - 速率限制
   - 必要时禁用 TFO

SYN Cookies：

SYN Flood 下：
   优势：
   - 完全无状态，不消耗内存
   - 快速计算，CPU 消耗低
   - 自动抵御攻击
   
   权衡：
   - 功能受限（丢失 TCP 选项）
   - 但服务仍然可用

A.6. 安全性对比 (Security Comparison)​

TFO 安全考虑​

防护机制：

✓ Cookie 绑定 IP 地址
✓ Cookie 加密和过期
✓ 限制 SYN 数据大小
✓ 限制 SYN-ACK 响应大小
✓ 速率限制

威胁：
✗ 可能被用于放大攻击
✗ 需要额外的验证开销
✗ Cookie 可能被重放（幂等性要求）

适用场景：

  • 正常网络环境
  • 可信客户端
  • 需要性能优化

SYN Cookies 安全考虑​

防护机制：

✓ 完全无状态
✓ 快速计算
✓ 自动启用（攻击检测）
✓ 不消耗服务器资源

限制：
✗ 功能受限（丢失 TCP 选项）
✗ MSS 编码受限
✗ 不支持 TCP 扩展

适用场景：

  • SYN Flood 攻击期间
  • 服务器资源紧张
  • 作为紧急防护措施

A.7. 兼容性和部署 (Compatibility and Deployment)​

TFO 部署​

要求：

客户端：
  ├─ 需要内核或应用支持
  ├─ 需要 Cookie 缓存机制
  └─ 需要回退到标准 TCP 的能力

服务器：
  ├─ 需要内核或应用支持
  ├─ 需要 Cookie 生成和验证
  └─ 需要配置和管理

网络：
  └─ 中间设备可能剥离 TCP 选项

部署状态：

  • Linux 3.6+ 支持
  • 主流操作系统逐步支持
  • 需要应用程序启用

SYN Cookies 部署​

要求：

客户端：
  └─ 无需任何修改（透明）

服务器：
  ├─ 内核级别支持
  ├─ 可配置启用/禁用
  └─ 通常默认启用

网络：
  └─ 完全透明，无影响

部署状态：

  • 所有主流操作系统支持
  • 广泛部署，默认启用
  • 成熟稳定的技术

A.8. 共存和协作 (Coexistence and Cooperation)​

TFO 和 SYN Cookies 可以共存​

推荐配置：

正常时：
  ├─ TFO：启用（性能优化）
  └─ SYN Cookies：启用但不激活（备用）

轻度攻击：
  ├─ TFO：继续工作（有速率限制）
  └─ SYN Cookies：开始激活（部分连接）

重度攻击：
  ├─ TFO：禁用或严格限制
  └─ SYN Cookies：完全激活（主要防护）

攻击结束：
  ├─ SYN Cookies：逐步退出
  └─ TFO：重新启用

协同优化​

策略：

def handle_syn(packet):
    if is_under_attack():
        # 攻击时，优先使用 SYN Cookies
        if use_syn_cookies:
            return handle_with_syn_cookies(packet)
    
    if packet.has_tfo_option():
        # 正常时，尝试 TFO
        if validate_tfo_cookie(packet):
            return handle_tfo_connection(packet)
        else:
            # TFO 失败，回退到标准 TCP
            return handle_standard_tcp(packet)
    
    # 标准 TCP 处理
    return handle_standard_tcp(packet)

A.9. 使用建议 (Usage Recommendations)​

何时使用 TFO​

推荐场景：

✓ 低延迟要求的应用（Web、API）
✓ 短连接频繁的场景
✓ 请求-响应模式
✓ 幂等操作
✓ 可信网络环境

示例：
- HTTP GET 请求
- DNS 查询
- RPC 调用
- 只读 API

不推荐场景：

✗ 非幂等操作
✗ 高安全要求（敏感操作）
✗ 长连接（收益小）
✗ 不可信环境

示例：
- 金融交易
- 写操作（POST/PUT/DELETE）
- WebSocket 长连接
- 数据库连接

何时依赖 SYN Cookies​

推荐场景：

✓ 所有面向公网的服务器
✓ 高流量网站
✓ 可能遭受 DDoS 攻击的服务
✓ 资源受限的服务器

建议：默认启用，作为最后防线

不推荐场景：

✗ 内部网络（可选）
✗ 完全可信的环境

注意：但即使在这些场景，启用也无害

A.10. 总结 (Summary)​

关键区别​

TFO (TCP Fast Open):
   定位：性能优化工具
   权衡：牺牲一定安全性换取性能
   部署：需要客户端和服务器支持
   效果：显著减少延迟

SYN Cookies:
   定位：安全防护工具
   权衡：牺牲一些功能换取安全
   部署：服务器端透明启用
   效果：有效防御 SYN Flood

互补关系​

TFO 和 SYN Cookies 不是竞争关系，而是互补关系：

TFO：
   "让快的更快" - 在正常情况下优化性能

SYN Cookies：
   "让慢的能用" - 在攻击情况下保持可用

理想部署：
   两者同时启用，根据网络状况动态切换

未来展望​

协议演进：
├─ TFO 可能标准化（从实验性到标准）
├─ SYN Cookies 持续改进（编码更多信息）
├─ 新协议（如 QUIC）原生支持 0-RTT
└─ 更智能的自适应机制

文档结束。感谢阅读 RFC 7413 - TCP Fast Open 技术文档。

有关更多信息，请访问：

Last updated on