HTTP TCP NoDelay 配置

配置项作用 #

http.tcp.no_delay 配置项用于控制是否禁用 TCP Nagle 算法。

Nagle 算法是一种通过缓冲小数据包来提高网络利用率的算法。禁用它（设置 no_delay = true）可以使数据立即发送，减少网络延迟。

配置项属性 #

• 配置路径: http.tcp.no_delay
• 数据类型: Boolean（布尔值）
• 默认值: true
• 是否可选: 是
• 作用域: NodeScope（节点级别）
• 旧版配置: http.tcp_no_delay（已弃用）

配置项详解 #

工作机制 #

Nagle 算法对比

启用 Nagle 算法 (no_delay = false):

小数据包:
┌─────┐ ┌─────┐ ┌─────┐
│ 50B │ │ 50B │ │ 50B │
└─────┘ └─────┘ └─────┘
   ↓       ↓       ↓
   └───────┴───────┘
           ↓
    缓冲区累积数据
           ↓
    等待达到一定大小
    或收到 ACK
           ↓
    ┌──────────────────┐
    │     150B 数据包    │ 发送
    └──────────────────┘

优点: 减少网络包数量，提高利用率
缺点: 增加延迟（最多 40-200ms）


禁用 Nagle 算法 (no_delay = true，默认):

小数据包:
┌─────┐ ┌─────┐ ┌─────┐
│ 50B │ │ 50B │ │ 50B │
└─────┘ └─────┘ └─────┘
   ↓       ↓       ↓
 立即   立即   立即
 发送   发送   发送

优点: 低延迟，立即响应
缺点: 更多网络包，可能降低利用率

HTTP 请求的场景 #

HTTP 请求/响应模型

典型的 HTTP 交互:

客户端                              服务器
  │                                   │
  │ ──── HTTP 请求 (小数据包) ─────→   │
  │                                   │
  │ ←─── HTTP 响应 (可能大数据包) ──── │
  │                                   │

对于 HTTP 协议:
- 请求通常很小（几百字节）
- 需要快速响应
- 低延迟优先于带宽利用率

因此默认禁用 Nagle 算法 (no_delay = true)

延迟对比 #

延迟分析

no_delay = false (启用 Nagle):

请求发送:
0ms ─────→ 40ms ──────→ 80ms
│          │            │
发送请求   等待 ACK    发送请求

总延迟: 40-200ms


no_delay = true (禁用 Nagle，默认):

请求发送:
0ms ─────→ 5ms
│          │
发送请求   网络延迟

总延迟: 5-20ms

配置建议 #

生产环境（默认） #

http:
  tcp:
    no_delay: true  # 默认值

建议: 保持默认值 true。HTTP 协议通常需要低延迟，这是最优配置。

高吞吐量场景 #

http:
  tcp:
    no_delay: false

建议: 设置为 false。当主要处理批量数据传输，且对延迟不敏感时使用。

低延迟要求场景 #

http:
  tcp:
    no_delay: true

建议: 保持 true。实时查询、用户交互等需要快速响应的场景。

代码示例 #

easysearch.yml 基础配置 #

http:
  tcp:
    no_delay: true  # 默认值

高延迟网络配置 #

http:
  tcp:
    no_delay: true  # 仍然建议启用
    # 高延迟网络更需要减少额外延迟

批量数据传输配置 #

http:
  tcp:
    no_delay: false  # 禁用 NoDelay，提高吞吐量

旧版配置（已弃用） #

# 旧版配置名称（不推荐）
http:
  tcp_no_delay: true

# 新版配置名称（推荐）
http:
  tcp:
    no_delay: true

相关配置 #

使用场景 #

推荐启用 no_delay 的场景 #

• REST API: HTTP 请求/响应模式需要低延迟
• 实时查询: 用户交互式搜索
• 小数据包: 请求和响应都较小
• 频繁交互: 大量短请求
• 在线服务: 需要快速响应用户

推荐禁用 no_delay 的场景 #

• 批量数据导入: 大数据量传输
• 日志聚合: 收集大量日志数据
• 备份恢复: 大文件传输
• 带宽受限: 网络带宽有限
• 内部集群: 节点间大量数据同步

性能影响分析 #

延迟 vs 吞吐量权衡

场景 1: 搜索 API（小数据包）

no_delay = true:
- 延迟: 5-20ms ✅
- 吞吐量: 中等
- 网络包数: 较多

no_delay = false:
- 延迟: 40-200ms ❌
- 吞吐量: 中等
- 网络包数: 较少

推荐: no_delay = true


场景 2: 批量索引（大数据包）

no_delay = true:
- 延迟: 10-50ms
- 吞吐量: 中等
- 网络包数: 很多

no_delay = false:
- 延迟: 30-100ms
- 吞吐量: 高 ✅
- 网络包数: 较少

推荐: no_delay = false

网络效率分析 #

网络包效率

假设 10 个 50 字节的请求，RTT = 10ms


no_delay = true:

发送: 10 个独立包
时间: 10 × 10ms = 100ms（串行）
或 约 10-20ms（流水线）
数据: 500 bytes + 10 × 头部开销


no_delay = false:

发送: 1-2 个合并包
时间: 10-20ms
数据: 500 bytes + 1-2 × 头部开销

效率提升:
- 减少 IP/UDP 头部开销
- 减少网络中断次数
- 提高 MTU 利用率

Nagle 算法与 Delayed ACK #

常见问题: Nagle 与 Delayed ACK 的交互

某些系统的 TCP 实现同时启用:
1. Nagle 算法（发送端缓冲小包）
2. Delayed ACK（接收端延迟确认）

可能导致:
发送端等待 ACK
接收端等待更多数据
结果: 40-200ms 的额外延迟

解决方案:
禁用 Nagle 算法 (no_delay = true)
可以避免这个问题

配置迁移 #

从旧版配置迁移

旧版配置（已弃用）:
http:
  tcp_no_delay: true

新版配置（推荐）:
http:
  tcp:
    no_delay: true

注意事项:
- 旧配置名称仍然有效
- 系统会自动处理迁移
- 建议更新到新配置名称
- 旧配置可能在未来版本移除

注意事项 #

1. 默认启用: 默认值为 true，适用于大多数 HTTP 场景。

2. HTTP 协议特性: HTTP 请求/响应模式通常需要低延迟。

3. 与吞吐量的权衡: 禁用 Nagle 会降低网络利用率。

4. 动态更新: 此配置不支持动态更新，修改后需要重启节点。

5. 所有平台支持: 此配置在所有平台上都有效。

6. 监控建议: 监控请求延迟和吞吐量，评估配置效果。

7. 客户端配置: 客户端也应该配置相应的 TCP_NODELAY 设置。

8. 旧版兼容: 旧版配置 http.tcp_no_delay 仍然有效但已弃用。

9. 批量操作: 对于批量索引等大吞吐量操作，可以考虑临时禁用。

10. 网络类型: 在高延迟网络中，禁用 Nagle 的优势更加明显。