当客户端访问目标服务器出现ping丢包或ping不通时，可以通过tracert或mtr等工具进行链路测试来判断问题根源。本文主要介绍如何通过工具进行链路测试和分析。
阿里云提醒您：
- 如果您对实例或数据有修改、变更等风险操作，务必注意实例的容灾、容错能力，确保数据安全。
- 如果您对实例（包括但不限于ECS、RDS）等进行配置与数据修改，建议提前创建快照或开启RDS日志备份等功能。
- 如果您在阿里云平台授权或者提交过登录账号、密码等安全信息，建议您及时修改。
使用ping命令丢包或者网络不通时，可参见以下操作步骤进行链路测试并进行处理，想了解链路测试中所使用工具的更多介绍请参见更多信息。
-
- 场景一：目标主机网络配置不当
- 场景二：ICMP限速
- 场景三：环路
- 场景四：链路中断
通常情况下，链路测试步骤如下：
步骤一：获取本地网络对应的公网IP
在客户端本地网络内访问淘宝IP地址库，获取本地网络对应的公网IP地址。
步骤二：正向链路测试（ping和mtr）
从客户端向目标服务器做以下测试：
- 从客户端向目标服务器域名或IP做持续的ping测试，建议至少ping 100个数据包，记录测试结果。
- 根据客户端操作系统的不同，使用WinMTR或mtr，设置测试目的地址为目标服务器域名或IP，然后进行链路测试，记录测试结果。
步骤三：反向链路测试（ping和mtr）
进入目标服务器系统内部做以下测试：
- 从目标服务器向获取的客户端IP做持续的ping测试，建议至少ping 100个数据包，记录测试结果。
- 根据目标服务器操作系统的不同，使用WinMTR或mtr，设置测试目的地址为客户端的IP地址，然后进行链路测试，记录测试结果。
步骤四：测试结果分析
参见，对测试结果进行分析。确认异常节点后，访问如下链接或其他可以查询IP归属地的网站，获取该异常节点的归属运营商信息。如果是客户端本地网络相关节点出现异常，则需要对本地网络进行相应排查分析。如果是运营商相关节点出现异常，则需要向运营商反馈问题。查询结果类似如下。
由于mtr（WinMTR）有更高的准确性，本文以其测试结果为例，参见以下要点进行分析。此处分析时以如下示例图为基础。
要点一：网络区域
正常情况下，从客户端到目标服务器的整个链路中会包含以下网络区域：
- 客户端本地网络：即本地局域网和本地网络提供商网络。如上图中的区域A。如果该区域出现异常，并且是客户端本地网络中的节点出现异常，则需要对本地网络进行相应的排查分析。如果是本地网络提供商网络出现异常，则需要向当地运营商反馈问题。
- 运营商骨干网络：如上图中的区域B。如果该区域出现异常，可以根据异常节点的IP查询其所属的运营商，直接向对应运营商进行反馈，或者通过，向运营商进行反馈。
- 目标服务器本地网络：即目标服务器所属提供商的网络。如上图中的区域C。如果该区域出现异常，需要向目标服务器所属的网络运营商反馈问题。
要点二：链路负载均衡
如上图中的区域D。如果中间链路某些部分启用了链路负载均衡，则mtr只会对首尾节点进行编号和探测统计。中间节点只会显示相应的IP或域名信息。
要点三：结合Avg（平均值）和StDev（标准偏差）综合判断
由于链路抖动或其它因素的影响，节点的Best和Worst值可能相差很大。Avg统计了自链路测试以来所有探测的平均值，所以能更好的反应出相应节点的网络质量。而StDev越高，则说明数据包在相应节点的延时值越不相同，即越离散。所以标准偏差值可用于协助判断Avg是否真实反应了相应节点的网络质量。例如，如果标准偏差很大，说明数据包的延迟是不确定的。可能某些数据包延迟很小，例如25ms，而另一些延迟却很大，例如350ms，但最终得到的平均延迟反而可能是正常的。所以，此时Avg并不能很好的反应出实际的网络质量情况。
综上所属，建议的分析标准如下：
- 如果StDev很高，则同步观察相应节点的Best和Worst，来判断相应节点是否存在异常。
-
如果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%的丢包率，同时延迟也明显陡增。但随后节点的延迟马上恢复了正常。所以判断该节点的延迟陡增及丢包是由于策略限速所致。
- 当出现ping丢包或ping不通时，首先请参考云服务器ECS网络故障诊断，排查是否为网络故障。
- 如果确认是因系统中病毒导致使用ping命令测试ECS实例的IP地址间歇性丢包，则可参考使用ping命令测试ECS实例的IP地址间歇性丢包进行处理。
- 如果是因删除ECS实例的默认安全组规则导致无法ping通ECS实例，可参考删除ECS实例的默认安全组规则导致无法ping通ECS实例进行处理。
- 如果在Linux系统内核没有禁PING的情况下，是因系统内部防火墙策略设置导致ECS服务器PING不通。可参考Linux系统的ECS中没有禁PING却PING不通的解决方法。
常见的链路异常场景及测试报告如下：
场景一：目标主机网络配置不当
示例数据如下。
