第2章网络基础优化

网络基础优化：TCP/IP协议栈调优

做中间件开发这些年，我踩过最多的坑，就是网络延迟。

你想想看，一个请求从客户端发出去，经过网卡、协议栈、内核缓冲区，再到对端应用。这中间任何一个环节出问题，延迟就上去了。今天咱们就从最底层开始，把TCP/IP协议栈的那些调优门道聊透。

TCP/IP协议栈的核心瓶颈

先看一张图，这是我总结的协议栈处理流程：

这张图里标红的几个点，就是咱们今天要啃的硬骨头。

Nagle算法：好心办坏事

Nagle算法是1984年提出的。初衷是好的——减少小包数量，避免网络拥塞。它的逻辑很简单：

如果数据小于MSS（最大报文段大小），就先攒着
等收到前一个包的ACK，或者攒够MSS了，再发出去

听起来挺合理对吧？但在我做过的项目中，这玩意儿坑了不少人。

典型场景：交互式应用、实时通信、高频交易

这些场景下，每个请求就几十个字节。Nagle算法一介入，延迟直接飙升到40ms以上。

我记得有一次排查一个Redis集群的延迟问题。客户端发一个SET命令，服务器要等200ms才响应。查了半天，发现就是Nagle算法在作祟。客户端攒着数据不发送，服务器那边干等着。

TCP_NODELAY：一剑封喉

解决方案很简单——禁用Nagle算法。在Socket上设置TCP_NODELAY选项就行。

// Java示例
Socket socket = new Socket();
socket.setTcpNoDelay(true);  // 禁用Nagle算法

// C/C++示例
int flag = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

// Python示例
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

我的建议：对于延迟敏感的应用，默认就开启TCP_NODELAY。除非你明确知道自己在做什么，否则别关。

但这里有个坑——TCP_NODELAY只解决了发送端的问题。接收端还有个延迟确认机制，同样会引入延迟。

延迟确认：另一个隐形杀手

TCP协议规定，收到数据包后要发送ACK确认。但为了减少ACK包的数量，协议栈会等一小段时间（通常40ms），看看有没有数据要回传。如果有，就把ACK和数据一起发出去。

这就是延迟确认（Delayed ACK）。

你想想看，如果发送端发了数据，接收端没有数据要回，那ACK就得等40ms。这40ms里，发送端可能已经超时重传了。

我曾经踩过的坑：一个消息中间件项目，客户端发消息后要等服务端确认。服务端处理很快，但客户端就是感觉慢。抓包一看，每次请求都等40ms才收到ACK。这就是延迟确认和Nagle算法叠加的后果。

解决方案有两个方向：

修改内核参数：调整tcp_delack_min，把延迟确认时间缩短
应用层优化：让接收端尽快发送响应数据，触发ACK随数据一起返回

# Linux内核参数调整
# 查看当前延迟确认时间（单位：毫秒）
cat /proc/sys/net/ipv4/tcp_delack_min

# 修改为10ms（默认是40ms）
echo 10 > /proc/sys/net/ipv4/tcp_delack_min

# 或者直接禁用延迟确认（不推荐）
echo 0 > /proc/sys/net/ipv4/tcp_delack_min

核心原则：延迟确认不是不能改，但要权衡。改得太小，ACK包数量暴增，CPU开销上升。我一般建议改成10-20ms，效果比较均衡。

Socket缓冲区大小调优

缓冲区大小这个事，说白了就是空间换时间。

发送缓冲区太小，应用层写数据时会被阻塞。接收缓冲区太小，对端发来的数据会被丢弃，触发重传。

但缓冲区太大也不行——内存占用高，而且TCP流控会变迟钝。

场景	推荐发送缓冲区	推荐接收缓冲区	说明
实时通信	16KB - 64KB	16KB - 64KB	延迟优先，小缓冲区
文件传输	256KB - 1MB	256KB - 1MB	吞吐优先，大缓冲区
消息中间件	64KB - 256KB	64KB - 256KB	平衡型
数据库连接	128KB - 512KB	128KB - 512KB	根据查询大小调整

调优方法也很直接：

// Java设置缓冲区大小
Socket socket = new Socket();
socket.setSendBufferSize(65536);   // 64KB
socket.setReceiveBufferSize(65536);

// C/C++设置
int sendbuf = 65536;
int recvbuf = 65536;
setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &sendbuf, sizeof(sendbuf));
setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &recvbuf, sizeof(recvbuf));

// 查看系统默认值
// cat /proc/sys/net/ipv4/tcp_wmem
// cat /proc/sys/net/ipv4/tcp_rmem

我的调优习惯：先用默认值跑，然后观察/proc/net/tcp里的发送/接收缓冲区使用情况。如果经常满，就加大。如果一直空闲，就减小。别拍脑袋设值。

实战：一个完整的调优案例

去年我帮一个金融客户优化他们的交易网关。延迟要求是5ms以内，但实际跑出来经常到20ms。

抓包分析后发现三个问题：

Nagle算法开启，小包被延迟发送
延迟确认40ms，ACK迟迟不来
发送缓冲区只有16KB，高并发时频繁阻塞

改动很简单：

// 1. 禁用Nagle
socket.setTcpNoDelay(true);

// 2. 调整内核参数
echo 10 > /proc/sys/net/ipv4/tcp_delack_min

// 3. 加大缓冲区
socket.setSendBufferSize(131072);   // 128KB
socket.setReceiveBufferSize(131072);

改完之后，延迟从20ms降到了3ms以内。效果立竿见影。

注意：这些改动不是银弹。如果你的网络本身就有丢包，或者链路延迟很高，调这些参数效果有限。先确认问题出在协议栈层面，再动手。

嗯，网络基础优化这块，今天就聊到这儿。记住一句话：TCP协议栈的默认配置，是为通用场景设计的。你的业务场景特殊，就得自己动手调。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

网络基础优化：TCP/IP协议栈调优

TCP/IP协议栈的核心瓶颈

Nagle算法：好心办坏事

TCP_NODELAY：一剑封喉

延迟确认：另一个隐形杀手

Socket缓冲区大小调优

实战：一个完整的调优案例