Nagle 算法与 TCP_NODELAY、TCP_CORK 详解

概述
一、背景：小包传输的效率问题
[二、Nagle 算法机制](#二、Nagle 算法机制)
三、算法目的与适用场景
[四、Nagle 易造成性能问题的场景](#四、Nagle 易造成性能问题的场景)
[五、与延迟确认（Delayed ACK）的交互](#五、与延迟确认（Delayed ACK）的交互)
[六、TCP_NODELAY 与 TCP_CORK 对比](#六、TCP_NODELAY 与 TCP_CORK 对比)
七、实践建议与示例代码
八、平台说明与排障命令
九、策略选择速查（决策表）
[附录 A：MSS 与 MTU 的关系](#附录 A：MSS 与 MTU 的关系)
[附录 B：术语与抓包速查](#附录 B：术语与抓包速查)
免责声明

概述

Nagle 算法 工作在 TCP 发送端 ：在「已有未确认数据」时，把应用的小写入先放进缓冲区，减少链路上的微型报文 。
TCP_NODELAY 用于关闭 Nagle，换取更低延迟 、更多小包。
TCP_CORK （主要 Linux ）则是另一类机制：主动堵包 ，把多次 write/send 合成更少 TCP 段，偏向吞吐与段合并。

重要边界 ：Nagle 与 TCP_NODELAY 只影响本端「往外发」的路径 ；对端是否 Delayed ACK、是否关 Nagle，需分别看连接两端配置。

下文用表图 + 流程图 + 时序示意串起原理与选型。

一、背景：小包传输的效率问题

在 TCP/IP 中，每个报文都带有协议头：IPv4 典型 IP 头 20 字节 、TCP 头至少 20 字节 （不含选项）。若应用层只发 1 字节 有效载荷，链路上仍要承载约 40+ 字节 的头，带宽利用率极低；大量小包还会加重路由器/主机处理负担，增加拥塞风险。

1.1 头部开销示意（IPv4、无 TCP 选项、示意值）

复制代码

  ┌─────────────────────────────────────────────┐
  │ IP 头 ≈20B  │ TCP 头 ≈20B  │ 载荷 1B      │
  └─────────────────────────────────────────────┘
        有效载荷占比 ≈ 1 / 41 ≈ 2.4%（量级示意）

1.2 效率对比表（示意，非精确测量）

应用每次写入	典型 IP+TCP 头（示意）	链路上「头+载荷」量级	头占比（粗算）
1 字节	≈40 B	≈41 B	~98%
100 字节	≈40 B	≈140 B	~29%
1460 字节（≈常见 MSS）	≈40 B	≈1500 B	~3%

Nagle 算法正是为缓解「应用频繁写极小数据」带来的小包泛滥问题而设计的发送端策略。

1.3 Nagle 在协议栈中的位置（示意）

复制代码

  ┌──────────── 本机协议栈（发送方向）────────────┐
  │  应用 write/send                             │
  │       ↓                                      │
  │  套接字缓冲 ──► TCP（Nagle / NODELAY / CORK）  │◄── 本文重点
  │       ↓                                      │
  │  IP → 网卡                                   │
  └──────────────────────────────────────────────┘
        对端的 Delayed ACK、窗口、SACK 等 ← 在「对机」接收路径上讨论

二、Nagle 算法机制

2.1 逻辑概要（伪代码）

text 复制代码

若有新数据要发送：
  若 发送窗口允许 且 已累积数据 ≥ MSS：
        立即发送一个满 MSS 的段
  否则：
        若 线路上仍有「未确认」的数据（等待 ACK）：
              把新数据放入发送缓冲区，暂不发送（等待 ACK 或凑包）
        否则：
              立即发送（例如连接上的「第一包」等情形）

（具体实现以各操作系统内核为准，边界条件与定时器略有差异。）

2.2 决策流程图（Mermaid）

是
否
否
是
是
否
应用产生新数据
窗口允许且已攒数据 ≥ MSS?
立即发送满 MSS 段
发送管线中仍有未确认数据?
立即发送
数据进发送缓冲

等待 ACK / 凑满 MSS / 超时等
满足立即发送条件?
发送

2.3 常见「允许立即发出」的触发条件（归纳）

条件	说明
已攒够 MSS	凑满一个最大报文段，减少分段次数
首包 / 无未确认数据	避免冷启动一直不发
带 FIN 等需尽快语义	关闭连接等
套接字设置 TCP_NODELAY	关闭 Nagle，有数据倾向立即发
TCP_CORK 与内核实现	CORK 关闭或达 MSS/超时等条件时才会真正推出（见第六节）

若长期不满足立即发送条件，数据可能在发送缓冲区中短暂等待 （量级上常见讨论为约 200ms 级超时或等到 ACK，以实现为准）。

2.4 发送侧数据流（ASCII）

复制代码

  应用 write/send
        │
        ▼
  ┌─────────────┐     ┌──────────────────┐
  │ 套接字发送缓冲 │ ──► │ TCP 层（Nagle 等） │
  └─────────────┘     └────────┬─────────┘
                               │ 组段
                               ▼
                        IP 层 → 链路层

三、算法目的与适用场景

维度	说明
目的	减少链路上的微小报文数量，降低头开销占比、提高有效吞吐，并一定程度减轻拥塞压力
更适合	数据量不大、对毫秒级延迟不敏感的交互（如某些批量上报、非实时日志等）
不太适合	强实时、小包极高频、交互往返极短的场景（见第四节）

四、Nagle 易造成性能问题的场景

以下场景往往要求低延迟、小包高频 ，Nagle 的「攒包」会放大体感延迟。

类型	示例	现象
实时交互	网游（FPS/MOBA 等）、云游戏、远程桌面	操作到画面不同步、「不跟手」
请求-响应小包	Redis/Memcached、部分自建 TCP RPC	RTT 变长、QPS 上不去
终端类	SSH、Telnet、串口	按键回显迟钝
即时消息 / 信令	IM、音视频 SDP/ICE、IoT 心跳	消息「慢半拍」
实时音视频	语视频、直播控制信令	卡顿、不同步

应对思路 ：在客户端或服务端（或两端）对相应套接字设置 TCP_NODELAY，关闭 Nagle（需结合业务与对端行为评估）。

五、与延迟确认（Delayed ACK）的交互

经典组合问题 ：一端 Nagle （等有 ACK 或凑包再发），另一端 Delayed ACK（推迟几十到约 200ms 再 ACK，等更多数据）。

发送端：可能等 ACK 才继续发积压小包
接收端：可能等更多数据才发 ACK

二者互相等待，可出现数百毫秒级额外延迟，在 HTTP/1.1、某些 RPC 场景的历史讨论中较常见。

5.1 互等过程示意（逻辑时序）

复制代码

  时间 →

  发送端(Nagle ON):  已发小包 P1 ──等待 ACK──┐
                                              │ 双方「等对方先动」
  接收端(Delayed ACK): 收到 P1 ──想再等更多数据再 ACK──┘

  结果：下一小包 P2 可能被 Nagle 按住直到 ACK 或超时；
        ACK 又被 Delayed ACK 推迟 → 整体 RTT 膨胀

5.2 缓解手段（对照表）

手段	说明
TCP_NODELAY	发送端不再按 Nagle 憋小包，减轻「等 ACK 才发」一侧压力
合并应用层写入	一次写更大块，让对端更愿意早 ACK
协议/栈参数	对端是否 Delayed ACK、定时器与实现相关，需结合系统文档
换模型	HTTP/2、多路复用、管道化等从架构上减少「小包 ping-pong」

5.3 收发两端角色对照

机制	作用端	典型手段
Nagle	发送端 TCP	内核默认策略；`TCP_NODELAY` 关闭
Delayed ACK	接收端 TCP	内核策略；与 Nagle 组合易「互等」
TCP_CORK	发送端（Linux）	`setsockopt(TCP_CORK)` / `MSG_MORE`

5.4 Mermaid：Nagle + Delayed ACK 互等（逻辑）

接收端(Delayed ACK) 发送端(Nagle 开) 接收端(Delayed ACK) 发送端(Nagle 开) 待发 P2：管线有未确认 → 可能等待 ACK 收到 P1：想等更多数据再 ACK 易出现百毫秒级额外 RTT（示意）小包 P1 P2 延迟发出 / ACK 延迟返回

六、TCP_NODELAY 与 TCP_CORK 对比

两者都影响「是否推迟发送 」，但语义不在同一维度：NODELAY 关 Nagle；CORK 是额外的「堵包」开关（Linux）。

维度	TCP_NODELAY	TCP_CORK（Linux）
作用	关闭 Nagle	主动堵包：尽量攒大再发
延迟发送	倾向不延迟（尽快发）	允许并强化延迟，直到满足条件
与 ACK	关闭 Nagle 后不再受 Nagle 那条「等 ACK」逻辑约束	不直接等价于 Nagle，是另一层「塞住」
典型用途	游戏、SSH、RPC、低延迟交互	HTTP 响应头+体一次写出、批量写减少段数
形象理解	「别替我合并，我要快」	「先别发，装满一车再走」

与 Nagle 的关系（简述）

TCP_NODELAY=1 ：跳过 Nagle，小包也更易立即发出；代价是头占比高、包数多。
TCP_CORK=1 ：内核倾向把用户数据攒在发送侧 ，直到达到 MSS、关闭 CORK、或超时等条件再发；常用于减少碎片段。

注意：同时乱用 NODELAY 与 CORK 会语义冲突------NODELAY 会破坏 CORK「攒大包」的意图；一般按业务二选一为主，或分阶段开关（由应用明确控制）。

Linux 上写路径还可配合 send(..., MSG_MORE) （提示「后面还有，先别急着发」），与 CORK 思想相近，具体以 send(2) 手册为准。

Nagle / NODELAY / CORK 关系示意图

复制代码

                    ┌─────────────────────────────┐
                    │     应用多次 write/send      │
                    └──────────────┬──────────────┘
                                   │
           TCP_NODELAY=1           │           TCP_CORK=1（Linux）
           （关闭 Nagle）          │           （额外堵包）
                   │              │                  │
                   ▼              ▼                  ▼
            尽快推出小段    Nagle 可能憋包      强制攒段至条件满足

七、实践建议与示例代码

7.1 何时考虑 TCP_NODELAY

交互延迟敏感、小包极多、或已观察到与 Delayed ACK 的「互等」延迟。

7.2 何时考虑 TCP_CORK / MSG_MORE

单次逻辑上连续的多段写（如响应头+体），希望少几个 TCP 段再发出。

7.3 setsockopt 示例（C，Linux）

c 复制代码

#include <netinet/tcp.h>
#include <sys/socket.h>

int enable = 1;
/* 关闭 Nagle */
if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &enable, sizeof(enable)) < 0) {
    perror("TCP_NODELAY");
}

/* Linux：开启 CORK（需与业务匹配，且勿与低延迟目标混用） */
#if defined(__linux__)
int cork = 1;
if (setsockopt(fd, IPPROTO_TCP, TCP_CORK, &cork, sizeof(cork)) < 0) {
    perror("TCP_CORK");
}
/* 发送完毕后记得 cork = 0 关闭 CORK，避免长期堵死 */
#endif

7.4 其他语言设置 TCP_NODELAY（示例）

环境	写法示例
Go	`conn.(*net.TCPConn).SetNoDelay(true)`
Java	`socket.setTcpNoDelay(true)`
Node.js	`socket.setNoDelay(true)`（`net.Socket`）
Python	`sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)`

许多高性能中间件、游戏服务器会在特定连接上默认关闭 Nagle；是否关闭应结合协议设计、客户端行为、吞吐与延迟指标测量后决定。

八、平台说明与排障命令

平台	TCP_NODELAY	TCP_CORK
Linux	支持	支持
Windows / macOS / BSD*	一般支持	通常无 CORK ；用合并写、`TCP_NOPUSH`（BSD 系）等替代思路需查各平台文档

Linux 观察连接信息（示例）：

bash 复制代码

ss -ti sport = :6379   # 示例：看 Redis 端口相关 TCP 信息（输出因内核版本而异）

具体字段是否展示 Nagle/RTT 等，以本机 ss 与内核为准；性能问题仍以抓包（tcpdump）+ 延迟测量为准。

8.1 全链路排查层次（表）

层次	关注点	常用手段
应用	是否频繁小 `write`、能否合并缓冲	日志、profiler
套接字	`TCP_NODELAY` / `TCP_CORK`	`getsockopt`、代码审查
内核 TCP	Delayed ACK、拥塞、重传	`ss -ti`、`nstat`、抓包
网络	RTT、丢包、中间设备	`ping`、`mtr`、tcpdump

九、策略选择速查（决策表）

业务目标	优先策略	避免
最低交互延迟、小包多	TCP_NODELAY=1	与 TCP_CORK 同时长期开启
单次响应多段 write、希望少几个 TCP 段	TCP_CORK 或 MSG_MORE（Linux）	在实时链路上长期 CORK
默认 Web/批处理、无特殊延迟问题	使用系统默认（多为 Nagle 开启）	盲目全局关 Nagle
已出现「偶发几百 ms」且为小请求	查 Nagle + Delayed ACK	只改一端不验证对端

选型流程图（Mermaid）

是
否
是
否
新连接/新模块
延迟敏感且小包高频?
TCP_NODELAY 开

并测 RTT/吞吐
单次响应多次 write

想减少段数?
Linux: CORK 或 MSG_MORE

写完关闭 CORK
保持默认

按需再调

附录 A：MSS 与 MTU 的关系

概念	含义	关系（典型）
MTU	链路层单帧最大载荷（如以太网常 1500）	决定 IP 包不宜超过的大小
MSS	TCP 单段数据最大长度（不含 IP/TCP 头）	常约为 MTU − IP 头 − TCP 头（无选项时约 1460 @ MTU=1500）

Nagle 判断里的 MSS 即「凑满一段再发」的阈值之一；实际 MSS 可能由 SYN 选项、路径 MTU 发现等协商决定。

A.1 以太网典型封装（示意）

复制代码

[ 以太网头 14B ][ IP 头 20B ][ TCP 头 20B ][ TCP 载荷 ≤MSS ]
                      ◄──────── MTU 常 1500（payload 部分）───────►

附录 B：术语与抓包速查

术语	含义
MSS	TCP 单段数据上限（不含 IP/TCP 头），与 MTU 协商相关
Nagle	发送端「有未确认数据时憋小包」的算法
TCP_NODELAY	关闭 Nagle，倾向低延迟、更多小包
TCP_CORK	Linux 发送端「堵包」至 MSS/关 CORK/超时等再发
Delayed ACK	接收端推迟发 ACK，常与 Nagle 组合讨论
tinygram	极小的 TCP 载荷段，头占比高

抓包（需权限，示例）：

bash 复制代码

# 观察某主机与 443 端口的交互间隔（示例）
sudo tcpdump -i any -nn host <对端IP> and port 443 -tt

# 保存为 pcap 用 Wireshark 看「TCP segment len」与 ACK 间隔
sudo tcpdump -i any -w /tmp/capture.pcap tcp port 443

免责声明

本文根据公开技术资料与讨论整理，用于学习与排障；Nagle、Delayed ACK、超时时间等细节因操作系统与内核版本而异，实现与调优请以官方文档及实测为准。

主题：TCP 发送端策略 --- Nagle、TCP_NODELAY、TCP_CORK 与延迟确认。

Nagle 算法与 TCP_NODELAY、TCP_CORK 详解