前言

一句话概括，Google DNS 8.8.8.8 会对 Ping 响应数据包长度做截断，在系统上会有不同的结果提示，但 Wireshark 抓包结果会显示 Ping 无响应。
​

163 示例

先以 www.163.com 为例，Windows 默认 Ping ，数据长度 32。

$ ping www.163.com

正在 Ping z163picipv6.v.bsgslb.cn [180.97.232.124] 具有 32 字节的数据:
来自 180.97.232.124 的回复: 字节=32 时间=8ms TTL=53
来自 180.97.232.124 的回复: 字节=32 时间=8ms TTL=53
来自 180.97.232.124 的回复: 字节=32 时间=8ms TTL=53
来自 180.97.232.124 的回复: 字节=32 时间=8ms TTL=53

180.97.232.124 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 8ms，最长 = 8ms，平均 = 8ms
    

​
Windows Ping 数据长度 1472，抓包结果显示总长度为 1514 ，ETH 14 + IP 20 + ICMP 1480（8+1472） = 1514，正好满足 MTU 1500 。

$ ping -l 1472 www.163.com

正在 Ping z163picipv6.v.bsgslb.cn [180.97.232.124] 具有 1472 字节的数据:
来自 180.97.232.124 的回复: 字节=1472 时间=9ms TTL=53
来自 180.97.232.124 的回复: 字节=1472 时间=9ms TTL=53
来自 180.97.232.124 的回复: 字节=1472 时间=8ms TTL=53

180.97.232.124 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 8ms，最长 = 9ms，平均 = 8ms
    

Windows Ping 字节长度 1473，因超过最大 MTU ， IP 产生分片，但 Ping 结果仍是正常。

$ ping -l 1473 www.163.com

正在 Ping z163picipv6.v.bsgslb.cn [180.97.232.125] 具有 1473 字节的数据:
来自 180.97.232.125 的回复: 字节=1473 时间=7ms TTL=53
来自 180.97.232.125 的回复: 字节=1473 时间=7ms TTL=53
来自 180.97.232.125 的回复: 字节=1473 时间=7ms TTL=53

180.97.232.125 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 7ms，最长 = 7ms，平均 = 7ms

可以看到 Ping request 3 个包，分片成 6 个数据包，同样 reply 3 个包，也由于分片变成 6 个数据包。

Google 示例

Google DNS 8.8.8.8，Windows 默认 Ping ，数据长度 32。

$ ping 8.8.8.8

正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=35ms TTL=114
来自 8.8.8.8 的回复: 字节=32 时间=35ms TTL=114
来自 8.8.8.8 的回复: 字节=32 时间=36ms TTL=114
来自 8.8.8.8 的回复: 字节=32 时间=36ms TTL=114

8.8.8.8 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 35ms，最长 = 36ms，平均 = 35ms

Google DNS 8.8.8.8，Windows Ping 数据长度 68 和 69 。注意不同之处，Ping 69 在系统上会显示为 字节=68 (已发送 69) ，结果仍是 Ping 成功。

$ ping -l 68 8.8.8.8

正在 Ping 8.8.8.8 具有 68 字节的数据:
来自 8.8.8.8 的回复: 字节=68 时间=65ms TTL=49
来自 8.8.8.8 的回复: 字节=68 时间=64ms TTL=49
来自 8.8.8.8 的回复: 字节=68 时间=64ms TTL=49

8.8.8.8 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 64ms，最长 = 65ms，平均 = 64ms



$ ping -l 69 8.8.8.8

正在 Ping 8.8.8.8 具有 69 字节的数据:
来自 8.8.8.8 的回复: 字节=68 (已发送 69) 时间=64ms TTL=49
来自 8.8.8.8 的回复: 字节=68 (已发送 69) 时间=64ms TTL=49
来自 8.8.8.8 的回复: 字节=68 (已发送 69) 时间=64ms TTL=49
来自 8.8.8.8 的回复: 字节=68 (已发送 69) 时间=64ms TTL=49

8.8.8.8 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 64ms，最长 = 64ms，平均 = 64ms

​
Wireshark 实际抓包结果如下图

Windows Ping 数据长度 69 ，ICMP Request 数据包长度仍是 111（14+20+8+69），但是 Google DNS 8.8.8.8 会将 Ping ICMP Reply 数据长度截断为 68，使得整个数据包长度变为了 110。

由于在 RFC 792 中针对 Echo or Echo Reply Message 定义说明了以下两点：

The data received in the echo message must be returned in the echo reply message.
The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests.

因为 Echo reply 数据长度 68 与 Echo request 数据长度 69 不一致，因此在 Wireshark 中会遵循 RFC ，从而显示 no response found! 信息，而在 Windows 系统（ macOS 系统类似）的判断逻辑会因为 id 和 seq num 相同，再加上部分长度数据匹配，从而认为是对应的一组 echo request 和 echo reply ，所以显示为 Ping 成功，并会友情提示 字节=68 (已发送 69) 。
​

继续 Google DNS 8.8.8.8，Windows Ping 数据长度 1472 和 1473 。

$ ping -l 1472 8.8.8.8

正在 Ping 8.8.8.8 具有 1472 字节的数据:
来自 8.8.8.8 的回复: 字节=68 (已发送 1472) 时间=35ms TTL=114
来自 8.8.8.8 的回复: 字节=68 (已发送 1472) 时间=35ms TTL=114
来自 8.8.8.8 的回复: 字节=68 (已发送 1472) 时间=36ms TTL=114

8.8.8.8 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 35ms，最长 = 36ms，平均 = 35ms



$ ping -l 1473 8.8.8.8

正在 Ping 8.8.8.8 具有 1473 字节的数据:
请求超时。
请求超时。
请求超时。

8.8.8.8 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 0，丢失 = 3 (100% 丢失)，

​
Wireshark 实际抓包结果如下图

虽然都是 no response found! ，但是 Ping 1472 和 1473 完全是不一样的含义。1472 如上述分析是因为 Echo reply 长度截断，系统里仍是显示 Ping 成功，而 1473 是因为超过了最大 MTU，产生了 IP 分片，由于 Google 安全防护种种缘故，阻断了相关报文，因此并不会有 Echo reply 消息返回，所以是真正的 Ping 不通。

总结

各种奇奇怪怪的 Ping 结果，考虑到不同的客户端、服务器、Ping 程序以及抓包工具等等，需结合实际环境，具体分析。