有了这些信息，我们可以说网络的稳定性如何？

网络工程 平
2021-07-26 18:56:03

在使用 ping 测试网络稳定性时，请求在每次回复的 MAX-TIME-TO-WAIT 之前超时。

我注意到在 500 毫秒之前超时的行。

COMMAND>ping google.com -n 20 -w 500

Pinging google.com [<google-ip>] with 32 bytes of data: 
Reply from <google-ip>: bytes=32 time=21ms TTL=55 
Reply from <google-ip>: bytes=32 time=13ms TTL=55 
Reply from <google-ip>: bytes=32 time=18ms TTL=55 
Reply from <google-ip>: bytes=32 time=16ms TTL=55 
Reply from <google-ip>: bytes=32 time=10ms TTL=55 
Reply from <google-ip>: bytes=32 time=17ms TTL=55 
Reply from <google-ip>: bytes=32 time=20ms TTL=55 
Request timed out. 
Request timed out. 
Reply from <google-ip>: bytes=32 time=117ms TTL=55
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.      <---***timed out before 500ms***
Request timed out.
Request timed out. 
Reply from <google-ip>: bytes=32 time=453ms TTL=55 
Reply from <google-ip>: bytes=32 time=23ms TTL=55

Ping statistics for <my-ip-addr>:
    Packets: Sent = 20, Received = 10, Lost = 10 (50% loss), 
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 453ms, Average = 70ms

感谢您对@YLearn 的编辑，很抱歉，这是本论坛上的第一个问题。关于IP地址，我错误地全部替换了（使用<*.*.*.*>）。关于超时，我敏锐地观察了它们，我确信它们都发生在眨眼之间，这不应该发生，因为 -w 设置为 500 毫秒，这是人为注意到的。关于使用 ping 测试外部网络稳定性的观点。现在，我的困惑是导致请求在 500 毫秒之前超时的原因。路径中靠近目的地的路由器是否有某种机制可以将数据包丢失通知源，从而导致超时？

2个回答

我们可以说，丢包率为 50% 的网络根本就不稳定，至少还不够稳定以支持健康的互联网使用。如果您的链接是无线的，这仍然是一个无法接受的高损耗。如果您只使用以太网电缆，那么您就远远超出了有线以太网可接受的正常范围。

简而言之：您的网络不稳定。

我可以从你粘贴的内容中推断出什么？您在远非理想条件下使用 WiFi 网络。如果您使用的是电缆，则您的开关出现故障（可能是其电源过滤部分中的电容器有故障 - 干涸？）或者您的连接器生锈了。这可能是由带有故障变压器的网卡引起的（这种情况下的另一个症状是网卡连接图标在 Windows 上不断出现和消失 - “网络电缆已拔出”消息或类似的东西）。对于以太网标准，您的网络电缆可能运行时间过长，但在这种情况下，这是您的错。

顺便说一句，你问了一个工具来检查这个。你知道 traceroute/tracert 命令吗？

有了这些信息，我们可以说网络的稳定性如何？

由于您使用的是您控制的网络之外的资源作为 ICMP 回显目标，因此您只能说您的连接可能不稳定。您需要进行额外的测试，可能还需要使用 ping 以外的工具来做出真正的决定。

ICMP ping 只是一个可靠的工具，用于确定您控制并知道它如何处理 ICMP 的网络中的不稳定连接。当你离开你的网络时，唯一可以可靠地使用它的方法是表明连接是稳定的（即良好的结果表明连接稳定）。

虽然像上面这样的输出可能表示连接不稳定，但也可能是正常操作的结果。

像上面这样使用时，ICMP 不能可靠地识别不稳定连接的原因是，ICMP 回送/回复消息通常被赋予较低的优先级或速率限制，从而产生额外的延迟或丢弃的消息。从历史上看，ICMP 已被用于许多不同的攻击，这导致许多提供商实施此类措施。

这通常最常发生在 ping 的目的地，但也可能发生在到达目的地的路径上的任何地方，具体取决于设备的配置方式。

这些限制或规则可能基于通过该设备（来自任何来源）的所有 ICMP 的总量，也可能基于来自单个主机的流量（或两者）。他们还可以使用许多其他因素，例如您的主机在之前某个时间段内发送的 ICMP 流量总量、您的主机发送的 ICMP 流量的不同目的地的数量等。

在此示例中，ICMP 流量看起来相当低，并且在不将 ICMP 流量与其他流量合并考虑时，理想情况下不会遇到此类问题。但是，同一主机可能会通过多种方式发送比提供的单个 ping 输出更多的 ICMP 流量，这可能会导致它超出限制：

  1. 您正在运行 ping 的主机也在您知情或不知情的情况下从其他窗口或进程运行其他 ping。
  2. 如果您的主机位于执行 NAT 的网络设备后面，则网络上的其他主机也可能正在发送 ICMP 流量。在这种情况下，所有流量似乎都来自单个主机。
  3. 您的 ISP 可能正在实施某种形式的运营商级 NAT (CGN)，这意味着他们的许多客户可以位于单个 IP 之后。来自该 IP 的所有 ICMP 流量都将被互联网上的其他设备视为一台主机。

无论如何，我确实知道 Google 确实限制了到达其服务器的 ICMP 流量，这可能会导致使用 ICMP 到 Google 服务器监视其 Internet 链接的人误报（我至少在三个不同的位置看到过这种情况）以我个人的经验）。

路径中靠近目的地的路由器是否有某种机制可以将数据包丢失通知源，从而导致超时？

并不真地。在此过程中，您可以从路由器获得响应，但这些响应将导致除“请求超时”之外的其他消息。例如，您可能会收到“目标无法访问”消息作为响应。

其它你可能感兴趣的问题
上一篇Cisco ASA 5505 - VPN 无法访问某些网络 下一篇HP 2920-48G PoE 菊花链 ARP 缓存问题