Nem*_*emo 11 networking linux tcp
我有一台与交换机有 10GbE 连接的服务器，以及 10 个客户端，每个客户端与同一交换机有 1GbE 连接。
在每个客户端上并行运行 nuttcp，我可以将 10 个 TCP 数据流以接近线速的速度同时推送到服务器（即，所有 10 个客户端同时每秒传输 100 兆字节）。
然而，当我改变方向并将数据从服务器发送到客户端时——即 10 个 TCP 流，一个发送到每个客户端——TCP 重传会猛增，性能下降到每秒 30、20 甚至 10 兆字节每个客户。我想提高这些数字，因为这种流量模式代表了我关心的某些应用程序。
我已经通过在与类似服务器的 10GbE 连接上执行相同的实验来验证我的服务器能够使 10GbE 链路饱和。我已经确认我的任何端口都没有错误。
最后，当我强行限制（限制）接收方的 TCP 窗口大小时，我可以获得更高的带宽（30-40 兆字节/秒）；如果我把它限制得非常低，我可以让重传为零（带宽低得离谱）。
因此，我有理由相信我正在超限交换机中的缓冲区，从而导致由于拥塞而导致数据包丢失。然而，我认为 TCP 的拥塞控制应该可以很好地处理这个问题，最终稳定在 50% 以上的线速。
所以我的第一个问题很简单：哪种 TCP 拥塞控制算法最适合我的情况？有很多可用的，但它们似乎主要针对有损网络或高带宽高延迟网络或无线网络......这些都不适用于我的情况。
第二个问题：还有什么我可以尝试的吗？
小智 2
您需要一种在出现数据包丢失时窗口大小不会大幅减小的算法。窗口大小的急剧下降导致 TCP 流量的吞吐量突然下降。
如果您的交换机和服务器支持流量控制，请尝试启用流量控制。它的工作效果几乎完全取决于 Switch 的芯片和固件。基本上，交换机将检测连接到客户端的端口上的出口拥塞，确定数据包来自何处，并将流量控制帧发送出入口端口（即返回到服务器）。如果服务器理解流量控制帧，就会降低传输速度。如果一切正常，您将获得最佳吞吐量，并且交换机出口缓冲区上发生的数据包丢失几乎为零。