问题背景

4月中旬，收到某用户反馈，从华北2地域的ECS下载华东1的ECS上的资源，下载速度被限制为2M，此问题会对用户的业务产生极大的影响，涉及到企业的大量业务订单，问题非常紧急。

收到用户反馈后我们立即根据现有的情况进行分析。

分析思路

下载速度的影响因素有哪些？

1、网络延迟；

2、客户端&服务端的出入带宽限制；

3、运营商中间链路限制(有些情况下就算ping延迟低，但也可能看到TCP或UDP协议的传输过程中被运营商认为的加入延迟来限速)；

4、客户端的多线程行为；

5、服务端和客户端的OS层面的TCP协议层面的接受发送窗口（Auto Tuning）的相关配置，Selective ACK协议的行为；

注：

TCP协议层面的接受发送窗口（Auto Tuning）的相关配置，如下：

TCP 滑动窗口（TCP Windowing）大小，窗口缩放因子（Window Scaling）的值。

分析过程

测试网络延迟

华东1与华北2之间互ping延迟为30ms左右。

检查带宽限制

检查客户端与服务端的ECS的出入带宽均没有到达上限。

测试使用多线程下载

问题是ECS限制了2M的下载速度，为了佐证ECS下载速度没有限制，测试使用mwget，多线程下载工具下载，轻松跑到30M左右。

说明ECS本身网络是没有限制的。

抓包分析报文

三次握手的过程如下（下图为Server的抓包）

这里也走了一些歪路 ，查看ACK的的交互有30ms左右的延迟，就定位为延迟导致的网络延迟。

如在报文完整的传输过程中，可以看到每隔30-50个报文就会出现延迟30ms的情况。

但是我们进行了对比测试，从上海，深圳等测试，

如：ping延迟小的情况下，有出现下载慢，而ping延迟大，有出现下载快的情况。于是思考延迟只是这个问题出现的一方面的原因。故继续分析报文。

考虑是否有网络限速的可能

查看报文出现30ms左右延迟的报文，均是ACK的报文。不太像网络限速。

TCP 参数检查

如上，单线程最多能够下载2M左右，但是多线程能够跑很高；判断可能是TCP参数导致的问题。

从这个角度分析TCP 三次握手信息：

SYN：

SYN,ACK 

ACK

三次握手完成后的结果为：没有启动窗口缩放功能。

window滑动窗口的大小是固定的。

查看系统配置：

查看确实没有开启。

输入：

修改为1后下载能够上升到20-30M左右，符合预期。

总结

1、如分析思路中描述的内容，影响下载速度的因素有很多，在定位时需要全部的内容都分析，然后找到最影响传输速度的项，针对性的进行优化。

2、本案例中需要了解：TCP 滑动窗口（TCP Windowing）、窗口缩放因子（Window Scaling）这2个概念的含义。

注意：TCP Window Scaling仅在TCP连接的双方都开启时才真正有效

3、这个案例的原因为没有开启Window Scaling导致传输速度不理想，属于TCP传输优化内容。

专家介绍

枫凡，目前在阿里云从事ECS产品的技术支持，专注于云计算相关的安全问题以及网络问题。坚信：“不忘初心，方得始终”