网络延迟丢包/使用MTR诊断网络问题

有时，本地访问云服务器，或者在云服务器上访问其他网络资源时，发现网络卡顿。使用 ping 命令，发现网络存在丢包或时延较高的情况。丢包或时延较高可能是骨干链路拥塞、链路节点故障、服务器负载高、系统设置问题等原因引起。

本文档以 Linux 和 Windows 云服务器为例，介绍如何使用 MTR 以及如何对 MTR 的报告结果进行分析。

解决方案

在排除云服务器自身原因后，使用 Tracert 工具对网络链路进行测试（请参阅：网络延迟丢包/使用Tracert测试链路），然后使用 MTR 进行进一步诊断。MTR 是一款网络诊断工具，其工具诊断出的报告可以帮助您确认网络问题的症结所在。

Windows ：WinMTR 的介绍及使用方法

WinMTR：适用于 Windows 系统的免费网络诊断工具，集成 Ping 和 tracert 功能，具有图形界面，可以直观地看到各个节点的响应时间和丢包情况。

安装 WinMTR

1. 登录 Windows 云服务器。

2. 在操作系统界面，通过浏览器访问官方网站（或合法渠道）下载对应操作系统类型的 WinMTR 包。

3. 解压缩 WinMTR 包。

使用 WinMTR

1. 双击 WinMTR.exe，打开 WinMTR 工具。

2. 在 WinMTR 窗口的 Host 处，输入目的服务器 IP 或者域名，单击【Start】。根据实际情况，等待 WinMTR 运行一段时间，单击【Stop】，结束测试。如下图所示：

测试结果的主要信息如下：

● Hostname：到目的服务器要经过的每个主机 IP 或名称。

●Nr：经过节点的数量。

●Loss%：对应节点的丢包率。

●Sent：发送的数据包数量。

●Recv：接收到响应的数量。

●Best：最短的响应时间。

●Avrg：平均响应时间。

●Worst：最长的响应时间。

●Last：最近一次的响应时间。

Linux：MTR 的介绍及使用方法

MTR：Linux 平台上诊断网络状态的工具，继承 Ping、traceroute、nslookup 功能，默认使用 ICMP 包测试两个节点之前的网络连接情况。

安装 MTR

执行以下命令在 Linux 云服务器中安装 MTR：

●CentOS 操作系统：

yuminstallmtr

●Ubuntu 操作系统：

sudoapt-getinstallmtr

MTR 命令用法：mtr [参数] hostname

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

使用示例

以本机到 IP 156.247.12.45 的服务器为例。执行以下命令，以报告形式输出 MTR 的诊断报告。

mtr156.247.12.45--report

返回类似如下信息：

主要输出的信息如下：

●HOST：节点的 IP 地址或域名。

●Loss%：丢包率。

●Snt：每秒发送的数量包的数量。

●Last：最近一次的响应时间。

●Avg：平均响应时间。

●Best：最短的响应时间。

●Wrst：最长的响应时间。

●StDev：标准偏差，偏差值越高，说明各个数据包在该节点的响应时间相差越大。

报告结果分析及处理

以下图为例分析 WinMTR 和 MTR 的报告。

●服务器本地网络：即图中A区域，代表本地局域网和本地网络提供商网络。

○ 如果客户端本地网络中的节点出现异常，则需要对本地网络进行相应的排查分析。

○如果本地网络提供商网络出现异常，则需要向当地运营商反馈问题。

●运营商骨干网络：即图中B区域，如果该区域出现异常，可以根据异常节点的IP查询其所属的运营商，向对应运营商进行反馈。

●目标端本地网络：即图中C区域，即目标服务器所属提供商的网络。

○如果丢包发生在目的服务器，则可能是目的服务器的网络配置原因，请检查目的服务器的防火墙配置。

○如果丢包发生在接近目的服务器的几跳，则可能是目标服务器所属提供商的网络问题。

说明：

由于网络状况的非对称性，遇到本地到服务器的网络问题时，建议您收集双向的 MTR 数据（从本地到云服务器以及云服务器到本地）。

●如果丢包发生在目的服务器，则可能是目的服务器的网络配置不当引起，请检查目的服务器的防火墙配置。

●如果丢包开始于前三跳，一般为本地运营商网络问题，建议检查访问其他网址是否存在相同情况。如果存在相同情况，请反馈给您的运营商进行处理。

●如果丢包发生在接近目的服务器的几跳，则可能为服务器运营商的网络问题，请 提交工单 进行反馈处理。提交工单时，请附上本地到目的服务器，以及目的服务器到本地的 MTR 测试截图，以便工程师进行定位。

常见的链路异常案例

●目标主机配置不当如下示例所示，数据包在目标地址出现了100%的丢包。从数据上看是数据包没有到达，其实很有可能是目标服务器网络配置原因，需检查目的服务器的防火墙配置。

HostLoss%SntLastAvg BestWrst StDev1.???2.???3.1XX.X.X.X 0.0% 10 521.3 90.1 2.7 521.3 211.34.11X.X.X.X 0.0% 102.94.71.6 10.6 3.95.2X.X.X.X80.0%103.03.03.0 3.00.06.2X.XX.XX.XX 0.0% 101.77.21.6 34.9 13.67.1XX.1XX.XX.X0.0% 105.25.25.1 5.20.08.2XX.XX.XX.XX0.0% 105.35.25.1 5.30.19.1XX.1XX.XX.X100.0% 100.00.00.0 0.00.0

●ICMP 限速如下所示，在第 5 跳出现丢包，但后续节点均未见异常。所以推断是该节点 ICMP 限速所致。该场景对最终客户端到目标服务器的数据传输不会有影响，分析时可以忽略此种场景。

HostLoss%SntLastAvg BestWrst StDev1.1XX.XX.XX.XX0.0%100.30.60.3 1.20.32.1XX.XX.XX.XX0.0%100.41.00.4 6.11.83.1XX.XX.XX.XX0.0%100.82.70.8 19.05.74.1XX.XX.XX.XX0.0%106.76.86.7 6.90.15.1XX.XX.XX.XX0.0%1027.225.323.126.42.96.1XX.XX.XX.XX0.0%1039.139.439.139.70.27.1XX.XX.XX.XX0.0%1039.640.439.446.92.38.1XX.XX.XX.XX0.0%1039.640.539.546.72.2

●环路如下所示，数据包在第 5 跳之后出现了循环跳转，导致最终无法到达目标服务器。出现此场景是由于运营商相关节点路由配置异常所致，需联系相应节点归属运营商处理。

HostLoss%SntLastAvg BestWrst StDev1.1XX.XX.XX.XX0.0%100.30.60.31.20.32.1XX.XX.XX.XX0.0%100.41.00.46.11.83.1XX.XX.XX.XX0.0%100.82.70.819.05.74.1XX.XX.XX.XX0.0%106.76.86.76.90.15.1XX.XX.XX.650.0%100.00.00.00.00.06.1XX.XX.XX.650.0%100.00.00.00.00.07.1XX.XX.XX.650.0%100.00.00.00.00.08.1XX.XX.XX.650.0%100.00.00.00.00.09.??? 0.0%100.00.00.00.00.0

●链路中断如下示例所示，数据包在第 4 跳之后就无法收到任何反馈。这通常是由于相应节点中断所致。建议结合反向链路测试做进一步确认。该场景需要联系相应节点归属运营商处理。

Host Loss% Snt LastAvg Best Wrst StDev1.1XX.XX.XX.XX0.0%100.30.60.31.20.32.1XX.XX.XX.XX0.0%100.41.00.46.11.83.1XX.XX.XX.XX0.0%100.82.70.8 19.05.74.1XX.XX.XX.XX0.0%106.76.86.76.90.15.1XX.XX.XX.XX0.0%100.00.00.00.00.06.1XX.XX.XX.XX0.0%100.00.00.00.00.07.1XX.XX.XX.XX0.0%100.00.00.00.00.08.1XX.XX.XX.XX0.0%100.00.00.00.00.091XX.XX.XX.XX 0.0%100.00.00.00.00.0