Wireshark 分析ping报文

wireshark 分析ping报文

使用ping命令来获取wwww.baidu.com网站的ICPM报文,其结果如下图:

这里写图片描述

可以看到,我们生成了8个报文(4个请求报文和4个应答报文),下面我们来分析第一个报文,首先,请求报文如下:

这里写图片描述

对于该报文的整个描述如下:

这里写图片描述

这个请求报文共74字节,其中:

前14个字节是以太网报文的一部分(由于网卡不会将其整个以太网帧格式数据提供出来,因此Wireshark只能捕捉到一部分以太网的数据),分别为本机的MAC地址和路由器的MAC地址:

这里写图片描述

由上图可知,其MAC地址的第一字节的最后两个bit位:IG位(individual/group,第7个bit位)为0表示这是一个单播MAC地址(unicast MAC address),LG位(local/global,第8个bit位)为0表示这是一个厂家出厂默认的MAC地址,为1时表示这是用户自己设置的MAC地址。

紧接着源MAC地址和目标MAC地址的是以太网封装的数据格式类型,这里的值为0x0800,表示就接下来的数据是IPV4报文的数据。

接下来的20个字节为IP报文:

这里写图片描述

这里写图片描述

关于ip报文的格式如下:

这里写图片描述

其中,ip报文中的第一个字节为01000101,前1/2个字节(即0100)表示版本号(为4),接下来的1/2字节为5,表示报文长度为5(此值表示长度为5个32位的位数,即5*32/8=20个字节),关于版本和头部字节长度的解释如下:

Version

Version: Identifies the version of IP used to generate the datagram.For IPv4, this is of course the number 4. The purpose of this field is to ensure compatibility between devices that may be running different versions of IP. In general, a device running an older version of IP will reject datagrams created by newer implementations, under the assumption that the older version may not be able to interpret the newer datagram correctly.

Internet Header Length (IHL)

Internet Header Length (IHL): Specifies the length of the IP header,in 32-bit words. This includes the length of any options fields and padding. The normal value of this field when no options are used is 5 (5 32-bit words = 5*4 = 20 bytes). Contrast to the longer Total Length field below.

再往下,ip报文的第二个字节为服务类型(Type of Service ,TOS)其值为00000000,服务类型字段声明了数据报被网络系统传输时可以被怎样处理。可以全为0,若全为0则表示一般服务。该字段并没有如初始定义被广泛使用,大部分主机会忽略这个字段。关于该字段的解释如下:

Type Of Service (TOS)

Type Of Service (TOS): A field designed to carry information to provide quality of service features, such as prioritized delivery, for IP datagrams. It was never widely used as originally defined, and its meaning has been subsequently redefined for use by a technique called Differentiated Services (DS). See below for more information.

第三,四个字节为003c,表示总长度为60字节,即整个数据报的长度,最大长度为65535字节。关于其解释:

Total Length (TL)

Total Length (TL): Specifies the total length of the IP datagram, in bytes. Since this field is 16 bits wide, the maximum length of an IP datagram is 65,535 bytes, though most are much smaller.

第5,6字节为0x4506,用来唯一地标识主机发送的每一份数据报。IP软件在存储器中维持一个计数器,每产生一个数据段,计数器就加1,并将此值赋给标识字段。但这个“标识”并不是序号,因为IP是无连接服务,数据报不存在按序接收的问题,当数据报由于长度,超过网络的MTU而必须分片时,这个标识字段的值就被复制到所有的数据报的标识字段中。相同的标识字段的值使分片后各数据报片最后能正确的重装成为原来的数据报。关于其解释:

Identification

Identification: This field contains a 16-bit value that is common to each of the fragments belonging to a particular message; for datagrams originally sent unfragmented it is still filled in, so it can be used if the datagram must be fragmented by a router during delivery. This field is used by the recipient to reassemble messages without accidentally mixing fragments from different messages. This is needed because fragments may arrive from multiple messages mixed together, since IP datagrams can be received out of order from any device. See the discussion of IP message fragmentation.

第7字节为0x00,目前只有前3位有意义,其解释:

这里写图片描述

第8字节为片偏移,其值为0,片偏移指出较长的分组在分片后,某片在原分组的相对位置。关于片偏移的解释:

Fragment Offset

Fragment Offset: When fragmentation of a message occurs, this field specifies the offset, or position, in the overall message where the data in this fragment goes. It is specified in units of 8 bytes (64 bits). The first fragment has an offset of 0. Again, see the discussion of fragmentation for a description of how the field is used.

第9个字节值为128,表示生存期,用来设置数据报最多可以经过的路由器数。关于其解释:

Time To Live (TTL)

Time To Live (TTL): Short version: Specifies how long the datagram is allowed to “live” on the network, in terms of router hops. Each router decrements the value of the TTL field (reduces it by one) prior to transmitting it. If the TTL field drops to zero, the datagram is assumed to have taken too long a route and is discarded.

第10个字节为0x01,表示IP层所封装的上层协议类型,如ICMP(1)、IGMP(2) 、TCP(6)、UDP(17)。解释如下:

这里写图片描述

第11,12个字段为0xe351,表示头部校验和,其根据头部中每个16比特进行二进制反码求和。其解释如下:

Header Checksum

Header Checksum: A checksum computed over the header to provide basic protection against corruption in transmission. This is not the more complex CRC code typically used by data link layer technologies such as Ethernet; it’s just a 16-bit checksum. It is calculated by dividing the header bytes into words (a word is two bytes) and then adding them together. The data is not checksummed, only the header. At each hop the device receiving the datagram does the same checksum calculation and on a mismatch, discards the datagram as damaged.

下面来讲解校验和的计算,其计算是将校验和的16bit位置0,将整个IP头部字段按照16bit位来相加,如果有进位,则将其进位放在16bit位的最小位,最后将加的结果取反即为校验和,其规则与下面的类似:

4500 -> 0100010100000000
003c -> 0000000000111100
453C -> 0100010100111100 /// First result

453C -> 0100010100111100 // First result plus next 16-bit word.
1c46 -> 0001110001000110
6182 -> 0110000110000010 // Second result.

6182 -> 0110000110000010 // Second result plus next 16-bit word.
4000 -> 0100000000000000
A182 -> 1010000110000010 // Third result.

A182 -> 1010000110000010 // Third result plus next 16-bit word.
4006 -> 0100000000000110
E188 -> 1110000110001000 // Fourth result.

E188 -> 1110000110001000 // Fourth result plus next 16-bit word.
AC10 -> 1010110000010000
18D98 -> 11000110110011000 // One odd bit (carry), add that odd bit to the result as we need to keep the checksum in 16 bits.

18D98 -> 11000110110011000(注意这里的进位规则)
8D99 -> 1000110110011001 // Fifth result

8D99 -> 1000110110011001 // Fifth result plus next 16-bit word.
0A63 -> 0000101001100011
97FC -> 1001011111111100 // Sixth result

97FC -> 1001011111111100 // Sixth result plus next 16-bit word.
AC10 -> 1010110000010000
1440C -> 10100010000001100 // Again a carry, so we add it (as done before)

1440C -> 10100010000001100
440D -> 0100010000001101 // This is seventh result

440D -> 0100010000001101 //Seventh result plus next 16-bit word
0A0C -> 0000101000001100
4E19 -> 0100111000011001 // Final result.

最后取反即可,我们可按照这个规则来计算校验和(上例展示了校验和的计算技巧,这里就没有针对本报文做演示计算过程了)。

接下来的13,14,15,16和17,18,19,20字节分别表示源IP地址(c0 a8 01 08,192.168.1.8)和目标IP地址(77 4b d9 6d,119.75.217.109),解释如下:

Source Address&Destination Address

Source Address: The 32-bit IP address of the originator of the datagram. Note that even though intermediate devices such as routers may handle the datagram, they do not normally put their address into this field—it is always the device that originally sent the datagram.

Destination Address: The 32-bit IP address of the intended recipient of the datagram. Again, even though devices such as routers may be the intermediate targets of the datagram, this field is always for the ultimate destination.

以上为IP报文头部的20个字节的解释,下面便是IP报文的数据段了,也就是ICMP报文了,如下:

这里写图片描述

这里写图片描述

其中第一个字节08表示类型,其表示Echo Request,关于该字段的解释:

Type

Type: Identifies the ICMP message type. For ICMPv6, values from 0 to 127 are error messages and values 128 to 255 are informational messages. Common values for this field are given in the table in the topic on ICMP message classes and types.

第二个字节为0,表示Code,关于其解释:

Code

Code: Identifies the “subtype” of message within each ICMP message Type value. Thus, up to 256 “subtypes” can be defined for each message type. Values for this field are shown in the individual ICMP message type topics.

接下来的第3,4字节(0x4d56)表示检验和,其解释如下:

Checksum: 16-bit checksum field that is calculated in a manner similar to the IP header checksum in IPv4. It provides error detection coverage for the entire ICMP message. Note that in ICMPv6, a pseudo-header of IPv6 header fields is prepended for checksum calculation; this is similar to the way this is done in TCP.

接下来的第5,6字节(0x0001)和第7,8字节(0x0005)分别表示标识码和序列码。

接着后面的32字节我们发送的数据,可以看到其数据为abcdefghijklmnopqrstuvwabcdefghi。

返回报文同理可分析。

*注:本文的引用部分来自*The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference by Charles M. Kozierok

猜你喜欢

转载自blog.csdn.net/u010999240/article/details/52969384