我试图通过一个“高延迟networking”来提高TCP吞吐量，在Linux机器之间有一些数据包丢失。
我将tcp_mem ， tcp_wmem和tcp_rmem为“8192 20530752 20530752”。
我将rmem_max ， wmem_max ， rmem_default和wmem_default为“20530752”。
我将netdev_max_backlog和txqueuelen设置为50000。
我将tcp_congestion_control设置为“可伸缩”。
我使用“nist”（cnistnet）来模拟延迟50ms（每个方向25ms）和0.5％（每个方向0.25％）的下降，BW I达到约7.48mbps。
下面是一个结果表（使用iperf来度量费率）：
| 0ms | 50ms 0% | 710mbps | 276mbps 0.5% | 181mbps | 7.48mbps
我没有想到延迟会对吞吐量产生如此大的影响（不适用于这些大的TCP窗口）。 我也没想到这个滴效果如此之好。 特别是与“可伸缩”algorithm不同，因为它的“拥塞窗口”应该很快从数据包丢失恢复。
我用tcpdump ＆ sar （sysstat的一部分）试图看看发生了什么事情。 在萨尔的报告中我没有看到任何可疑的东西。 而在tcp转储我看到：
“rexmt data pkts”= 88（在8183中发送）
“rexmt data bytes”= 127,424字节（已发送的44,649,104个字节）
“avg owin”= 135,964字节。
“avg retr time”= 53.5 ms。
这是最好的TCP可以做的吗？ 在这种情况下，没有其他algorithm可以达到更好的吞吐量吗？ 我的scheme是不寻常的（我认为50毫秒延迟0.5滴是普通的广域网属性）？