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