通常情況下，請依照下述步驟進行處理：
1.利用鏈路測試工具探測網絡狀況和服務器狀態。
2.根據鏈路測試結果分析處理。
WinWTR工具（優先使用）
mtr（My traceroute）作為一款網絡測試工具，集成了tracert與ping這兩個命令的圖形界面。ping 與 tracert 通常被用來檢測網絡狀況和服務器狀態，具體說明如下：
|
命令名稱 |
具體說明 |
|
ping |
送出風包到指定的服務器。如果服務器有回應就會傳送回封包，并附帶返回封包來回的時間。 |
|
tracert |
返回從用戶的電腦到指定的服務器中間經過的所有節點（路由）以及每個節點的回應速度。 |
WinMTR是mtr工具在Windows環境下的圖形化實現，適合Windows下做路由追蹤及ping測試。WinMTR默認發送ICMP數據包進行探測，無法切換。
相比TRACERT命令行工具，Winmtr能避免節點波動對測試結果的影響，測試結果更正確。Windows環境下，建議優先使用WinMTR進行鏈路測試。（請到官方網站去下載）
操作步驟
1.在官網下載WinMTR后，直接解壓運行。運行程序后，在Host字段輸入目標服務器域名或IP（前面不要包含空格）。
2.單擊Start開始測試。（開始測試后，相應按鈕變成了Stop。）
3.運行一段時間后，單擊Stop停止測試。
Copy Text to clipboard：將測試結果以文本格式復制到粘貼板。
Copy HTML to clipboard：將測試結果以 HTML 格式復制到粘貼板。
Export TEXT：將測試結果以文本格式導出到指定文件。
Export HTML：將測試結果以 HTML 格式導出到指定文件。
Options：可選參數。具體包括：
Interval（sec）：每次探測的間隔（過期）時間，默認為 1 秒。
Ping size(bytes)： ping 探測所使用的數據包大小，默認為 64 字節。
Max hosts in LRU list： LRU 列表支持的最大主機數，默認值為 128。
Resolve names：通過反查 IP 以域名顯示相關節點。
4.查看WinMTR運行后的返回結果。
說明：默認配置下，WinMTR測試結果說明如下：
第一列（Hostname）：到目的服務器要經過的每個節點主機 IP 或域名。
第二列（Nr）：節點編號。
第三列（Loss%）：節點丟包率。ping 數據包回復失敗的百分比，由此可判斷那個節點(線路)出現故障，是服務器所在機房還是國際路由干路。
第四列（Sent）：已發送的數據包數量。
第五列（Recv）：已成功接收的數據包數量。
第六、七、八、九列（Best 、Avg、Worst、Last）：分別是回應時間的最小值、平均值、最大值和最后一個數據包的回應時間。
TRACERT命令行工具
TRACERT (Trace Route) 是 Windows 自帶的網絡診斷命令行實用程序，用于跟蹤 Internet 協議 (IP) 數據包傳送到目標地址時經過的路徑。
TRACERT 通過向目標地址發送 ICMP 數據包來確定到目標地址的路由。在這些數據包中，TRACERT 使用了不同的 IP 生存期(TTL) 值。由于要求沿途的路由器在轉發數據包前至少必須將 TTL 減少 1，因此 TTL 實際上相當于一個躍點計數器 (hop counter)。當某個數據包的 TTL 達到零 (0) 時，相應節點就會向源計算機發送一個 ICMP 超時 的消息。
TRACERT 第一次發送 TTL 為 1 的數據包，并在每次后續傳輸時將 TTL 增加 1，直到目標地址響應或達到 TTL 的最大值。中間路由器發送回來的 ICMP 超時 消息中包含了相應節點的信息。
操作步驟
1.在桌面底部單擊開始菜單，選擇運行。
2.打開運行框后，在框中輸入cmd并單擊確定。
3.在命令運行界面中，輸入tracert，按回車鍵后，界面將顯示tracert的用法說明。
4.根據具體用法，輸入待跟蹤的目標地址。
分析鏈路測試結果
以如下鏈路測試結果示例圖為基礎進行闡述：
操作步驟
1.判斷各區域是否存在異常，并根據各區域的情況分別處理。
區域 A：客戶端本地網絡，即本地局域網和本地網絡提供商網絡。針對該區域異常，客戶端本地網絡相關節點問題，請對本地網絡進行排查分析；本地網絡提供商網絡相關節點問題，請向當地運營商反饋。
區域 B：運營商骨干網絡。針對該區域異常，可根據異常節點 IP 查詢歸屬運營商，然后直接或通過阿里云售后技術支持，向相應運營商反饋問題。
區域 C：目標服務器本地網絡，即目標主機歸屬網絡提供商網絡。針對該區域異常，需要向目標主機歸屬網絡提供商反饋問題。
2.結合Avg（平均值）和StDev（標準偏差），判斷各節點是否存在異常。
若 StDev 很高，則同步觀察相應節點的 Best 和 Wrst，來判斷相應節點是否存在異常。
若 StDev 不高，則通過 Avg 來判斷相應節點是否存在異常。
注意：上述 StDev 高 或者 不高，并沒有具體的時間范圍標準。而需要根據同一節點其它列的延遲值大小來進行相對評估。比如，如果 Avg 為 30 ms，那么，當 StDev 為 25 ms，則認為是很高的偏差。而如果 Avg 為 325 ms，則同樣的 StDev（25 ms），反而認為是不高的偏差。
3.查看節點丟包率，若Loss%不為零，則說明這一跳網絡可能存在問題。
導致節點丟包的原因通常有兩種：
人為限制了節點的 ICMP 發送速率，導致丟包。
節點確實存在異常，導致丟包。
4.確定當前異常節點的丟包原因。
若隨后節點均沒有丟包，說明當前節點丟包是由于運營商策略限制所致，可以忽略。如前文鏈路測試結果示例圖中的第 2 跳所示。
若隨后節點也出現丟包，說明當前節點存在網絡異常，導致丟包。如前文鏈路測試結果示例圖中的第 5 跳所示。
說明：前述兩種情況可能同時發生，即相應節點既存在策略限速，又存在網絡異常。對于這種情況，若當前節點及其后續節點連續出現丟包，而且各節點的丟包率不同，則通常以最后幾跳的丟包率為準。如前文鏈路測試結果示例圖所示，在第 5、6、7 跳均出現了丟包。所以，最終丟包情況，以第 7 跳的 40% 作為參考。
5.通過查看是否有明顯的延遲，來確認節點是否存在異常。通過如下兩個方面進行分析：
若某一跳之后延遲明顯陡增，則通常判斷該節點存在網絡異常。如前文鏈路測試結果示例圖所示，從第 5 跳之后的后續節點延遲明顯陡增，則推斷是第 5 跳節點出現了網絡異常。
注意：高延遲并不一定完全意味著相應節點存在異常，延遲大也有可能是在數據回包鏈路中引發的，建議結合 反向鏈路測試 一并分析。
ICMP 策略限速 也可能會導致相應節點的延遲陡增，但后續節點通常會恢復正常。如前文鏈路測試結果示例圖所示，第 3 跳有 100% 的丟包率，同時延遲也明顯陡增。但隨后節點的延遲馬上恢復了正常。所以判斷該節點的延遲陡增及丟包是由于策略限速所致。
故障賠償
極速響應
客戶服務
7*24小時售后支持
免費備案
京公網安備11030102000056號
京ICP備09061941號-4
商品已成功加入購物車
