网络基本功（十四）：细说诊断工具ping

时间 2019-11-07

原文原文链接

网络基本功（十四）：细说诊断工具pingphp

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese 网络

介绍

ping的工做原理很简单，一台网络设备发送请求等待另外一网络设备的回复，并记录下发送时间。接收到回复以后，就能够计算报文传输时间了。只要接收到回复就表示链接是正常的。耗费的时间喻示了路径长度。重复请求响应的一致性也代表了链接质量的可靠性。所以，ping回答了两个基本的问题：是否有链接？链接的质量如何？本文主要讨论这两个问题。ide

更多信息

正常的ping操做主要是两个特定的ICMP消息，ECHO_REQUEST和ECHO_REPLY。理论上，全部TCP/IP网络设备都应当经过返回报文来响应ECHO_REQUEST，但实际上并不老是如此。工具

ping的解析:性能

大多数操做系统版本，会一直发送ECHO_REQUESTs，直到中断为止。例如：测试

bsd1# ping www.bay.comurl

PING www.bay.com (204.80.244.66): 56 data bytesspa

64 bytes from 204.80.244.66: icmp_seq=0 ttl=112 time=180.974 ms操作系统

64 bytes from 204.80.244.66: icmp_seq=1 ttl=112 time=189.810 msblog

64 bytes from 204.80.244.66: icmp_seq=2 ttl=112 time=167.653 ms

--- www.bay.com ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 167.653/179.479/189.810/9.107 ms

bsd1#

这一过程被Ctrl-C中断，此时打印出汇总统计。

上述结果中，针对每个报文的回复给出了报文大小，来源，ICMP sequence number，TTL值，以及往返时间。其中，sequence number和往返时间对于评估基本链接情况来讲是最有用的信息。

当发送一个ECHO_REQUEST时，将发送时间记录在报文里，并复制到远端主机相应的ECHO_REPLY报文中。当接收到ECHO_REPLY时，经过比较当前时间与报文时间计算出耗费时间。若是没有收到符合该sequence number的报文，则认为该报文丢失。耗费时间长短以及变化范围取决于中间链路数量，速度，以及链路拥塞状况。

什么值是合理的呢？这一值高度取决于网络以及网络质量。若是是在LAN网络环境下，响应时间仍是很快的，一般在十几毫秒范围以内。若是链接到外网则该值会显著增长。若是是远程站点，可能会耗时上百毫秒。

你也能够用ping来粗略计算链接的吞吐量。在外网上发送两个不一样大小的报文，经过-s选项来完成。时间长度的差异会反映大报文中额外数据所耗费的时间。例如，假设ping 100字节耗费30ms而ping 1100字节耗费60ms，所以，往返额外花费30ms单程额外花费15ms，多发送1000字节或8000比特。吞吐量近似为每15ms 8000比特或540，000bps。两个测量值之间的差别用来扣除开销。固然这一估算是很是粗略的，没有考虑到路径上其余数据流的状况，也没有考虑路径上全部链路的状况。

TTL貌似能够估算一条路径上的跳数，可是这有一些问题。当发送报文时，TTL字段先被初始化接着通过路径上每一个路由器都要递减。若是达到0，报文就被丢弃了。从而对全部报文生命周期有必定限制。于是在路由回环的过程当中，报文不会无期限存在于网络上。不幸的是，TTL字段可能会，也可能不会被远端设备重置，若是重置，也没有一致性。所以，要使用TTL字段估算路径中的跳数须要知道详细的系统信息。

一般一串稳定的回复意味着健康的链接。若是报文丢失或丢弃，能够在sequence number中看到跳数，以及丢失报文的编号。偶尔丢失一个报文不表示真的有什么问题。特别是跨越多台路由器或拥塞网络时。一个序列中的一个报文丢失或耗费明显更长时间是很正常的，这是由于路径中各条链路需对第一个报文作ARP解析。在ARP数据保存以后，后续报文就不会有这种开销。可是，若是丢失报文比例较大，则有可能路径上有问题。

某些状况下会收到ICMP错误消息。一般来自路由器，这里面包含颇有用的信息。例如，下例中，设备尝试访问一个不存在的网络上的设备：

bsd1# ping 172.16.4.1

PING 172.16.4.1 (172.16.4.1): 56 data bytes

36 bytes from 172.16.2.1: Destination Host Unreachable

Vr HL TOS Len ID Flg off TTL Pro cks Src Dst

4 5 00 5400 5031 0 0000 fe 01 0e49 172.16.2.13 172.16.4.1

36 bytes from 172.16.2.1: Destination Host Unreachable

Vr HL TOS Len ID Flg off TTL Pro cks Src Dst

4 5 00 5400 5034 0 0000 fe 01 0e46 172.16.2.13 172.16.4.1

--- 172.16.4.1 ping statistics ---

2 packets transmitted, 0 packets received, 100% packet loss

因为路由器没有到达该网络的路径，因此返回ICMP DESTINATION_HOST_UNREACHABLE信息。一般若是问题发生在运行ping命令的设备上，则会收到Destination Host Unreachable告警或 Destination Network Unreachable告警。若是问题发生在转发报文的设备上，则只会收到一条Destination Host Unreachable。

下例中，尝试向一台已配置拒绝从源设备接收数据流的路由器发送数据：

bsd1# ping 172.16.3.10

PING 172.16.3.10 (172.16.3.10): 56 data bytes

36 bytes from 172.16.2.1: Communication prohibited by filter

Vr HL TOS Len ID Flg off TTL Pro cks Src Dst

4 5 00 5400 5618 0 0000 ff 01 0859 172.16.2.13 172.16.3.10

36 bytes from 172.16.2.1: Communication prohibited by filter

Vr HL TOS Len ID Flg off TTL Pro cks Src Dst

4 5 00 5400 561b 0 0000 ff 01 0856 172.16.2.13 172.16.3.10

--- 172.16.3.10 ping statistics ---

2 packets transmitted, 0 packets received, 100% packet loss

被过滤条件阻止的告警信息代表报文被丢弃。但也有可能过滤条件不显示该告警。

下例中，

bsd1# ping 172.16.3.10

PING 172.16.3.10 (172.16.3.10): 56 data bytes

--- 172.16.3.10 ping statistics ---

6 packets transmitted, 0 packets received, 100% packet loss

路由器上使用一样的过滤条件，但应用于离开网络的数据流，而不做用于inbound数据流。所以，没有消息发送。这时，ping就没法告诉你为何报文没有收到回复。

ping的选项:

一些选项控制发送报文的速率和数量，-c选项容许用户指定发送报文的数量。例如，ping –c10会发送10个报文而后中止。这一命令在脚本中颇有用处。

命令-f和-l用于将报文泛洪到网络上。-f选项代表报文发送速率与接收主机可以处理速率相同。这一参数可用于链路压力测试或接口性能比较。

-l选项用于计数，尽量快的发送该数量报文，而后恢复正常。该命令用于测试处理泛洪的能力，须要root权限执行。

-i选项用于用户在两个连续报文之间指定等待秒数。该命令对于将报文间隔开或用在脚本中很是有用。正常状况下，偶然的ping包对数据流的影响是很小的。但重复报文或报文泛洪影响就很大了。所以，使用以上选项时需谨慎。

-n选项将输出限制为数字形式，这在遇见DNS问题时颇有用。-v显示更详尽输出，较少输出为-q和-Q。

-s选项指定发送数据的大小。但若是设置的过小，小于8，则报文中就没有空间留给时间戳了。设置报文大小能诊断有路径MTU(Maximum Transmission Unit)设置或分段而致使的问题。若是不使用该选项，ping默认是64字节