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