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