4、接收缓冲区调优：SO_RCVBUF选项、接收缓冲区大小对性能的影响、如何计算最佳接收缓冲区大小

接收缓冲区，说白了就是内核为每个 socket 准备的一个“临时仓库”。数据从网络抵达后，先在这个仓库里排队，等着应用程序来取。仓库太小，数据会溢出丢包；仓库太大，又白白浪费内存。怎么调？咱们今天就把这事聊透。

4.1 SO_RCVBUF 选项：手动接管缓冲区大小

默认情况下，内核会根据系统负载自动调整接收缓冲区。但自动调整不一定适合你的业务场景。我习惯在项目初期就通过 SO_RCVBUF 把缓冲区大小固定下来，避免内核“瞎猜”。

设置方法很简单，在 socket 创建后、连接建立前调用 setsockopt：

int rcvbuf = 87380;  // 单位：字节
if (setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf)) < 0) {
    perror("setsockopt SO_RCVBUF");
}

注意：内核会对设置值做“加倍”处理。你设 87380，内核实际分配的是 87380 × 2 = 174760 字节。为什么？因为内核要预留一部分空间给自身的管理开销。这个“加倍”行为在 Linux 2.4 之后一直存在，别被实际值吓到。

想确认实际分配了多少？用 getsockopt 读回来看看：

int actual;
socklen_t len = sizeof(actual);
getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &actual, &len);
printf("实际接收缓冲区大小: %d 字节\n", actual);

我曾经在一个视频流项目中遇到过坑：设了 256KB 的接收缓冲区，结果 getsockopt 返回 512KB，内存直接翻倍。后来查文档才知道是内核的“加倍”机制。嗯，从那以后我每次设完都会读回来确认一遍。

4.2 接收缓冲区大小对性能的影响

缓冲区大小直接影响两个核心指标：吞吐量和延迟。它们之间的关系，我画了张图帮你理解：

你想想看，如果缓冲区太小，数据包来了没地方放，内核只能丢掉。TCP 发现丢包后会触发重传，重传又占用带宽，吞吐量直接崩了。反过来，缓冲区太大，数据在缓冲区里积压，应用程序读到的是“旧数据”，延迟自然就高了。

我遇到过最典型的案例是一个金融交易系统。对方要求延迟低于 1 毫秒，但默认的接收缓冲区是 128KB。数据量一大，缓冲区里积压了几百个包，应用层读到数据时行情已经变了。后来我们把缓冲区降到 16KB，配合 TCP_NODELAY，延迟直接降到 0.3 毫秒。你看，有时候“小”反而是好事。

4.3 如何计算最佳接收缓冲区大小

最佳大小不是拍脑袋定的，得算。我一般用这个公式：

最佳接收缓冲区大小 = 带宽 × RTT

其中 RTT 是网络往返时延，单位秒；带宽单位是 bps，结果要除以 8 转成字节。

举个例子：你的服务器带宽是 1Gbps，客户端到服务器的 RTT 是 20ms。那么：

最佳大小 = (1 × 10^9 bps) × (0.02 s) / 8 = 2,500,000 字节 ≈ 2.5 MB

这个值的意思是：在数据从发送端出发到收到确认的这段时间里，接收端需要 2.5MB 的缓冲区才能把“在途数据”全部装下。低于这个值，发送端会因为接收窗口满而停等，吞吐量上不去。

但实际项目中，我很少直接套这个公式。为什么？因为还有两个变量要考虑：

变量	影响	我的建议
应用处理速度	如果应用处理慢，缓冲区再大也没用，数据只会积压	先压测应用的处理能力，再反推缓冲区大小
内存预算	每个连接都按“最佳大小”分配，并发一高内存就爆了	用 `net.core.rmem_max` 限制上限，按业务优先级分配
丢包率	高丢包环境下，缓冲区太大反而加剧延迟	丢包率 > 1% 时，缓冲区建议减半

我的调优步骤：

先用公式算出理论值，作为初始参考。
用 ss -i 观察实际 rcv_space 和 rcv_ssthresh，看内核自动调整到了多少。
逐步增大或减小缓冲区，配合 iperf 或真实业务流量压测，记录吞吐量和延迟曲线。
找到“吞吐量不再明显增长”的那个点，那就是你的最佳值。

我曾经在一个 CDN 边缘节点上做过测试。理论计算需要 4MB 缓冲区，但实际压测发现 1MB 时吞吐量已经达到线速，再增大到 4MB 吞吐量只提升了 2%，延迟却增加了 15ms。最后我们定了 1MB，既省内存又保证性能。

4.4 系统级调优：别只盯着应用层

应用层设了 SO_RCVBUF 还不够，系统层有两个参数你得知道：

net.core.rmem_default：所有 socket 的默认接收缓冲区大小。
net.core.rmem_max：SO_RCVBUF 能设置的上限。你应用层设 10MB，但系统上限只有 2MB，那实际生效的还是 2MB。

查看当前值：

sysctl net.core.rmem_default
sysctl net.core.rmem_max

临时修改：

sysctl -w net.core.rmem_default=262144
sysctl -w net.core.rmem_max=4194304

永久生效就写进 /etc/sysctl.conf。

避坑指南：我曾经在生产环境直接改了 rmem_max 为 16MB，结果几百个连接瞬间吃掉 8GB 内存，OOM Killer 直接把进程杀了。改系统参数前，一定先算好“最大连接数 × 缓冲区大小”会不会超过物理内存。

4.5 实战：用 ss 命令监控接收缓冲区

调优不是一次性的活。上线后你得持续监控。我常用的命令是 ss -i，它会输出每个 socket 的接收缓冲区状态：

ss -i | grep -A 1 "ESTAB"

# 输出示例：
# Netid  State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port
# tcp    ESTAB   0       0       192.168.1.1:80       192.168.1.2:54321
#          rcv_space:87380  rcv_ssthresh:87380

重点关注两个字段：

Recv-Q：当前在接收缓冲区里排队、等待应用读取的字节数。如果这个值持续大于 0，说明应用处理速度跟不上网络接收速度。
rcv_space：内核自动计算的“理想缓冲区大小”。如果它经常接近你设的 SO_RCVBUF，说明缓冲区可能偏小了。

嗯，到这里接收缓冲区调优的核心内容就差不多了。记住一句话：缓冲区不是越大越好，也不是越小越好，而是要刚好匹配你的业务流量特征。动手试试，用公式算个初始值，再配合压测和监控，你很快就能找到那个“黄金点”。