中国移动通信集团广东有限公司 刘瑛
文章摘要： 在运营商的网络环境中，无论是共有云、私有云还是政企专线、IT部门，运维人员经常会碰见这样的反馈和投诉：明明购买了1000M的链路专线，为何进行测速时不能达到带宽上限？实际流量速率表现未能满足用户的期待，是运维部门日常工作中疑难杂症里比较“头大”的一类；从多年的云维护工作经验中，笔者发现这些问题的根因可以归类为“重传与丢包”、“接受效率”、“发送效率”三个主要方向，有针对性地排查数个关键指标，可有效提升解决这类问题的效率。在本文中，笔者主要运用实际案例，讲解监测“接收效率”的意义所在。
1理论部分 — 决定接受效率的三个关键参数
关键参数1：接收窗口
TCP header中有一个Window Size字段，它其实是指接收端的窗口，即接收窗口，用来告知发送端自己所能接收的数据量；其实TCP在整个发送过程中，也在度量当前的网络状态，目的是为了维持一个健康稳定的发送过程，比如拥塞控制。可以说，TCP数据是在窗口机制的控制下进行传输的。
窗口字段—占2字节。窗口字段用来控制对方发送的数据量，单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方在接下来的这次传输中发送数据量的上限。
关键参数2：窗口扩展因子
TCP诞生初期，上世纪八九十年代时候，IETF的RFC 793定义window size最大为2的16次方，为65535，后随着宽带不断提高，65535字节已经小了，为了突破限制，便有了Window Size Scaling选项，假设window scale为7，也就是要将Window Size的值左移七位，即乘以2的7次方（128），如下图所示：
.png)
需要注意的有两点：
1）window scale最大为14，即乘以2的14次方（8192）；
2）在整个双方的交互过程中，发送方和接收方Window size scaling factor乘积因子必须保持不变，但是发送方的乘积因子和接收方的乘积因子可以不同，由各自决定。
关键参数3：RTT
RTT(Round Trip Time)：一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值；
这个参数一般可以从数据交互的三次握手中取得，如果网络维持在较为稳定的状态，那么测量的时候，笔者一般使用三次握手时间作为RTT的平均值，如右图所示；
.png)
2案例分析—某政府部门云专线传输文件慢的问题排查
2.1用户故障
某运营商资源池，客户反馈云专线复制文件速度出现异常，存在“慢”的问题；正常的传输过程可以达到20MB/秒；异常的传输过程只能达到4.91MB/秒
移动云上用打流工具测试，该用户4台云主机中，3台正常，1台异常：其中192.168.0.3、8、9的单线程速度都能达到170Mbps-180Mbps，不过192.168.0.5只能达到40Mbps。
2.2正常的会话流程监测
通过移动云回溯分析系统跟踪192.168.0.3的数据打流过程；发现网络时延维持在0.012ms左右，而且在三次握手的前两个包，192.168.0.3按照正常的TCP机制同步窗口扩展因子08（代表2的8次方）： 传输过程中，192.168.0.3的实时窗口是1026：所以根据接收窗口理论传输效率可达：1026 × 256（2的8次方）÷0.012（秒，网络时延） ×8=175 Mbps，跟实测值接近。
.png)
2.3 异常的会话流程
通过移动云回溯分析系统跟踪192.168.0.5的数据打流过程；在三次握手过程中，未见协商TCP窗口扩展因子的参数；而且，打流过程中，TCP接收窗口稳定在65535字节：
.png)
除此之外，192.168.0.5的测试中移动云专线质量稳定，过程中未见丢包重传，网络时延稳定13.5ms左右；根据TCP接收窗口65535÷0.135×8，传输速率理论值上限为38Mbps左右，和实测值接近。接收窗口过小，影响传输效率的表现如下：
.png)
如上图所示，每传3个包就需要接受端确认一次ACK，收到这个ACK后，再传下一段数据；每次ACK包的传输，均需要耗费一次网络时延，这样的数据交互严重影响了传输效率，所以云主机192.168.0.5的量速率峰值一直小于40Mbps。
2.4 对比两台系统的TCP参数设置
192.168.0.5的TCP窗口扩展因子自动调节级别为disable：
.png)
192.168.0.3的TCP窗口扩展因子自动调节级别为normal：
.png)
2.5 修改192.168.0.5的配置并重新打流
需要说明的是：云主机是统一镜像的，系统参数是不会有差异的。
为了解决用户的问题，我们执行了以下指令：netsh int tcp set global autotuninglevel=normal；
并做好了备份指令：netsh int tcp set global autotuninglevel=disabled
执行后，0.5的速率依然是40Mbps左右，抓包分析后发现，交互的窗口依然是65535：也就是说TCP窗口扩展因子修改未能生效，登录系统发现：之前调整会normal的配置，查看的时候又变回disable了！
也就是说，有应用在后台修改了改系统的TCP参数。
2.6主机修改策略
针对该问题，协调主机组专家并提交操作系统的case，诊断后得出以下修改方案；经过专家组内部研究，修改autotuning可以通过netsh或者powershell或者是组策略，如果是组策略下发的，在本地通过netsh或者powershell设置应该不生效，另外还有一个ScalingHeuristics 的参数可以让Windows能够自动将自己的TCP窗口自动调优行为改变为更保守的状态，而不考虑任何用户设置，建议禁用：netsh interface tcp set heuristics wsh=disabled；参考文档
2.7 优化效果评估
调优后重新打流，发现文件共享速度有了较大的提升，可以达到30.28MB/s了；从监测系统上看，该云主机峰值超过300Mbps，该速率满足用户预期值，问题得以解决：
.png)
2.8 问题排查结论
对于其他云主机来说，192.168.0.5传输效率较低的原因是系统被修改，TCP接口窗口自动调节功能关闭，传输中双方的接收窗口只有65535字节，导致速率不能符合真实的水平，以及未能满足用户的期待。
合理怀疑备份软件修改了系统的参数。
3心得体会
回溯网络数据，观察TCP数据交互过程，可以直观的定位问题。
留意并调整合适的TCP参数，对于解决故障问题的方向和效率有重要意义。
关于打流问题排查，建议优先查看是否有丢包和重传，若没有，则建议重点关注接收窗口；
在实际工作中，“接收窗口”和“丢包重传”问题是打流问题的最常见根因；其中单线程打流速度上不去，往往是“接收窗口”的问题。