MTU的含义: MAC帧内的数据(Payload)字段的最大长度
我们使用Ping命令时, -l参数所指定的数据包大小, 是指的ICMP报文中的ICMP
Data字段的长度,
不包括ICMP Header,
更不包括IP
Header.
|
首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。
其中以太网（Ethernet）的数据帧在链路层
IP包在网络层
TCP或UDP包在传输层
TCP或UDP中的数据（Data)在应用层
它们的关系是
数据帧｛IP包｛TCP或UDP包｛Data｝｝｝
---------------------------------------------------------------------------------
在应用程序中我们用到的Data的长度最大是多少，直接取决于底层的限制。
我们从下到上分析一下：
1.在链路层，由以太网的物理特性决定了数据帧的长度为（46＋18）－（1500＋18），其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500，即MTU（Maximum
Transmission Unit）为1500；
以太网帧格式：
|
Preamble
7
|
SFD
1
|
Destination
6
|
Source
6
|
Length/
Type 2
|
Data and Pad
46~1500
|
FCS
4
|
格式的说明：
|
字段
|
字段长度（字节）
|
目的
|
|
前导码（Preamble）
|
7
|
同步
|
|
帧开始符（SFD）
|
1
|
标明下一个字节为目的MAC字段
|
|
目的MAC地址
|
6
|
指明帧的接受者
|
|
源MAC地址
|
6
|
指明帧的发送者
|
|
长度（Length）
|
2
|
帧的数据字段的长度（长度或类型）
|
|
类型（Type）
|
2
|
帧中数据的协议类型（长度或类型）
|
|
类型和填充（Data and
Pad）注
|
46~1500
|
高层的数据，通常为3层协议数据单元。对于TCP/IP是IP数据包
|
|
帧校验序列（FCS）
|
4
|
对接收网卡提供判断是否传输错误的一种方法，如果发现错误，丢弃此帧
|
2.在网络层，因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480；
IP数据包格式：
http://s1/middle/49dc9889ge81dbb60fed0&690
3.在传输层，对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472；
所以，在应用层，你的Data最大长度为1472。 （当我们的UDP包中的数据多于MTU(1472)时，发送方的IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议，如果分片丢失导致重组失败，将导致UDP数据包被丢弃）。
从上面的分析来看，在普通的局域网环境下，UDP的数据最大为1472字节最好（避免分片重组）。
但在网络编程中，Internet中的路由器可能有设置成不同的值（小于默认值），Internet上的标准MTU值为576，所以Internet的UDP编程时数据长度最好在576－20－8＝548字节以内。
TCP首部格式
---------------------------------------------------------------------------------
MTU对我们的UDP编程很重要，那如何查看路由的MTU值呢？
对于windows
OS: ping -f -l 如：ping
-f -l 1472 192.168.0.1
如果提示：Packets needs to be fragmented but DF set.
则表明MTU小于1500，不断改小data_length值，可以最终测算出gateway的MTU值；
对于linux
OS: ping -c -M do -s 如： ping -c 1 -M do -s 1472 192.168.0.1
如果提示 Frag needed and DF set……
则表明MTU小于1500，可以再测以推算gateway的MTU。
---------------------------------------------------------------------------------
IP数据包的最大长度是64K字节(65535)，因为在IP包头中用2个字节描述报文长度，2个字节所能表达的最大数字就是65535。
由于IP协议提供为上层协议分割和重组报文的功能，因此传输层协议的数据包长度原则上来说没有限制。实际上限制还是有的，因为IP包的标识字段终究不可能无限长，按照IPv4，好像上限应该是4G(64K*64K)。依靠这种机制，TCP包头中就没有“包长度”字段，而完全依靠IP层去处理分帧。这就是为什么TCP常常被称作一种“流协议”的原因，开发者在使用TCP服务的时候，不必去关心数据包的大小，只需讲SOCKET看作一条数据流的入口，往里面放数据就是了，TCP协议本身会进行拥塞/流量控制。
UDP则与TCP不同，UDP包头内有总长度字段，同样为两个字节，因此UDP数据包的总长度被限制为65535，这样恰好可以放进一个IP包内，使得UDP/IP协议栈的实现非常简单和高效。65535再减去UDP头本身所占据的8个字节，UDP服务中的最大有效载荷长度仅为65527。这个值也就是你在调用getsockopt()时指定SO_MAX_MSG_SIZE所得到返回值，任何使用SOCK_DGRAM属性的socket，一次send的数据都不能超过这个值，否则必然得到一个错误。
那么，IP包提交给下层协议时将会得到怎样的处理呢？这就取决于数据链路层协议了，一般的数据链路层协议都会负责将IP包分割成更小的帧，然后在目的端重组它。在EtherNet上，数据链路帧的大小如以上几位大侠所言。而如果是IP
over
ATM，则IP包将被切分成一个一个的ATM
Cell，大小为53字节。
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~根据RFC894的说明，以太网封装IP数据包的最大长度是1500字节，也就是说以太网最大帧长应该是以太网首部加上1500，再加上7字节的前导同步码和1字节的帧开始定界符，具体就是：7字节前导同步吗＋1字节帧开始定界符＋6字节的目的MAC＋6字节的源MAC＋2字节的帧类型＋1500＋4字节的FCS。
按照上述，最大帧应该是1526字节，但是实际上我们抓包得到的最大帧是1514字节，为什么不是1526字节呢？原因是当数据帧到达网卡时，在物理层上网卡要先去掉前导同步码和帧开始定界符，然后对帧进行CRC检验，如果帧校验和错，就丢弃此帧。如果校验和正确，就判断帧的目的硬件地址是否符合自己的接收条件（目的地址是自己的物理硬件地址、广播地址、可接收的多播硬件地址等），如果符合，就将帧交“设备驱动程序”做进一步处理。这时我们的抓包软件才能抓到数据，因此，抓包软件抓到的是去掉前导同步码、帧开始分界符、FCS之外的数据，其最大值是6＋6＋2＋1500＝1514。
以太网规定，以太网帧数据域部分最小为46字节，也就是以太网帧最小是6＋6＋2＋46＋4＝64。除去4个字节的FCS，因此，抓包时就是60字节。当数据字段的长度小于46字节时，MAC子层就会在数据字段的后面填充以满足数据帧长不小于64字节。由于填充数据是由MAC子层负责，也就是设备驱动程序。不同的抓包程序和设备驱动程序所处的优先层次可能不同，抓包程序的优先级可能比设备驱动程序更高，也就是说，我们的抓包程序可能在设备驱动程序还没有填充不到64字节的帧的时候，抓包程序已经捕获了数据。因此不同的抓包工具抓到的数据帧的大小可能不同。下列是本人分别用wireshark和sniffer抓包的结果，对于TCP
的ACK确认帧的大小一个是54字节，一个是60字节，wireshark抓取时没有填充数据段，sniffer抓取时有填充数据段。
加载中，请稍候......
加载中…
(2011-06-26 12:34:32)