意见箱
恒创运营部门将仔细参阅您的意见和建议,必要时将通过预留邮箱与您保持联络。感谢您的支持!
意见/建议
选择附件
添加更多
{{item.label}} 删除
支持.jpg, .gif, .jpeg, .png, .rar, .zip, .tar.gz, .xls 格式,最多上传5个文件,每个最大 3M
提交建议
首页>>云服务器 v4

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

来源:恒创科技  编辑:恒创科技编辑部  时间:2021-12-28 12:02


有时,本地访问云服务器,或者在云服务器上访问其他网络资源时,发现网络卡顿。使用 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 操作系统:

yum install mtr

●  Ubuntu 操作系统:

sudo apt-get install mtr

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 的诊断报告。

mtr 156.247.12.45 -- report

返回类似如下信息:

主要输出的信息如下:

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

       ● Loss%:丢包率。

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

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

       ● Avg:平均响应时间。

       ● Best:最短的响应时间。

       ● Wrst:最长的响应时间。

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

报告结果分析及处理

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

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

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

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

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

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

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

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

说明:

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

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

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

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

常见的链路异常案例

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

Host              Loss%   Snt   Last   Avg    Best  Wrst    StDev 
1. ???
2. ???
3. 1XX.X.X.X          0.0%    10     521.3   90.1   2.7    521.3   211.3
4. 11X.X.X.X          0.0%    10    2.9   4.7   1.6   10.6   3.9
5. 2X.X.X.X          80.0%   10    3.0   3.0   3.0   3.0   0.0
6. 2X.XX.XX.XX         0.0%    10    1.7   7.2   1.6   34.9   13.6
7. 1XX.1XX.XX.X        0.0%    10    5.2   5.2   5.1   5.2   0.0
8. 2XX.XX.XX.XX        0.0%    10    5.3   5.2   5.1   5.3   0.1
9. 1XX.1XX.XX.X        100.0%   10    0.0   0.0   0.0   0.0   0.0

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

Host             Loss%   Snt   Last  Avg   Best  Wrst   StDev 
1. 1XX.XX.XX.XX       0.0%    10   0.3   0.6  0.3   1.2   0.3
2. 1XX.XX.XX.XX       0.0%    10   0.4   1.0  0.4   6.1   1.8
3. 1XX.XX.XX.XX       0.0%    10   0.8   2.7  0.8   19.0   5.7
4. 1XX.XX.XX.XX       0.0%    10   6.7   6.8  6.7   6.9   0.1
5. 1XX.XX.XX.XX       0.0%    10   27.2  25.3  23.1  26.4   2.9
6. 1XX.XX.XX.XX       0.0%    10   39.1  39.4  39.1  39.7   0.2
7. 1XX.XX.XX.XX       0.0%    10   39.6  40.4  39.4  46.9   2.3
8. 1XX.XX.XX.XX       0.0%    10   39.6  40.5  39.5  46.7   2.2


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

Host              Loss%   Snt   Last   Avg     Best  Wrst    StDev 
1. 1XX.XX.XX.XX        0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 1XX.XX.XX.XX        0.0%    10    0.4   1.0   0.4   6.1   1.8
3. 1XX.XX.XX.XX        0.0%    10    0.8   2.7   0.8  19.0   5.7
4. 1XX.XX.XX.XX        0.0%    10    6.7   6.8   6.7   6.9   0.1
5. 1XX.XX.XX.65        0.0%    10    0.0   0.0   0.0   0.0   0.0
6. 1XX.XX.XX.65        0.0%    10    0.0   0.0   0.0   0.0   0.0
7. 1XX.XX.XX.65        0.0%    10    0.0   0.0   0.0   0.0   0.0
8. 1XX.XX.XX.65        0.0%    10    0.0   0.0   0.0   0.0   0.0
9. ???             0.0%    10    0.0   0.0   0.0   0.0   0.0


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

Host            Loss%    Snt    Last   Avg   Best   Wrst    StDev 
1. 1XX.XX.XX.XX      0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 1XX.XX.XX.XX      0.0%    10    0.4   1.0   0.4   6.1   1.8
3. 1XX.XX.XX.XX      0.0%    10    0.8   2.7   0.8    19.0   5.7
4. 1XX.XX.XX.XX      0.0%    10    6.7   6.8   6.7   6.9   0.1
5. 1XX.XX.XX.XX      0.0%    10    0.0   0.0   0.0   0.0   0.0
6. 1XX.XX.XX.XX      0.0%    10    0.0   0.0   0.0   0.0   0.0
7. 1XX.XX.XX.XX      0.0%    10    0.0   0.0   0.0   0.0   0.0
8. 1XX.XX.XX.XX      0.0%    10    0.0   0.0   0.0   0.0   0.0
9 1XX.XX.XX.XX       0.0%    10    0.0   0.0   0.0   0.0   0.0