問題描述
云主機對外訪問網絡資源時出現網絡卡頓的情況。通過執行ping命令，發現網絡存在丟包或時延較高的情況。
原因分析
出現網絡訪問丟包或時延較高的問題，可能存在多方面原因，比如鏈路擁塞、鏈路節點故障、服務器負載高、系統設置問題等。
解決方法
在出現訪問丟包或者時延高的情況下，可以優先對云主機自身原因進行排查。
如果云主機運行狀態正常（如不存在負載異常等情況），可以使用Tracert或MTR工具進行進一步診斷。
Tracert和MTR工具使用方式
Windows操作系統使用Tracert命令方式
tracert是路由跟蹤命令，用來跟蹤數據包到達目的地址過程中的跳轉路徑，以及每一跳消耗的時間。tracert命令功能與ping命令類似，但可以獲得更詳細的路徑信息，包括數據包所走的全部路徑、節點IP以及消耗時間。
-
登錄Windows云主機。
-
打開cmd命令窗，執行命令
tracert IP地址/域名跟蹤路徑，例如：tracert www.daliqc.cn。
可以根據回顯信息，對數據節點進行分析：
1）tracert默認最大跳數30，第1列為起跳順序號。
2）tracert每次會發送三個數據包，第2、3、4列為對應三個數據包的返回時間，如果包丟失則返顯為“*” 。
3）第5列為跳轉的目標IP節點，如果某一行的此列出現了“請求超時”或“request timed out”，請您根據實際情況對該節點問題進行排查。
Windows操作系統使用WinMTR工具介紹
-
登錄Windows云主機，WinMTR需要訪問公網下載，因此請確認云主機可訪問公網。
-
請您通過瀏覽器尋找正規途徑搜索并下載WinMTR軟件包。此軟件無需安裝，解壓即可運行。
-
雙擊WinMTR.exe，運行WinMTR。
-
在WinMTR窗口的Host處，輸入目的地址，可以為IP地址或者域名。完成后單擊“Start”。
-
根據鏈路情況不同，運行時間不同，如果一段時間未運行完成可單擊“Stop”以結束測試。結果如下圖所示。
測試結果的主要信息如下：
1）第一列-Hostname：到目的地址經過的每個節點IP或域名。
2）第二列-Nr：經過的節點數量。
3）第三列-Loss%：對應節點的丟包率。
4）第四列-Sent：已發送的數據包數量。
5）第五列-Recv：已接收到的響應數量。
6）第六列-Best：最短響應時間。
7）第七列-Avrg：平均響應時間。
8）第八列-Worst：最長響應時間。
9）第九列-Last：最近一次響應時間。
Linux操作系統MTR介紹和使用
-
您可以執行以下命令進行安裝MTR，安裝前請確保您的云主機可訪問公網。如果已安裝可跳過此步驟。
1）CentOS 操作系統執行以下命令安裝：yum install mtr2）Ubuntu 操作系統執行以下命令安裝：
sudo apt-get install mtr -
MTR相關參數說明，請根據您的實際情況選擇參數使用：
-h/--help：顯示幫助菜單。
-v/--version：顯示MTR版本信息。
-r/--report：結果以報告形式輸出。
-p/--split：與 --report相對，分別列出每次追蹤的結果。
-c/--report-cycles：指定每次探測發送的數據包數量，默認值是10。
-s/--psize：設置數據包的大小。
-n/--no-dns：不對IP地址做域名解析。
-a/--address：用戶設置發送數據包的IP地址，主要用戶單一主機多個IP地址的場景。
-4：IPv4。
-6：IPv6。
-
以本機到目的地址www.daliqc.cn為例，執行以下命令，以報告形式輸出MTR的診斷結果。
mtr www.daliqc.cn --report回顯信息如下：
主要輸出的信息如下：
1）第一列-HOST：到目的地址經過的每個節點IP或域名。
2）第二列-Loss%：對應節點的丟包率。
3）第三列-Snt：已發送的數據包數量。
4）第四列-Last：最近一次響應時間。
5）第五列-Avg：平均響應時間。
6）第六列-Best：最短響應時間。
7）第七列-Wrst：最長響應時間。
8）第八列-StDev：標準偏差。偏差值越高，說明各個數據包在該節點的響應時間相差越大。
WinMTR和MTR的報告分析處理
以下圖為例，對MTR報告進行分析。
- 客戶端本地網絡：即圖中A區域，代表本地局域網和本地網絡提供商網絡。
1）如果客戶端本地網絡中的節點出現異常，則需要對本地網絡進行相應的排查分析。
2）如果本地網絡提供商網絡出現異常，則需要向當地運營商反饋問題。 - 運營商骨干網絡：即圖中B區域，如果該區域出現異常，可以根據異常節點的IP查詢其所屬的運營商，向對應運營商進行反饋。
- 目標服務器本地網絡：即圖中C區域，即目標服務器所屬提供商的網絡。
1）如果丟包發生在目標服務器，則可能是目標服務器的網絡配置原因，請檢查目的服務器的防火墻配置。
2）如果丟包發生在接近目標服務器的幾跳，則可能是目標服務器所屬提供商的網絡問題。 - 鏈路負載均衡：即圖中的D區域，如果中間鏈路某些部分啟用了鏈路負載均衡，則mtr命令只會對首尾節點進行編號和探測統計，中間節點只會顯示相應的IP或域名信息。
常見的鏈路異常案例
-
目標主機配置不當。
如下示例所示，數據包在第5條的目標地址出現了80%的丟包，問題可能是目標服務器網絡配置原因，需檢查目標服務器的訪問配置。
-
ICMP限速。
如下圖所示，在第6、7跳出現丟包，但后續節點均未見異常。推斷是該節點ICMP限速所致。該場景對最終客戶端到目標服務器的數據傳輸不會有影響，分析時可以忽略此種場景。
-
環路。
如下圖所示，數據包在第5跳之后出現了循環跳轉，導致最終無法到達目標服務器。出現此場景是由于運營商相關節點路由配置異常所致，需聯系相應節點歸屬運營商處理。
-
鏈路中斷。
如下圖所示，數據包在第4跳之后就無法收到任何反饋。這通常是由于相應節點中斷所致。建議結合反向鏈路測試做進一步確認。該場景需要聯系相應節點歸屬運營商處理。
