网络性能调优：TCP缓冲区调优、Nagle算法、延迟确认、零拷贝技术

说实话，网络编程做到一定阶段，你会发现瓶颈往往不在业务逻辑上，而在内核的网络栈里。我早年调一个高并发网关，CPU才用了30%，吞吐量就是上不去。查了三天，最后发现是TCP缓冲区太小，加上Nagle算法在捣乱。嗯，今天咱们就把这几个性能杀手挨个说清楚。

一、TCP缓冲区调优

TCP缓冲区，说白了就是内核为每个socket分配的一块内存。发送缓冲区存着你还没发出去的数据，接收缓冲区存着对端发来但你还没取走的数据。这两个缓冲区的大小，直接影响吞吐量。

BDP = 带宽 × RTT。举个例子，千兆网络（125MB/s）RTT是20ms，BDP就是125MB/s × 0.02s = 2.5MB。也就是说，缓冲区至少2.5MB才能跑满带宽。

我在项目中遇到过，默认的缓冲区只有16KB，跑千兆网络时吞吐量死活上不去。调大之后，直接翻了5倍。

Linux下调整方法

// 获取当前缓冲区大小
int sndbuf, rcvbuf;
socklen_t len = sizeof(int);
getsockopt(sock, SOL_SOCKET, SO_SNDBUF, &sndbuf, &len);
getsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rcvbuf, &len);

// 设置缓冲区大小（注意：内核会翻倍）
int new_sndbuf = 1024 * 1024;  // 1MB
setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &new_sndbuf, sizeof(int));

系统级调优可以改/proc文件：

# 查看当前值
cat /proc/sys/net/ipv4/tcp_rmem
cat /proc/sys/net/ipv4/tcp_wmem

# 临时修改（最小、默认、最大）
echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 65536 16777216" > /proc/sys/net/ipv4/tcp_wmem

二、Nagle算法

Nagle算法，说白了就是「攒够了再发」。它的规则是：如果发送方有数据要发，但之前发的小包还没收到ACK，那就先把数据攒着，等ACK到了或者攒够一个MSS了再发。

这个算法在1984年设计出来时，是为了解决「愚蠢窗口综合症」——就是那种发一个字节也要占40字节TCP头部的浪费行为。但在今天，它经常帮倒忙。

我记得有一次做游戏服务器，客户端发操作指令，每个指令就几十个字节。开了Nagle算法后，延迟从5ms飙到了200ms。玩家操作后要等200ms才有反应，这游戏还怎么玩？

关闭Nagle算法

int flag = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(int));

你想想看，如果发的是大文件，一个包就占满MSS了，Nagle算法根本不会触发。所以关了也没影响。但如果是小包，关了之后网络利用率会下降，每个包都有40字节头部开销。这是个取舍问题。

三、延迟确认

TCP确认机制里有个优化：收到数据后不立即发ACK，而是等一小段时间（通常40-200ms），看看有没有数据要回复，如果有就捎带过去。这就是延迟确认（Delayed ACK）。

这个机制本身没问题，但和Nagle算法一起用就出事了。Nagle在等ACK，延迟确认在等数据，两边互相等，形成了死锁。这就是著名的「Nagle + Delayed ACK 死锁」问题。

我曾经排查过一个诡异的问题：客户端发请求，服务端要等500ms才响应。抓包一看，客户端发了小包，服务端延迟确认，客户端Nagle算法等着ACK不发后续数据，服务端也等着客户端发完数据才处理。两边就这么干瞪眼。

解决方案

• 关闭Nagle算法（最直接）
• 禁用延迟确认（不推荐，影响所有连接）
• 应用层做数据合并，避免小包

// 禁用延迟确认（Linux 2.6+）
int flag = 1;
setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &flag, sizeof(int));

四、零拷贝技术

传统的数据发送流程是这样的：应用数据 → 内核缓冲区（CPU拷贝） → 网卡。如果数据来自文件，还要先读到应用缓冲区，再写到socket缓冲区。数据在内核和用户空间之间来回拷贝，白白浪费CPU。

零拷贝技术，就是让数据直接从文件到网卡，或者从一个socket到另一个socket，不经过用户空间。说白了，就是让内核帮你搬砖，你别插手。

sendfile系统调用

#include <sys/sendfile.h>

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

这个函数直接把文件描述符中的数据发送到socket。数据从磁盘读到内核缓冲区，然后直接DMA到网卡，全程不经过用户空间。

我在做静态文件服务器时，用sendfile替代了read+write，CPU占用从80%降到了15%。效果立竿见影。

splice系统调用

#include <fcntl.h>

ssize_t splice(int fd_in, loff_t *off_in, int fd_out, 
               loff_t *off_out, size_t len, unsigned int flags);

splice可以在两个文件描述符之间移动数据，不需要用户空间缓冲区。它适用于从一个socket到另一个socket的转发场景。

五、知识体系总览

下面这张图把今天讲的内容串起来了。你可以看到，TCP缓冲区、Nagle算法、延迟确认、零拷贝技术，它们分别作用于网络栈的不同层次，但最终目标都是提升性能。

从这张图可以看出，性能调优是分层进行的。应用层关注业务逻辑，传输层关注TCP参数，内核层关注数据拷贝方式，硬件层关注DMA能力。每一层都有优化空间，但最立竿见影的往往是传输层和内核层。

六、实战建议

说了这么多，我总结几条实战经验：

1. 先测量，后调优。用netstat、ss、tcpdump看当前状态，别凭感觉改参数。
2. 一次只改一个参数。同时改缓冲区、Nagle、延迟确认，出了问题你都不知道是谁的锅。
3. 关注BDP。缓冲区大小至少是BDP的两倍，才能跑满带宽。
4. 交互式应用关Nagle。延迟敏感的场景，TCP_NODELAY是标配。
5. 文件传输用零拷贝。sendfile和splice能省掉大量CPU拷贝。

---