为什么在 ICMPv4 echo ping 请求的数据部分中写了一些东西?
Why is there something written in the data section of an ICMPv4 echo ping request?
(我的问题与 this 不同。)
我已连接到无线网络中的 AP,并且已向 www.google.com。当我在wireshark中分析数据包时,我可以看到,ICMP的数据部分写入了48个字节。在 8 个字节的垃圾值之后,值从 0x10
依次增加到 0x37
。
有什么特别的原因,为什么 ICMPv4 适合值而不是仅仅使用一堆零?
ICMPv4 数据部分的 hexdump:
0030 09 d9 0d 00 00 00 00 00 10 11 12 13 14 15 .Ù............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
8字节垃圾值后
首先,这些不是垃圾值。在ping
的some implementations中,前8个字节可能代表一个时间戳。
如@ross-jacobs 所述,RFC 792 描述了 ICMP Echo Request/Reply 数据包。为了清楚起见,这两个数据包在相关部分描述如下:
回显或回显回复消息
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
...
Description
The data received in the echo message must be returned in the echo
reply message.
这里可以看到Data的内容完全没有描述;因此,实现可以自由使用它希望使用的任何数据,包括 none。
现在,由于 ping
是一个网络测试工具,它可以帮助测试的其中一项是 fragmentation/reassembly。我所知道的每个 ping
实现都允许用户指定有效负载的大小,如果超过 MTU,您应该会看到 ICMP 数据包 fragmented/reassembled。如果检查第一个片段的有效负载,只需查看第一个片段的有效负载中的字节序列,就可以知道第二个片段应该从哪里开始。如果数据全为 0,则无法执行此操作。同样,如果 ICMP 数据包没有正确重组,不仅校验和可能是错误的,而且您很可能能够准确判断重组失败的位置是由于负载中的间隙或其他不一致。这只是为什么具有字节序列而不是全 0 的有效负载对用户更有用的一个示例。
(我的问题与 this 不同。)
我已连接到无线网络中的 AP,并且已向 www.google.com。当我在wireshark中分析数据包时,我可以看到,ICMP的数据部分写入了48个字节。在 8 个字节的垃圾值之后,值从 0x10
依次增加到 0x37
。
有什么特别的原因,为什么 ICMPv4 适合值而不是仅仅使用一堆零?
ICMPv4 数据部分的 hexdump:
0030 09 d9 0d 00 00 00 00 00 10 11 12 13 14 15 .Ù............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
8字节垃圾值后
首先,这些不是垃圾值。在ping
的some implementations中,前8个字节可能代表一个时间戳。
如@ross-jacobs 所述,RFC 792 描述了 ICMP Echo Request/Reply 数据包。为了清楚起见,这两个数据包在相关部分描述如下:
回显或回显回复消息
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+- ... Description The data received in the echo message must be returned in the echo reply message.
这里可以看到Data的内容完全没有描述;因此,实现可以自由使用它希望使用的任何数据,包括 none。
现在,由于 ping
是一个网络测试工具,它可以帮助测试的其中一项是 fragmentation/reassembly。我所知道的每个 ping
实现都允许用户指定有效负载的大小,如果超过 MTU,您应该会看到 ICMP 数据包 fragmented/reassembled。如果检查第一个片段的有效负载,只需查看第一个片段的有效负载中的字节序列,就可以知道第二个片段应该从哪里开始。如果数据全为 0,则无法执行此操作。同样,如果 ICMP 数据包没有正确重组,不仅校验和可能是错误的,而且您很可能能够准确判断重组失败的位置是由于负载中的间隙或其他不一致。这只是为什么具有字节序列而不是全 0 的有效负载对用户更有用的一个示例。