我有一个10GbE连接到交换机的服务器，和10个客户端，每个连接1GbE连接到同一个交换机。
在每个客户机上并行运行nuttcp，我可以以接近线速的速度同时向服务器推送10个TCP数据stream（即，同时从所有10个客户机以每秒100兆字节为单位）。
然而，当我逆转方向并将数据从服务器发送到客户端时（即，10个TCPstream，每个客户端一个TCP连接），TCP重新传输量猛增，性能下降到30,20甚至10兆字节每秒每个客户端。 我希望得到这些数字，因为这种stream量模式是我关心的某些应用程序的代表。
我已经validation了我的服务器能够通过在类似的服务器上通过10GbE连接执行相同的实验来饱和10GbE链路。 我已经validation在我的任何端口上都没有错误。
最后，当我强行钳制（限制）接收器的TCP窗口大小时，我可以获得更高的带宽（30-40兆字节/秒）。 如果我将其限制得非常低，我可以将重传数据设置为零（带宽低得可怜）。
因此，我相当有把握地确信我的交换机中的缓冲区溢出，导致拥塞导致的数据包丢失。 但是，我认为TCP的拥塞控制本来是要处理好的，最终稳定在线速度的50％以上。
所以我的第一个问题很简单：哪个TCP拥塞控制algorithm最适合我的情况？ 有很多可用的，但他们似乎主要是针对有损networking或高带宽高延迟networking或无线networking…没有一个适用于我的情况。
第二个问题：还有什么我可以尝试？
你会想要一个algorithm，当有一个数据包丢失时，窗口大小没有大幅度减less。 这是窗口大小的急剧下降，导致TCPstream量突然下降。
如果您的交换机和服务器支持stream量控制，请尝试启用stream量控制。 几乎完全取决于Switch的芯片和固件。 基本上，交换机将检测连接到客户端的端口的出口拥塞，确定数据包来自哪里，并将stream量控制帧从入口端口（即回到服务器）发送出去。 如果服务器了解stream量控制帧，则会降低传输速度。 如果一切正常，您将获得最佳的吞吐量，并在交换机的出口缓冲区上发生几乎零丢包。