1007
ECS資源下載慢 ，如何分析定位？
問題背景
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左右。
檢查帶寬限製
檢查有2端的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傳輸優化內容。
最後更新：2017-05-04 15:07:42