我正在尝试提高 Linux 机器之间“高延迟网络”的 TCP 吞吐量。
我将tcp_mem、tcp_wmem和设置tcp_rmem为“8192 7061504 7061504”。
我将 、 和 设置rmem_max为wmem_max“ rmem_default7061504 wmem_default”。
我将netdev_max_backlog和设置txqueuelen为 10000。
我设置tcp_congestion_control为“scalable”。
我使用“nist”（cnistnet）模拟100ms的延迟，达到的BW大约是200mbps（无延迟时达到大约790mbps）。
我正在使用 iperf 执行测试并使用 TCPTrace 分析结果，以下是我得到的结果：
在接收方：
最大获胜优势：5294720 字节
平均获胜优势：5273959 字节
发送的 sack pkts：0
在发送方：
实际数据字节：3085179704
rexmt 数据字节：9018144
最大 owin：5294577 字节
平均 owin：3317125 字节
RTT 最小值：19.2 毫秒
RTT 最大值：218.2 毫秒
RTT 平均值：98.0 毫秒
为什么我只能达到 200mbps？我怀疑“owin”与此有关，但我不确定（这些结果是 2 分钟的测试结果。1 分钟的测试结果为“平均 owin”为 1552900）...
即使延迟为 100 毫秒，我期望吞吐量也能达到近 790mbps，这是错的吗？
（我尝试在窗口配置中使用更大的数字，但似乎没有效果）
答案1
这是一个常见的 TCP 问题，称为“长胖管道”。如果您在 Google 上搜索该短语和 TCP，您会找到大量有关此问题及其可能解决方案的信息。
此主题对如何针对此类情况调整 Linux TCP 堆栈进行了大量计算和建议。
答案2
网站
http://www.psc.edu/networking/projects/tcptune/
提到由于 Linux 现在会自动调整 TCP 设置，因此修改这些值可能不会改善情况。
话虽如此，也许 100 毫秒加上大带宽（至少 790 mbps）可能会导致巨大的 BDP，因此也许自动调整会判定某些地方出了问题并且还不够彻底。
答案3
尝试设置 iperf 窗口大小以真正匹配该链接的带宽延迟乘积。因此平均 RTT * 1Gbps 应该会给您大约 10MB。看看这是否会改善情况。
答案4
这台机器有多少内存？tcp_mem设置似乎很疯狂，它全局配置了 28gb（7061504 * 4kb）用于 TCP 数据。（但这不是您的性能问题，因为您很可能不会在几个插槽的测试运行中达到该限制。只是想提一下，因为将 tcp_mem 设置为 tcp_xmem 值表明了一个非常常见的误解）。
您为默认值配置的 7mb 似乎没问题。但是，在延迟较大的管道上，最大值可能会高得多。为了进行测试，我将使用 64MB 作为tcp_wmem和的最大数字tcp_rmem，然后您可以排除这是您的限制因素。（这确实会使您的缓冲区膨胀，因此只有在并发性有限且连接抖动和丢失较少的情况下才有效）。