一 问题描述：

通过25G交换机下服务器向10G交换机下服务器，通过iperf3压测带宽只有1/2G。另外，通过测试服务器多次验证，不是每次测试都上不去，多数情况还是能打到接近10G的，只有碰到中间网络丢包严重时才这样。

二 问题分析

通过多次测试发现，当网络环境不稳定时，如上图所示，丢包比较严重，需要较长时间才可以把拥塞窗口调整下来。怀疑拥塞控制算法cubic启动过程异常，启动参数异常。

通过stap跟踪内核cwnd变化情况，发现异常和正常情况下变化不大，可以确定，iperf显示的cwnd与内核中计算的不是一个概念，iperf显示应该是包含了重传数据包后自己计算的。

                                                      异常情况下cwdn变化

                                                 正常情况下cwnd变化

对比上述两幅图，分别为丢包严重和丢包很少情况，cwnd变化情况，其中图右侧为iperf统计信息，相差很大；而左侧为probe跟踪的内核中对应sock的cwnd变化情况，可以看到两幅图上，内核中cwnd是一致的，都是从10开始的慢启动过程。

另外，对比下图，为压测过程中，带宽带宽上不去时，内核统计到的tcpRetrans统计（重传包统计）信息，与ipef统计是可以对应起来，而带宽正常时该项统计计数为零（不显示），可以确认是有用网络丢包较严重，恢复不及时导致。

三 问题结论

对比其他服务器发现，server端没有启动sack功能，开启后对比结果如下：

上图为通过iperf3连续打压52次，带宽平均值对比。其中，左边为tcp_sack == 0， 可以明显看到10次带宽只有2-3G左右，且重传数据包非常多（中间列数字）；对比右边tcp_sack==1 时的情况，可明显看到带宽很稳定，都是再9.8G以上，且重传报文很少。