【OSS 排查方案-5】透过现象看本质之网络排查分析
背景:拿到數據包時如何通過眾多的數據,提煉出有效的網絡分析信息,快速的進行定位排障。以下總結了一些 OSS 上傳/下載慢的共性問題,提供大家參考。
排查問題之前讓我們先來回顧一下 TCP 的基礎知識
TCP 結構:
基礎名詞:
- Sequence Number是包的序列號,用來解決網絡包亂序(reordering)問題。
- Acknowledgement Number就是ACK —— 用于確認收到,用來解決不丟包的問題。
- Window又叫Advertised-Window,也就是著名的滑動窗口(Sliding Window),用于解決流控的。
- TCP Flag,也就是包的類型,主要是用于操控TCP的狀態機的。
- CWND ,也就是初始化發包控制的數量, ip ro 可以看到。 ip route 可以設置
- package flow ,數據包的流動增長。
常用抓包命令:
tcpdump -i 出口網卡 -s0 -v host \( 本地出口IP and 服務端IP \) -w filename.pcap架構:
1)本地 PC -》 OSS 上傳
2)本地 PC -》 OSS 上傳
3)ECS -》 VPC 環境 -》OSS 下載
第一種架構:
首先根據 TCP/IP connect find important message
- client WS = 256
- MSS = 1452
- SACK = 1
- server WS = 0
- cwnd = 2
- length 1506
通過已知的信息我們可以先得出一些判斷
- server 端不支持 WS,也就是一個往返 RTT 內最大傳輸是 64KB
- server support SACK,so transmission lose package,not all package
- cwnd tiny,起始傳輸會比較 slow,后續探測 reciver ACK 后,會指數遞增
?通過 RTT 可以看出來我們的網絡穩定在 0.035
分析 TCP Stream? 流圖可以得知,延遲低,而且無丟包,從而可以得知并非是延遲丟包導致的傳輸速度慢。
分析發包的規律分布
通過以上幾張連續的判斷可以得知,客戶端的 cwnd 是 2,而且每經過一個 RTT 后都會進行倍數的遞增 2,4,6,8 最終穩定在 9 個,正常的 TCP 協議棧應該是以指數被遞增,linux 是 64 ,windows 應該是到 256,同時我們也得知了對方是在一個 windows 系統上發包,協議棧和 Linux 的有很大區別。
接下準備分析為什么客戶上傳慢的原因:
RTT 是 35ms ,每個 RTT 只能傳 9 個包,也就是 9*1506 / 35 = 378KB/s
總的時間? 8876789/378/1024 = 23 + 卡頓 ~= 30S
所以整個發包速度慢也就是正常的
而服務端不支持 WS 的情況下,理論的最大傳輸速度也應該是:
根據 TCP 傳輸原理,理論最大傳輸速度 = WND / RTT = 64KB / 0.035 = 1828KB/s
1s 內有 1000/35 = 29 個 RTT, 29* 64 = 每個 RTT 最大傳輸量
但是現在每秒鐘只能傳輸 1506 * 9 = 13554 = 13KB
綜合結論客戶端的 TCP 協議站傳輸是有問題。
第二種架構
老套路,先分析 TCP 三次握手中的基本信息。
- 服務端支持的 ws, 512 ,也就是單程 RTT 最大的傳輸量是 576 KB。
- 客戶端的首發包數量是 2 個,也是成倍數遞增 2,4,6,8,20 ...最終是 20。
- RTT 有持續增長的狀態,因此三次握手的 RTT 可能不準確,我們需要計算一個加權后的 iRTT,最后得到是 40ms。
為什么延遲大的情況下,我們的傳輸速度反而比直傳 OSS 穩定 0.035S 的要快呢?因為服務端支持 WS,也就是客戶端在傳輸過程中的 package 可以持續滑動。
所以計算下來就是 434/(20*1498/0.04/1024) = 590ms?
整個數據包傳輸完的時間 ~= 572ms
第三種架構
先從三次握手中獲取價值信息
- 客戶端、服務端都支持 WS?
- RTT 穩定在 0.006
- send package 穩定在 88 個。
- 按照 WS 的支持一秒中最多能傳的包是? 88 * 1514 /0.006 =21MB/S
- 理論傳輸 1000/6 = 166,現在最大能傳到 104,平均 88 ,可能存在 TCP 協議棧的問題。最終手段通過服務端調整了 OSS 機器的 TCP 協議棧,增大了 send package 和 CWND
總結
以上是生活随笔為你收集整理的【OSS 排查方案-5】透过现象看本质之网络排查分析的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Redis数据过期策略详解
- 下一篇: 解决pycharm输入法不跟随的方法