--- title: "HTTP TCP NoDelay 配置" date: 2026-01-24 lastmod: 2026-01-24 description: "http.tcp.no_delay 配置项用于控制是否禁用 TCP Nagle 算法以减少延迟。" tags: ["HTTP", "TCP", "NoDelay", "Nagle算法"] summary: "配置项作用 # 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` 配置项用于控制**是否禁用 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 ``` ## 配置建议 ## 生产环境（默认） ```yaml http: tcp: no_delay: true # 默认值 ``` **建议**: 保持默认值 `true`。HTTP 协议通常需要低延迟，这是最优配置。 ## 高吞吐量场景 ```yaml http: tcp: no_delay: false ``` **建议**: 设置为 `false`。当主要处理批量数据传输，且对延迟不敏感时使用。 ## 低延迟要求场景 ```yaml http: tcp: no_delay: true ``` **建议**: 保持 `true`。实时查询、用户交互等需要快速响应的场景。 ## 代码示例 ## easysearch.yml 基础配置 ```yaml http: tcp: no_delay: true # 默认值 ``` ## 高延迟网络配置 ```yaml http: tcp: no_delay: true # 仍然建议启用 # 高延迟网络更需要减少额外延迟 ``` ## 批量数据传输配置 ```yaml http: tcp: no_delay: false # 禁用 NoDelay，提高吞吐量 ``` ## 旧版配置（已弃用） ```yaml # 旧版配置名称（不推荐） http: tcp_no_delay: true # 新版配置名称（推荐） http: tcp: no_delay: true ``` ## 相关配置 | 配置项 | 作用 | 默认值 | |--------|------|--------| | `http.tcp.no_delay` | 是否禁用 Nagle 算法 | true | | `http.tcp.keep_alive` | 是否启用 Keep-Alive | true | | `http.tcp.receive_buffer_size` | 接收缓冲区大小 | -1（系统默认） | | `http.tcp.send_buffer_size` | 发送缓冲区大小 | -1（系统默认） | ## 使用场景 ## 推荐启用 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 的优势更加明显。