文档

使用ping命令丢包或不通时的链路测试方法

更新时间:

当客户端访问目标服务器或负载均衡,使用ping命令测试出现丢包或网络不通时,可以通过链路测试工具进行链路测试来判断问题来源。本文介绍如何使用链路测试工具进行链路测试。

链路测试流程

通常情况下,链路测试流程如下图所示。链路测试流程图

链路测试流程说明如下:

  1. 获取本地网络对应公网IP地址。

    在客户端本地网络上,访问IP地址查询等网站,获取本地网络对应的公网IP地址。

  2. 正向链路测试(ping和mtr)。

    从客户端向目标服务器做ping和mtr链路测试。

    • ping:从客户端向目标服务器域名或IP地址做持续的ping测试时,建议至少测试100个数据包,记录测试结果。

    • mtr:根据客户端操作系统环境的不同,在Windows操作系统上使用WinMTR或在Linux操作系统上执行mtr命令,设置测试目的地址为目标服务器域名或IP地址,然后进行链路测试,记录测试结果。

  3. 反向链路测试(ping和mtr)。

    进入目标服务器操作系统内部向客户端做反向ping和mtr链路测试。

    • ping:从目标服务器向客户端IP地址做持续的ping测试时,建议至少测试100个数据包,记录测试结果。

    • mtr:根据目标服务器操作系统环境的不同,在Windows操作系统上使用WinMTR或在Linux操作系统上执行mtr命令,设置测试目的地址为客户端IP地址,然后进行链路测试,记录测试结果。

  4. 测试结果分析。

    对测试结果进行分析,相关参数说明请参见链路测试结果说明。确认异常节点后,访问IP地址查询等网站查询并获取相应节点归属的运营商及网络,解决方案如下:

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

    • 如果是运营商相关节点出现异常,则需要直接联系运营商,或联系阿里云售后技术支持向相应运营商反馈问题。

进行链路测试

Linux操作系统

MTR是一款网络诊断工具,其将pingtraceroute的功能合并,相对于traceroute只会做一次链路跟踪测试,mtr会对链路上的相关节点做持续探测并给出相应的统计信息。因此,mtr能避免节点波动对测试结果的影响,所以其测试结果更正确,建议优先使用。

MTR(推荐)

安装mtr

sudo yum install mtr

使用MTR

mtr命令格式如下:

mtr [-hvrctglspni46] [-help] [-version] [-report] [-report-cycles=COUNT] [-curses] [-gtk] [-raw] [-split] [-no-dns] [-address interface] [-psize=bytes/-s bytes] [-interval=SECONDS] HOSTNAME [PACKETSIZE]

常见的可选参数说明如下表所示,您也可以通过man mtr命令查看更多参数说明。

可选参数

参数说明

-r-report

以报告模式显示输出。

-p-split

将每次链路跟踪的结果分别列出来。

-s-psize

指定ping数据包的大小。

-n-no-dns

不对IP地址做域名反解析。

-a-address

设置发送数据包的IP地址。

说明

该参数用于主机存在多个IP地址的场景。

-4

只使用IPv4协议。

-6

只使用IPv6协议。

您也可以在mtr命令运行过程中,输入如下参数来快速切换模式。

参数

参数说明

h

显示帮助菜单。

d

切换显示模式。

n

启用或禁用DNS域名解析。

u

使用ICMP或UDP数据包进行探测。

MTR返回示例

以执行mtr 目标IP地址命令为例,返回结果如下:

默认配置下,返回结果列表中各数据项的说明如下。

参数

参数说明

Host

节点IP地址和域名。您可以按n键切换显示。

Loss%

节点丢包率。

Snt

已发送数据包数。默认值是10,可以通过参数-c指定。

Last

最近一次的探测延迟值。

Avg

探测延迟的平均值。

Best

探测延迟的最小值。

Wrst

探测延迟的最大值。

StDev

标准偏差。该值越大说明相应节点越不稳定。

traceroute

安装traceroute

sudo yum install traceroute

使用traceroute

traceroute命令格式如下:

traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [ -t TypeOfService ] [ -f flow ] [ -v ] [ -w WaitTime ] Host [ PacketSize ]

常见的可选参数说明如下表所示,您也可以通过man traceroute命令查看更多参数说明。

可选参数

参数说明

-d

使用Socket层级的排错功能。

-f

设置第一个检测数据包的存活数值TTL的大小。

-F

设置不要分段标识。

-g

设置来源路由网关,最多可设置8个。

-i

主机有多个网卡时,使用指定的网卡发送数据包。

-I

使用ICMP数据包替代UDP数据包进行探测。

-m

设置检测数据包的最大存活数值TTL的大小。

-n

直接使用IP地址而非主机名称(禁用DNS反查)。

-p

设置UDP传输协议的通信端口。

-r

忽略普通的Routing Table,直接将数据包发送到目标主机上。

-s

设置本地主机发送数据包的IP地址。

-t

设置检测数据包的TOS数值。

-v

详细显示指令的执行过程。

-w

设置等待远端主机回包时间。

-x

开启或关闭数据包的正确性检验。

traceroute返回示例

以执行mtr -I 目标IP地址命令为例,返回结果如下:

image.png

Windows操作系统

WinMTR是mtr工具在Windows环境下的图形化实现,但进行了功能简化,只支持部分mtr的参数。WinMTR默认发送ICMP数据包进行探测,无法切换。相比tracert,WinMTR能避免节点波动对测试结果的影响,所以测试结果更正确。所以在WinMTR可用的情况下,建议优先使用WinMTR进行链路测试。

WinMTR(推荐)

安装并使用WinMTR

下载WinMTR后无需安装,直接解压运行即可,操作方法非常简单,操作步骤如下。

  1. 前往WinMTR官网下载WinMTR。

  2. 解压WinMTR压缩包,并双击运行WinMTR。运行WinMTR

  3. Host中,输入目标服务器域名或IP地址。

    重要

    输入的目标服务器域名或IP地址不能包含空格。

    您还可以设置其他参数,参数说明如下:

    参数

    参数说明

    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. 单击Start,开始测试。

    开始测试后,Start会自动变成Stop,WinMTR自动显示测试结果。

  5. 运行一段时间后,单击Stop停止测试。

WinMTR返回示例

以测试目标服务器域名为例,返回示例如下:

测试进行中

默认配置下,返回结果中各数据项的说明如下:

参数

参数说明

Hostname

节点IP地址和域名。

Nr

节点编号。

Loss%

节点丢包率。

Sent

已发送的数据包数量。

Recv

已成功接收的数据包数量。

Best

节点延迟的最小值。

Avg

节点延迟的平均值。

Worst

节点延迟的最大值。

Last

节点延迟的最后一次值。

StDev

标准偏差。该值越大说明相应节点越不稳定。

tracert

tracert(Trace Route)是Windows系统自带的网络诊断命令行程序,用于跟踪Internet协议(IP)数据包传送到目标地址时经过的路径。

使用tracert

在Windows PowerShell或cmd命令行中执行tracert命令。

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

参数

参数说明

-d

不要将地址解析为主机名(禁用DNS反解)。

-h

maximum_hops,指定搜索目标地址时的最大跃点数。

-j

host-list,指定沿主机列表的松散源路由。

-w

timeout,等待每个回复的超时时间(以毫秒为单位)。

-R

跟踪往返行程路径(仅适用于IPv6)。

-S

srcaddr,要使用的源地址(仅适用于IPv6)。

-4

强制使用IPv4。

-6

强制使用IPv6。

target_host

目标主机域名或IP地址。

tracert返回示例

以执行tracert -d 目标IP地址命令为例,返回结果如下:

C:\> tracert -d 192.168.0.1
通过最多 30 个跃点跟踪到 192.168.0.1 的路由
1 请求超时。
2 9 ms 3 ms 12 ms 192.168.XXX.XXX
3 4 ms 9 ms 2 ms 10.20.XXX.XXX
4 9 ms 2 ms 1 ms 10.35.XXX.XXX
5 11 ms 211.24.X.XX
6 3 ms 2 ms 2 ms 200.12.XXX.XXX
7 2 ms 2 ms 1 ms 42.28.XXX.XXX
8 32 ms 4 ms 3 ms 42.25.2XX.2XX
9 请求超时。
10 3 ms 2 ms 2 ms 通过最多 30 个跃点跟踪到 192.168.0.1 的路由

跟踪完成。

链路测试结果说明

由于mtr命令有更高的准确性,本文以mtr命令测试结果为例,对链路测试结果的分析进行简要说明。后续的说明,均以如下链路测试结果示例图为基础进行阐述。

网络区域

通常情况下,从客户端到目标服务器的整个链路,会显著的包含如下区域:

  • 客户端本地网络

    本地局域网和本地网络提供商网络,如前文链路测试结果示例图中的区域A,一般为前2~3个节点。如果该区域出现异常,如果是客户端本地网络相关节点出现异常,则需要对本地网络进行相应排查分析。否则,如果是本地网络提供商网络相关节点出现异常,则需要向当地运营商反馈问题。

  • 运营商网络

    运营商网络,如前文链路测试结果示例图中的区域B,一般有很多个节点,并且会经过很多个骨干网络。如果该区域出现异常,可以根据异常节点IP地址查询该IP地址归属的运营商,然后直接或通过阿里云售后技术支持,向相应运营商反馈问题。

  • 目标服务器本地网络

    目标主机归属网络提供商网络,如前文链路测试结果示例图中的区域C,一般为最后目标服务器IP地址前的2~3个节点。如果该区域出现异常,则需要向目标主机归属网络提供商反馈问题。

链路负载均衡

如前文链路测试结果示例图中的区域D。如果中间链路某些部分启用了链路负载均衡,则mtr命令只会对首尾节点进行编号和探测统计。中间节点只会显示相应的IP地址或域名信息。

Avg(平均值)和 StDev(标准偏差)

由于链路抖动或其他因素的影响,节点的Best和Wrst值可能相差很大。而Avg(平均值)统计了自链路测试以来所有探测的平均值,所以能更好的反应出相应节点的网络质量。而StDev(标准偏差值)越高,则说明数据包在相应节点的延时值越不相同(越离散)。所以标准偏差值可用于协助判断Avg是否真实反应了相应节点的网络质量。例如,如果标准偏差很大,说明数据包的延迟是不确定的。可能某些数据包延迟很小(例如25 ms),而另一些延迟却很大(例如350 ms),但最终得到的平均延迟反而可能是正常的。所以此时Avg并不能很好的反应出实际的网络质量情况。

综上,建议分析标准如下:

  • 如果StDev值很高,则同步观察相应节点的Best和Wrst,来判断相应节点是否存在异常。

  • 如果StDev值不高,则通过Avg来判断相应节点是否存在异常。

    说明

    StDev值或者不高,并没有具体的时间范围标准,而需要根据同一节点其他列的延迟值大小来进行评估。例如,如果Avg为30ms,当StDev为25ms时,则认为是很高的偏差。而如果Avg为325ms,当StDev同样为25ms时,反而认为是不高的偏差。

Loss%(丢包率)

任一节点的Loss%(丢包率)如果不为零,则说明这一跳网络可能存在问题。导致相应节点丢包的原因通常有如下两种:

  • 运营商基于安全或性能需求,人为限制了节点的ICMP发送速率,导致丢包。

  • 节点确实存在异常,导致丢包。

    您可以结合异常节点及其后续节点的丢包情况,来判定丢包原因:

  • 如果随后节点均没有丢包,则通常说明异常节点丢包是由于运营商策略限制所致。可以忽略相关丢包。如前文链路测试结果示例图中的第2跳所示。

  • 如果随后节点也出现丢包,则通常说明异常节点确实存在网络异常,导致丢包。如前文链路测试结果示例图中的第5跳所示。

  • 如果随后节点出现没有丢包的节点和丢包的节点,即相应节点既存在策略限速,又存在网络异常。对于这种情况,如果异常节点及其后续节点连续出现丢包,而且各节点的丢包率不同,则通常以最后几跳的丢包率为准。如前文链路测试结果示例图所示,在第 5、6、7跳均出现了丢包。所以,最终丢包情况,以第7跳的40%作为参考。

延迟

  • 延迟跳变

    如果在某一跳之后延迟陡增,则通常判断该节点存在网络异常。如前文链路测试结果示例图所示,从第5跳之后的后续节点延迟陡增,则推断是第5跳节点出现了网络异常。不过,高延迟并不一定完全意味着相应节点存在异常。如前文链路测试结果示例图所示,第5跳之后,虽然后续节点延迟陡增,但测试数据最终仍然正常到达了目的主机。所以,延迟大也有可能是在数据回包链路中引发的。所以,建议结合反向链路测试一并分析。

  • ICMP限速导致延迟增加

    ICMP策略限速也可能会导致相应节点的延迟陡增,但后续节点通常会恢复正常。如前文链路测试结果示例图所示,第3跳有100%的丢包率,同时延迟也明显陡增。但随后节点的延迟马上恢复了正常。所以判断该节点的延迟陡增及丢包是由于策略限速所致。

常见链路异常场景

说明

常见链路异常场景以Linux操作系统上执行mtr命令为例进行说明,具体结果以您的实际操作系统和工具返回结果为准。

目标主机网络配置不当

如下图所示,数据包在目标地址出现了100%的丢包。初步看是数据包没有到达,其实很有可能是目标服务器相关安全策略,例如防火墙、iptables等禁用了ICMP所致,导致目的主机无法发送任何应答。所以,该场景需要排查目标服务器的安全策略配置。

ICMP限速

如下图所示,数据包在目标地址出现了100%的丢包。初步看是数据包没有到达,其实很有可能是目标服务器相关安全策略,例如防火墙、iptables 、运营商策略等禁用了ICMP所致,导致目的主机无法发送任何应答。所以,该场景需要排查目标服务器的安全策略配置,或结合反向MTR链路测试综合分析。

链路中存在环路

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

链路中断

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

  • 本页导读 (1)
文档反馈