通过ICMP来分析MTU
ping -l 1472 -f -n 1.1.1.1指定了ping的数据长度为1472字节,其中的-f参数禁用了数据分段,可以看到第一次ping通了; 但是,第二次ping的时候指定数据长度为1473字节,却没有ping通,而且提示“packet needs to be fragmented but DF set”。什么意思呢? 第三次ping时把-f参数去掉了,此时ping通了!这时为什么却又通了呢? 通过抓包来分析。下图的1、2帧是第一次ping时产生的,而3-6帧是第三次ping时产生的。 现在就来对比分析一下第一次ping的数据包、第二次ping的数据、第三次ping的数据包到底有何差异? 从上图的帧1中我们可以清晰的看到,第一次ping的时候数据包刚好达到了1500字节,即该数据包已经达到了MTU的大小。而在第二次ping时却失败了,是因为在网络层的控制信息中设置了“不分段”比特位,并且这个包达到了1501字节(20字节的IP报头控制信息+8字节的ICMP控制信息+1473字节的数据=1501字节),该大小已经超过了MTU的大小,必需要分段后才能传输,可此时却设置了“不要分段”,因此这个数据包无法发送,也就导致第二次ping的失败和那个报错信息! 在帧3中,IP数据包也刚好为1500字节,可以看到IPv4负载着的是1480字节的Data(其实1480字节里包含了8字节的ICMP控制信息)。并且在IP报头中标明了“还有更多的段”,这意味着数据被分段了,后面的帧4里还有相关的数据。 Data里面前8个字节其实就是ICMP控制信息,只有从这8个字节以后才是ICMP的有效载荷。Windows系统发出的ping包里面不就是abc……uvw这23个字母的循环,对吗? 在帧4中,IP数据包共21字节,减去IP报头的20字节,只剩下1字节,但是你可能会有疑问,这里不还显示着ICMP控制信息吗,应该还有8字节才对啊?但实际上,帧3和帧4共用同一个ICMP控制信息,准确的说,应该是在帧3中就有ICMP控制信息,这个控制信息包含着帧3和帧4里的数据,数据不是分开来了吗?所以,这仅仅是抓包软件在解码时的一个显示让人感觉看着有点懵而已。 看帧4里的ICMP数据,被重组为1473字节了。并且可以和帧3的ICMP控制信息对比一下,是不是一模一样? |
-
ICMP_1.png (9.06 KB)