44、TCP_NODELAY选项：Nagle算法、TCP_NODELAY关闭Nagle、适用场景
聊到TCP性能优化，Nagle算法和TCP_NODELAY这对冤家是绕不开的。我记得刚入行那会儿，写了一个即时通讯的小服务，客户端发消息总是卡顿，查了半天才发现是Nagle算法在背后搞鬼。今天咱们就把这个知识点彻底掰扯清楚。
Nagle算法：它到底在干什么？
Nagle算法是TCP协议栈里一个很经典的小包优化策略。说白了，它的目的就一个：减少网络中微小数据包的数量。
你想想看，一个TCP数据包光是头部就有40字节（20字节IP头 + 20字节TCP头）。如果你每次只发1个字节的数据，那有效载荷才1字节，网络利用率低得可怜。Nagle算法就是来解决这个问题的。
它的核心规则很简单：
- 当有数据要发送时，如果之前发送的小包还没有收到ACK确认，那么新数据不会立即发送，而是先缓存起来
- 等到之前的ACK回来了，或者缓存的数据量凑够了一个MSS（最大报文段长度），再一次性发出去
嗯，这里要注意，Nagle算法只对未确认的小包生效。如果你发的是一个大的数据段，它不会拦着你。
Nagle算法的伪代码逻辑
我习惯用伪代码来理解这种算法逻辑，比看RFC文档直观多了：
if 有数据要发送:
if 发送缓冲区中的数据长度 >= MSS:
立即发送
else:
if 之前发送的小包都已收到ACK:
立即发送
else:
将数据放入缓冲区，等待ACK或凑够MSS这个算法在1984年提出，当时网络带宽普遍很低，确实起到了很好的作用。但在今天的高带宽、低延迟网络环境下，它有时候反而成了性能杀手。
TCP_NODELAY：关掉这个"好心办坏事"的算法
TCP_NODELAY是一个socket选项，它的作用就是禁用Nagle算法。设置之后，每次调用send/write，数据都会立即被推送到网络上，不做任何缓存等待。
我在项目中遇到过这样一个场景：一个实时行情推送系统，服务端需要把每笔交易数据尽快推送给客户端。每笔交易数据也就几十个字节，但要求毫秒级延迟。如果不关Nagle，客户端收行情就会一卡一卡的——因为Nagle在等ACK，而ACK又在等数据，形成了死锁式的延迟。
设置方法很简单，C语言里就几行代码：
#include <sys/socket.h>
#include <netinet/tcp.h>
int sockfd;
int flag = 1;
// 创建socket
sockfd = socket(AF_INET, SOCK_STREAM, 0);
// 设置TCP_NODELAY选项
if (setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag)) < 0) {
perror("setsockopt TCP_NODELAY failed");
close(sockfd);
return -1;
}
// 之后的所有send操作都会立即发送注意看，flag = 1表示启用TCP_NODELAY，也就是禁用Nagle算法。如果设置成0，就是恢复Nagle算法的默认行为。
Nagle算法 vs TCP_NODELAY：核心对比
| 特性 | 启用Nagle（默认） | 禁用Nagle（TCP_NODELAY） |
|---|---|---|
| 发送策略 | 等待ACK或凑够MSS | 立即发送 |
| 网络利用率 | 高（减少小包数量） | 低（可能产生大量小包） |
| 延迟 | 较高（有等待时间） | 低（数据即时推送） |
| 适用场景 | 大文件传输、批量数据 | 实时交互、小包高频场景 |
一个经典的坑：Nagle + Delayed ACK 的"死锁"
这里我要重点提一个我曾经踩过的坑。TCP还有一个机制叫Delayed ACK（延迟确认），它会在收到数据后等一小会儿（通常40-200ms）再发ACK，目的是把多个ACK合并成一个。
当Nagle算法遇上Delayed ACK，就会产生一个经典的性能问题：
- 发送端：Nagle在等ACK，数据发不出去
- 接收端：Delayed ACK在等数据，ACK发不出去
- 结果：双方互相等待，延迟飙升到200ms级别
我曾经在一个远程桌面协议的项目里就遇到了这个问题。鼠标移动的坐标数据只有几个字节，但每次操作都感觉有半秒的延迟。查了三天，最后发现就是Nagle和Delayed ACK在打架。解决方案？对，就是加上TCP_NODELAY。
适用场景总结
什么时候该用TCP_NODELAY？我根据自己的经验列了几个典型场景：
- 实时交互应用：在线游戏、远程桌面、SSH终端。这些场景对延迟极度敏感，每次按键或鼠标移动都需要立即响应。
- 高频交易系统：订单数据通常很小，但延迟就是金钱。我见过有的交易系统甚至把TCP_NODELAY和内核旁路技术一起用。
- 即时通讯的消息推送：聊天消息通常只有几十到几百字节，用户期望"秒达"体验。
- HTTP/2 和 WebSocket：这些协议本身就有多路复用机制，不需要Nagle再来"帮忙"缓存数据。
什么时候保持默认（不设TCP_NODELAY）？
- HTTP/1.1的大文件下载
- FTP文件传输
- 视频流媒体传输
- 任何以吞吐量为优先、延迟不敏感的场景
核心知识体系图
下面这张图把Nagle算法和TCP_NODELAY的关系、决策流程画清楚了。我建议你保存下来，以后调优的时候对照着看：
最后说两句
TCP_NODELAY这个选项，说白了就是一个"延迟换效率"还是"效率换延迟"的取舍。没有绝对的好坏，关键看你的业务场景。我个人习惯是：默认不开，按需开启。只有在明确感知到Nagle算法导致的延迟问题时，才去动这个开关。
另外提醒一点，TCP_NODELAY只影响Nagle算法，不影响TCP的其他机制比如流量控制、拥塞控制。别指望开了它就能解决所有性能问题，该做的优化一样不能少。
公众号:蓝海资料掘金营，微信deep3321