您的Ping命令真的用对了吗？

在对以太网网络上的通信问题进行故障排除时，Ping命令是最广泛使用的诊断工具之一。这种受欢迎程度是因为每个人都知道如何使用命令，执行起来非常简单。

在对通信问题进行故障排除时，我们在无法正常工作时听到的最常见的一句话是“但我可以ping通”，就好像这一点应该作为确切的证据，证明一切都按预期工作，通信服务器选择不通信。

本文介绍了一些关于Ping命令的常见误解，特别是如何有效地使用它，什么时候它可能不是任务的最佳工具，以及Ping的更好的替代方案（提供实际上可操作的数据）。

什么是Ping命令？

在命令提示符下键入ping 1.1.1.1会发生什么？

Ping旨在告诉用户主机是否可以在IP网络上访问，并通过发送ICMP（Inte.NET控制消息协议）回应请求来执行此操作，远程主机（我们正在ping的IP地址）将在收到时回显。

虽然这无疑是有用的，但Ping命令在它告诉我们的内容中也非常有限，因为ICMP位于IP协议之上（毕竟它是Internet控制消息协议）并且不需要像TCP或UDP这样的传输协议。

为什么这很重要？

在Internet协议描述主机之间的通信的地方，传输协议（如TCP或UDP）描述了在这些主机上运行的进程之间的通信。如果没有传输层，Ping命令将永远无法向我们提供有关远程主机的信息：

正在监听连接
有一个开放的接口
将接受我们流程的连接
甚至是我们想要与之沟通的合适主机
Ping命令只会告诉我们主机响应指定IP地址的echo请求。 因此，Ping命令的缺点可以概括为命令根本没有给我们足够的信息来巧妙地得出控制器或网络节点不通信的原因。那么，Ping命令的哪些替代方案在这种情况下值得考虑？

什么是Tracert命令？

Tracert命令在很大程度上起到与Ping命令相同的作用，并且只应用于确定在指定的IP地址处是否存在响应的内容，仅此而已。

如果您正在ping同一子网上的设备，则Tracert和Ping将执行完全相同的操作。当ping不在同一子网或网络上的主机时，会发现Tracert的强大功能，因为它不仅会显示终端设备是否响应，还会显示到达该远程主机的路由路径。

如果Tracert在路径中的任何特定点发生故障，则很容易识别通信中断的特定位置。 Tracert通过发送与ping相同的ICMP Echo请求来完成此操作，但它使用“Time To Live”字段来控制消息可以跳转的距离。第一个数据包以TTL为1发送，路径中的第一个跳转将减少为0，并以“Time to live exceeded in transit/运行中的超时时间”响应，这有助于我们的机器现在知道第一个跳转的IP地址路由路径。

然后以TTL为2发送第二个回应请求，以便消息可以在超时之前到达路径中的第二跳。然后是3的TTL，4的TTL，依此类推，直到我们得到Echo响应，并且我们知道'ping'数据包已经到达我们试图到达的目标节点。

就像ping一样，Tracert结果告诉我们在远程主机上是否有运行的应用程序/固件/通信模块能够与我们通信 - 只是远程主机支持IP并且可以访问。

因此，我们现在已经确定，在许多情况下，Ping和Tracert命令在解决通信问题的有效性方面基本相同。我们还能尝试什么？

什么是Portqry实用程序？

如果Ping命令没有给我们任何可操作的数据，并且Tracert命令没有给我们任何可操作的数据， 我们如何得到一些我们可以用来确定设备是否正在监听连接以及通信问题可能是什么是？这个问题将我们带到PortQryUI--一个可从Microsoft下载的实用工具。

虽然它没有预先安装windows，但PortQryUI是一个非常轻量级的实用程序，不仅可用于识别主机是否可访问，还可用于确定在该主机上运行的进程是否可访问和/或是否愿意接受连接。

知道1.1.1.1是DNS服务器，正如我们之前建立的那样，让我们​​针对DNS端口53运行Portqry。 我们可以看到，首先，Portqry尝试在使用TCP和UDP查询端口之前将IP地址解析为DNS主机名（在此处成功完成 - “one.one.one.one”），并且因为实用程序知道53是DNS端口，它也向端口发送DNS查询。

Portqry有三种可能的结果：

正在监听 - 该实用程序得到了端口的积极回应
不监听 - 该实用程序收到了端口的回复，告诉我们要离开
已过滤 - 该实用程序未收到来自端口的任何响应，无论是正面还是负面
现在让我们在实验室中使用本地Modbus PLC进行尝试，我们知道这可以通过端口502（默认的Modbus端口）看到连接请求。

这次我扫描一系列端口502-503，仍然要求检查TCP和UDP。 结果并不令人惊讶; 主机名称解析失败，因为它只是一个PLC（虽然它没有超出PLC分配DNS名称的可能性的范围，大多数不是），并且查询结果确实显示有一个进程在端口502上侦听传入的TCP连接。

现在，显然，我们实验室中的Modbus PLC没有任何通信问题。但是，您现在可以想象，当Portqry实用程序以“Not Listening”或“Filtered”响应端口和传输时，对于无响应的设备有多么有用，我们希望在正常通信情况下能够得到肯定的响应。

但是，如果我们从Portqry得到积极响应但仍然没有成功通信，我们还能做些什么呢？

什么是Netstat？

虽然Netstat命令不提供远程设备接受连接的能力的信息，或者远程主机是否可以在网络上访问，但在查看本地计算机上的套接字状态时，它是非常宝贵的资源。 运行简单的netstat枚举本地套接字信息，显示本地和远程地址，套接字状态以及与该主题关联的进程ID（在想要跟踪哪个应用程序正在使用端口时特别有用）。在对PLC的连接问题进行故障排除时，套接字状态将是最有用的列，因为它可以深入了解发生问题的连接顺序。过滤后（使用FIND）可以轻松过滤任何关键字的Netstat列表; 包括IP地址和端口：
在解释Socket状态时，至少在一般情况下 - 理解TCP状态图以查看错误发生在连接序列中的哪个位置。毫无疑问，这是有用的，只是触及netstat能够表达的表面，建议运行netstat /？查看所有可用选项。

什么是Wireshark？

如果所有其他方法都失败了，并且上面的工具显示一切都应该工作，那么Wireshark就是我们的首选诊断工具。Wireshark将捕获网卡上的所有流量，并将向我们显示目标设备与我们的计算机之间究竟发生了什么。
因此，虽然Ping命令肯定有其作为一个非常基本的故障排除工具，但它不应该被误认为是一个完成所有工作的工具。