我正在尝试不同的拥塞控制算法，以在 TCP 流的设置中获得最大吞吐量和最小延迟。请建议除以下之外的其他可用算法
维诺、韦斯特伍德、里诺和立方
其实现（或内核模块）可以在互联网上免费获得。并建议是否有其他方法可以在不同端的 Linux (Fedora) 和 Windows 7 的 TCP 协议栈之间运行 TCP 以获得更高的吞吐量。
答案1
黑匣子：）。
如果丢包率低于 15%，则 BBR 能够充分利用该路径（达到 link_bandwidth*(1 - loss_rate)）。这个 15% 阈值是一个设计参数，而不是一个基本限制
我正在努力解释这一点的确切意义。这是埃里克·杜马塞特：
与 Cubic 相比，在有损环境下存在 2 到 4 个数量级的差异。
100ms rtt 和 1% 数据包丢失的示例。 Cubic 在那里表现非常糟糕。
$ netperf -H 10.246.7.152 -l 30 -- -K cubic
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 40.00 3.27
$ netperf -H 10.246.7.152 -l 30 -- -K bbr
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.25 9150.01
第三方测试揭示/引发了一个解释，即如果存在任何竞争，当前代码预计在瓶颈处有一个完整的缓冲区 (BDP)。这是进一步改进的已知目标。如果不满足条件，就会提高损失率。那么传统的 TCP 基本上就会挨饿。
如果有更多的缓冲区大于 1 BDP，BBR 流将协作以避免填充多余的缓冲区，因此根据您的要求限制排队延迟。传统的 TCP 往往会填满整个缓冲区。当两者竞争时，BBR 无法神奇地修复传统 TCP 流的行为，但我认为这不会以任何其他方式伤害 BBR。
如果不满足上述条件，应用程序延迟将受到影响（必须重新传输丢失的数据包）。
https://groups.google.com/forum/#!forum/bbr-dev
答案2
无情 TCP 将是您可以获得的最无情的 TCP。