MTU和Fragment详解

1. 基础知识

我们知道, 数据在网络上传输时, 要经过一段一段的链路。当数据从某一段链路的一端传到另一端的过程中, 需要考虑的是数据链路层协议, 在这一层, 我们观察到的数据包(PDU: Packet Data Unit)称为MAC帧(MAC Frame), 不同的数据链路层协议, MAC Frame的格式也不同, 但大致都会有目标MAC地址、源MAC地址、长度/类型、数据(有效载荷: Payload)这几个字段。 对以太网而言, 采用的是数据链路层协议是基于IEEE 802.2/802.3, 但与IEEE 802.2/802.3略有区别.

查一下802.3协议中MAC帧格式部分, 就会发现上面提到的MAC帧中的数据(有效)字段的长度范围是46-1500个字节. 那么, 当链路层的上一层－IP层所要传输的IP数据包(包括IP Header)大小超过这个长度范围时, IP数据包就必须分成多片传输, 这个过程就是分片(Fragmentating), 其中分割出来的每一个片断就是一个Fragment.

2. MTU与Fragment

上述链路层这种对超过其协议定义的最大数据字段长度时就进行分片的特性, 就称为MTU(Maximum Transmission Unit). 不同链路层协议, MTU值也不同, 我们已经知道, 对以太网, MTU是1500字节, 而对令牌环(Token Ring)网, MTU是4482字节.

3. IP数据包中与分片相关的字段

IP数据包在封装时, 在IP头的第8-9个字节(16bit)中, 存放关于分片的信息. 其中前3个bit表示分片的状态, 后13个bit表示当前片断在分片之前的整块待封装的数据包中的偏移量(因为IP数据包的最大可能长度为16bit, 而这13bit无法表示16bit的范围, 故实际使用时, 偏移量的计算是用这13bit的值乘8(3bit), 以实现表示16bit的范围).

3.1 不分片标记(Don't Fragment Flag)

IP头第8-9字节从左往右的第2bit表示当前IP数据包是(1)否(0)不分片, 缺省值为0, 就是不不分片, 即允许分片. 因为默认允许分片, 所以我们平常使用Ping命令时, 加参数-l 65500 Ping一台机器也不会有问题.

'

3.2 是否有后续分片标记(More Fragments Flag)

IP头第8-9字节从左往右的第3bit表示当前数据包里的数据是否为某块数据的最后一个分片, 若为0, 则说明当前数据包内的数据没有分片或者是最后一个分片, 若为1, 则表示后面还有属于同一块数据的分片.

4. 说了半天感觉太抽象, 我们来些看得见摸得着的东西.

4.1 用Ping测试MTU(在以太网环境中)开个命令行窗口, 输入命令:

ping 192.168.0.1 -l 2000 -f

出现提示:

Pinging 192.168.0.1 with 2000 bytes of data:

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

也就是在将IP头里的"Don't Fragment Flag"位设置为1, 也就是不允许分片, 但是我们又用Ping命令的-l参数指定了发送的数据包的大小为2000字节, 显然超过了以太网的MTU-1500字节. 所以数据包不能通过, 并且返回了上述错误信息: 数据包需要分片但是DF(Don't Fragment)标记被设置了.

再输入命令:

ping 192.168.0.1 -l 1500 -f

Pinging 192.168.0.1 with 1500 bytes of data

Packet needs to be fragmented but DF set

lPacket needs to be fragmented but DF set

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

奇怪, 已经把发送数据包的大小改为MTU值1500, 怎么还不能通过?

减小参数值, 重输命令:

ping 192.168.0.1 -l 1400 -f

Pinging 192.168.0.1 with 1400 bytes of data:

Reply from 192.168.0.1: bytes=1400 time<10ms TTL=128

Reply from 192.168.0.1: bytes=1400 time<10ms TTL=128

Reply from 192.168.0.1: bytes=1400 time<10ms TTL=128

Reply from 192.168.0.1: bytes=1400 time<10ms TTL=128

好, 这次可以通过了.

反复调整参数值, 看看可以通过的最大Ping命令-l 参数值是多少. 经过反复试验, 最后发现, 最大可以通过的Ping命令的-l参数的数值是1472. 这个1472是和预期的MTU值1500差了28个字节. 这28个字节是怎么来的呢?

4.2 协议分层封装

我们知道, 在MAC帧的数据(Payload)字段, 封装(存放)的是上层(IP层)的IP数据包, 而IP数据包的格式是IP Header + IP Data(Payload). 在我们用Ping命令的这个例子中, IP数据包内的IP Data字段内封装的是ICMP协议数据.

我们来回顾一下MTU的含义: MAC帧内的数据(Payload)字段的最大长度, 也就是说它所封装的IP Header + IP Data两者长度之和最大为1500字节, 而IP Header的最小长度为20字节, 所以IP Data的最大长度就是1500-20=1480字节, 离我们试验的1472字节已经比较接近了.

再查查ICMP协议数据的具体格式, 发现在Ping命令用到的ICMP Echo Request/Replay报文中, 在ICMP Data之前, 有几个字段共占用了8个字节, 分别为: Type(1byte), Code(1byte), Checksum(2byte), Identifier(2byte), Sequence Number(2byte), 这几个字段我们可以称之为ICMP Header. 好了, 1480-8=1472, 和我们的试验结果对上了.

可以发现, 我们使用Ping命令时, -l参数所指定的数据包大小, 是指的ICMP报文中的ICMP Data字段的长度, 不包括ICMP Header, 更不包括IP Header.