前言

一句话概括，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

DNS-01

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 个数据包。
DNS-02

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 实际抓包结果如下图
DNS-03

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 定义说明了以下两点：

因为 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 实际抓包结果如下图
DNS-04

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