偵測到ping有明顯丟包時如何作連結測試

本篇文章给大家带来的内容是关于检测到ping有明显丢包时如何作链路测试，有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。

Windows实例网络访问丢包延时高

当网站访问很慢或无法访问时，若排除其它显著问题，而检测到 ping 有明显丢包时，建议您作链路测试。Windows 环境下，您可以通过 WinMTR 工具（优先使用） 或 TRACERT 命令行工具进行链路测试来判断问题来源。

通常情况下，请依照下述步骤进行处理：

利用链路测试工具探测网络状况和服务器状态。

根据链路测试结果分析处理。

WinMTR 工具（优先使用）

mtr（My traceroute）作为一款网络测试工具，集成了 tracert 与 ping 这两个命令的图形界面。ping 与 tracert 通常被用來检测网络状况和服务器状态，具体说明如下：

WinMTR 是 mtr 工具在 Windows 环境下的图形化实现，适合 Windows 下做路由追踪及 ping 测试。WinMTR 默认发送 ICMP 数据包进行探测，无法切换。

相比 TRACERT 命令行工具，WinMTR 能避免节点波动对测试结果的影响，测试结果更正确。Windows 环境下，建议优先使用 WinMTR 进行链路测试。（点击官方网站下载获取。）

操作步骤

在官网下载 WinMTR 后 ，直接解压运行。运行程序后，在 Host 字段输入目标服务器域名或 IP（前面不要包含空格）。

单击 Start 开始测试。（开始测试后，相应按钮变成了 Stop。）

运行一段时间后，单击 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 以域名显示相关节点。

查看 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 超时 消息中包含了相应节点的信息。

操作步驟

在桌面底部點選 開始 選單，選擇 運行。

開啟運行框後，在框中輸入 cmd 並按一下 確定。

在指令運行介面中，輸入 tracert ，按下回車鍵後，介面將顯示 tracert 的用法說明。

根據具體用法，輸入待追蹤的目標位址。

範例

 C:\> tracert -d 223.5.5.5
 通过最多 30 个跃点跟踪到 223.5.5.5 的路由
   1     *        *        *     请求超时。
   2    9 ms     3 ms    12 ms   192.168.17.20
   3    4 ms     9 ms     2 ms   111.1.20.41
   4    9 ms     2 ms     1 ms   111.1.34.197
   5   11 ms     *        *      211.140.0.57
   6    3 ms     2 ms     2 ms   211.138.114.62
   7    2 ms     2 ms     1 ms   42.120.244.190
   8   32 ms     4 ms     3 ms   42.120.244.238
   9     *        *        *     请求超时。
   10   3 ms     2 ms     2 ms   223.5.5.5

#分析連結測試結果

以如下鏈路測試結果範例圖為基礎進行闡述：

#操作步驟

判斷各區域是否有異常，並根據各區域的情況分別處理。

區域 A：客戶端本地網絡，即本地區域網路和本地網路提供者網路。針對該區域異常，客戶端本地網路相關節點問題，請對本地網路進行排查分析；本地網路提供者網路相關節點問題，請向當地營運商回饋。

區域 B：營運商骨幹網路。針對該區域異常，可根據異常節點 IP 查詢歸屬運營商，然後直接或透過阿里雲售後技術支持，向相應運營商反饋問題。

區域 C：目標伺服器本機網絡，即目標主機歸屬網路提供者網路。針對該區域異常，需要向目標主機歸屬網路提供者回饋問題。

結合 Avg（平均值）和 StDev（標準差），判斷各節點是否有異常。

若 StDev 很高，則同步觀察對應節點的 Best 和 Wrst，來判斷對應節點是否有異常。

若 StDev 不高，則透過 Avg 來判斷對應節點是否有異常。

注意：上述 StDev 高 或 不高，並沒有特定的時間範圍標準。而需要根據同一節點其它列的延遲值大小來進行相對評估。例如，如果 Avg 為 30 ms，那麼，當 StDev 為 25 ms，則認為是很高的偏差。而如果 Avg 為 325 ms，則同樣的 StDev（25 ms），反而認為是不高的偏差。

查看節點丟包率，若 Loss% 不為零，則表示這一跳網路可能有問題。

導致節點丟包的原因通常有兩種：

人為限制了節點的 ICMP 發送速率，導致丟包。

節點確實有異常，導致丟包。

確定目前異常節點的丟包原因。

若隨後節點皆沒有丟包，表示目前節點丟包是由於營運商策略限制所致，可以忽略。如前文鏈路測試結果範例圖中的第 2 跳所示。

若隨後節點也出現丟包，表示目前節點有網路異常，導致丟包。如前文鏈路測試結果範例圖中的第 5 跳所示。

說明：前述兩種情況可能同時發生，即對應節點既存在策略限速，又存在網路異常。對於這種情況，若當前節點及其後續節點連續出現丟包，且各節點的丟包率不同，則通常以最後幾跳的丟包率為準。如前文鏈路測試結果範例圖所示，在第 5、6、7 跳均出現了丟包。所以，最終丟包情況，以第 7 跳的 40% 作為參考。

透過查看是否有明顯的延遲，來確認節點是否有異常。透過以下兩個面向進行分析：

若某一跳之後延遲明顯陡增，則通常判斷節點存在網路異常。如前文鏈路測試結果範例圖所示，從第 5 跳之後的後續節點延遲明顯陡增，則推斷是第 5 跳節點出現了網路異常。

注意：高延遲不一定完全意味著對應節點有異常，延遲大也有可能是在資料回包鏈路中引發的，建議結合反向連結測試一併分析。

ICMP 策略限速也可能導致對應節點的延遲陡增，但後續節點通常會恢復正常。如前文鏈路測試結果範例圖所示，第 3 跳有 100% 的丟包率，同時延遲也明顯陡增。但隨後節點的延遲馬上恢復正常了。所以判斷該節點的延遲陡增及丟包是由於策略限速所致。

其它建議

阿里雲中國大陸地域機房和其他國家或地區有網路通訊的專線，為降低通訊時候的丟包率，推薦使用高速通道。

若主機掉包和延遲非常高，建議作 WinMTR 雙向測試，即本地到伺服器的和伺服器到本地的測試。無法遠端登入時，請透過管理終端進行登入。

#

以上是偵測到ping有明顯丟包時如何作連結測試的詳細內容。更多資訊請關注PHP中文網其他相關文章！