在“高延迟网络”上具有更好的TCP性能

我正在尝试通过Linux机器之间的“高延迟网络”改善TCP吞吐量。

我设置tcp_mem，tcp_wmem并tcp_rmem以“8192 7061504 7061504”。
我设置rmem_max，wmem_max，rmem_default并wmem_default为“7061504”。
我将netdev_max_backlog和设置txqueuelen为10000。
我将其设置tcp_congestion_control为“可缩放”。

我正在使用“ nist”（cnistnet）来模拟100ms的延迟，而我达到的带宽约为200mbps（无延迟时，我达到790mbps）。

我正在使用iperf进行测试，并使用TCPTrace分析结果，这就是我得到的：

在接收方：
最大获胜副词：5294720字节
平均获胜副词：5273959字节
发送的麻袋数：0

在发送方：
实际数据字节：3085179704
rexmt数据字节：9018144
最大值：5294577字节
平均值：3317125字节
RTT最小值：19.2 ms
RTT最大值：218.2 ms
RTT平均值：98.0 ms

为什么我只能达到200mbps？我怀疑“ owin”与它有关，但是我不确定（这些结果是2分钟的测试。1分钟的测试中的“平均”是1552900）…

我是否期望即使延迟为100ms，吞吐量也将接近790mbps？

（我尝试在窗口配置中使用更大的数字，但似乎没有效果）

这是一个常见的TCP问题，称为“长发管道”。如果您用谷歌搜索该短语和TCP，就会发现很多有关此问题和可能解决方案的信息。

该线程提供了大量计算和建议，用于针对此类情况调整Linux TCP堆栈。

网站

http://www.psc.edu/networking/projects/tcptune/

提到当今的Linux会自动调整TCP设置，弄乱这些值可能不会有所改善。

话虽这么说，也许100毫秒加上较大的带宽（至少790 mbps）可能会导致巨大的BDP，因此自动调整可能会判定某些问题是错误的，并且远远不够。

尝试将iperf窗口大小设置为真正达到该链接的带宽延迟乘积。如此平均。RTT * 1Gbps应该大致为您提供10MB。看看是否可以改善情况。

您真正开始了解正在发生的事情的唯一方法是获取更多数据-否则您只是在猜测，或在要求其他人猜测。我建议sar从iostat软件包中获取系统级视图（cpu，内存，中断等）。另外，您应该使用Wireshark或tcpdump获得数据包转储。然后，您可以使用Wireshark对其进行分析，因为它有很多用于此目的的工具。您可以绘制窗口大小随时间变化，数据包丢失等的图形。

高延迟链路上即使有一点数据包丢失也往往会严重损害带宽。尽管正在模拟-这有点奇怪。许多小数据包也可能导致高中断（即使也可以模拟这些中断？）。

简而言之，请获取TCPDump和Sar以查看数据包级别以及系统资源的状况。

这台机器有多少内存？该tcp_mem设置似乎是疯了，它的TCP数据全局配置28GB（7061504 * 4KB）。（但这不是您的性能问题，因为您很可能在几路测试运行中未达到该限制。只想提一下，因为将tcp_mem设置为tcp_xmem值会显示出非常普遍的误解。）

您为默认配置的7mb似乎还可以。但是，在大型延迟管道上，最大值可能会更高。为了测试我将使用64MB作为最大数量tcp_wmem和tcp_rmem，那么你就可以排除，这是你的限制因素。（这确实会使您的缓冲区过大，因此，仅在您的并发性有限且连接具有低抖动和掉线的情况下才起作用）。