高延迟链路上TCP跑不满带宽，很多人第一反应是拥塞控制算法不行，或者线路质量太差。但有一个更基础、也更容易被忽略的因素：接收窗口太小，导致发送方在等待ACK的过程中无事可做。这不是算法的问题，是数学问题。带宽延迟积(BDP)决定了在任意时刻，链路上“在途”的数据量必须达到某个阈值，才能把管道填满。如果TCP缓冲区不够大，接收方通告的窗口就小，发送方被限制在“发一点、等一等”的节奏里，链路再宽也跑不出速度。

　　先算清楚：你的链路到底需要多大的窗口

　　在动任何参数之前，得先知道目标是什么。BDP的计算公式很简单：带宽乘以RTT，再除以8换算成字节。一条100Mbps的链路，RTT为50ms，BDP就是100,000,000 × 0.05 / 8 = 625,000字节，约610KB。这意味着接收方至少要有610KB的可用缓冲区来通告窗口，发送方才能在不等待ACK的情况下持续灌满这100Mbps。

　　如果RTT更高，比如跨境线路常见的150ms，同样100Mbps的BDP就变成了约1.8MB。而Linux默认的tcp_rmem最大值通常是6MB左右，看起来够用，但问题在于自动调优的触发条件和实际通告窗口的计算方式，并不总是能让缓冲区增长到理论上限。

　　一个快速的验证方法是：在接收端用iperf3测试时，手动指定一个很大的窗口，看吞吐是否显著提升。

# 在接收端（服务端）运行
iperf3 -s

# 在发送端（客户端）运行，先测默认
iperf3 -c <接收端IP> -t 30

# 再测手动指定大窗口
iperf3 -c <接收端IP> -t 30 -w 4M

　　如果-w 4M的吞吐明显高于默认测试，说明默认的缓冲区/窗口大小确实成了瓶颈。注意Linux内核在设置SO_RCVBUF时会将请求值翻倍，所以实际生效的缓冲区大约是-w参数的两倍，但前提是不超过rmem_max的上限。

　　tcp_rmem的三元组：min、default、max各管什么

　　net.ipv4.tcp_rmem是一个三元组，三个值单位都是字节，含义完全不同。

　　第一个值是最小缓冲区大小。每个TCP socket在创建时，接收缓冲区不会低于这个值。默认通常是4096字节，对于现代网络来说很小，但它的作用是保底，防止极端情况下socket连基本的数据都收不了。

　　第二个值是默认缓冲区大小。如果应用程序没有通过setsockopt(SO_RCVBUF)显式设置缓冲区，内核会用这个值作为初始接收缓冲区。在自动调优开启的情况下(tcp_moderate_rcvbuf=1)，这个值只是一个起点，缓冲区会随着连接的实际需求动态增长。默认值通常在87380字节左右。

　　第三个值是自动调优的上限。这是最关键的一个。无论自动调优怎么努力，接收缓冲区都不会超过这个值。默认通常是6291456字节(6MB)。对于低延迟局域网，6MB绰绰有余;但对于高BDP链路，比如100Mbps配150ms RTT(BDP约1.8MB)，6MB的上限理论上够用，但实际能否涨到那个水平，取决于内核自动调优的判断逻辑。

　　tcp_wmem的结构完全对称，管的是发送缓冲区。但这里有一个容易被忽略的不对称性：发送缓冲区的大小受接收方通告窗口的限制。即使你把tcp_wmem的最大值调到很大，如果接收方通告的窗口只有64KB，发送方也只能发64KB就停下来等ACK。所以调优的顺序应该是先确认接收侧，再考虑发送侧。

　　自动调优不是万能的

　　Linux的接收缓冲区自动调优机制(tcp_moderate_rcvbuf)的设计目标是：根据应用程序实际读取数据的速度来动态调整缓冲区大小，而不是简单地根据到达速率。内核会跟踪应用层read()系统调用的消费速率，然后尝试把接收缓冲区维持在“应用在一个RTT内能读走的数据量”的两倍左右。

　　这个策略在短RTT场景下工作得很好，因为应用读得再慢，RTT也短，缓冲区不需要很大就能匹配。但在高延迟链路上，问题就暴露了：如果应用程序的读取速度本身就不快，自动调优会把缓冲区维持在一个较小的水平，导致通告窗口小，发送方发得慢，数据到达更慢，应用读得更慢——这是一个负反馈循环，吞吐量被锁死在低水平上。

　　有一个更隐蔽的细节：Linux计算接收窗口时，实际上取的是min(tcp_rmem[2], 已拷贝数据量)的一个函数。这意味着即使你把tcp_rmem的最大值调得很大，如果应用读得慢，实际通告的窗口仍然会被限制住。这不是一个简单的“调大参数就能解决”的问题，它揭示了内核流控算法在高BDP场景下的一个结构性局限。

　　所以调大tcp_rmem[2]的效果，取决于你的应用是否能够及时消费数据。对于iperf3这种疯狂读取的测试工具，调大上限立刻见效;对于一个处理逻辑复杂、单次读取量小的应用，调大上限可能只是让缓冲区里积压更多数据，延迟反而增加，吞吐未必改善。

　　实操：调什么、怎么调、调完怎么验证

　　如果确认瓶颈在缓冲区，调整分两步。先改内核参数，再确认应用没有覆盖它。

　　查看当前值：

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

　　根据你的BDP计算一个合理的上限。假设目标链路是200Mbps、RTT 120ms，BDP = 200,000,000 × 0.12 / 8 = 3,000,000字节，约3MB。考虑到自动调优需要一定的余量，把tcp_rmem[2]设到BDP的2到3倍是稳妥的，比如8MB到12MB。

　　临时生效：

sysctl -w net.ipv4.tcp_rmem="4096 87380 12582912"
sysctl -w net.ipv4.tcp_wmem="4096 65536 12582912"

　　持久化写入/etc/sysctl.d/下的配置文件，用sysctl -p加载。

　　但这里有一个坑：net.core.rmem_max和tcp_rmem[2]的关系。如果应用程序通过setsockopt(SO_RCVBUF)请求一个缓冲区，内核会把请求值翻倍后与net.core.rmem_max比较，取较小值。而自动调优机制使用的是tcp_rmem[2]作为上限。两者是独立的限制路径。如果你只调了tcp_rmem但应用硬编码了SO_RCVBUF，实际生效的可能是rmem_max限制下的值，调参不会生效。

　　验证时，用ss -tmi查看活跃连接的缓冲区状态：

ss -tmi | grep -A1 "ESTAB"

　　输出里的skmem:(r...,rb...,t...,tb...)，rb是接收缓冲区当前大小，tb是发送缓冲区。在iperf3跑满的过程中观察这个值是否接近你设置的tcp_rmem[2]。如果rb一直远低于上限，说明自动调优认为不需要那么大，问题可能不在缓冲区参数，而在应用读取或拥塞控制。

　　什么时候调缓冲区有用，什么时候是白费力气

　　调大tcp_rmem/tcp_wmem在一种场景下效果最明显：发送端和接收端都是你控制的机器，应用读取速度快，链路RTT高但丢包率低。比如两台VPS之间的数据同步、跨境文件传输、或者你自己写的服务端程序。这种情况下，缓冲区上限是纯粹的数学约束，解开就释放。

　　但在以下场景，调参数几乎不会带来改善。公网网站服务：访问者的设备、浏览器、中间网络都不受你控制，接收方的窗口大小由用户的设备和操作系统决定，你调大自己服务器的tcp_wmem只能让你发得更快，但用户收不收得下是另一回事。高丢包链路：如果RTT高的同时丢包率也高，拥塞控制会把窗口降下来，缓冲区再大也填不满，因为发送方主动限速了。应用读取本身就是瓶颈：如果服务器端程序在处理每个请求时花了大量时间做数据库查询或计算，读socket的速度上不去，缓冲区调大只会增加排队延迟，对吞吐没有帮助。

　　一个更根本的替代方案是调整拥塞控制算法。BBR在设计上不依赖缓冲区填满来探测带宽，它对BDP的敏感度低于CUBIC。但在接收窗口受限的场景下，BBR也受制于同一个数学约束：接收方通告的窗口就是发送方的上限，算法再聪明也突破不了。所以BBR和缓冲区调优不是互斥的，先确认窗口不是瓶颈，再考虑算法。