最大传输单元(Maximum Transmission Unit,MTU)是指一种通信协议的某一层上面所能通过的最大数据报大小(以字节为单位)。最大传输单元这个参数通常与通信接口有关(网络接口卡、串口等)。
Internet协议允许IP分片,这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。这一分片过程发生在IP层(OSI模型的第三层,即网络层),它使用的是将分组发送到链路上的网络接口的最大传输单元的值。原始分组的分片都被加上了标记,这样目的主机的IP层就能将分组重组成原始的数据报了。
展开索引
何为MTU,MTU的定义:
最大传输单元(Maximum Transmission Unit,MTU)是指一种通信协议的某一层上面所能通过的最大数据报大小(以字节为单位)。最大传输单元这个参数通常与通信接口有关(网络接口卡、串口等)。
Internet协议允许IP分片,这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。这一分片过程发生在IP层(OSI模型的第三层,即网络层),它使用的是将分组发送到链路上的网络接口的最大传输单元的值。原始分组的分片都被加上了标记,这样目的主机的IP层就能将分组重组成原始的数据报了。
在Internet协议中,一条因特网传输路径的“路径最大传输单元”被定义为从源地址到目的地址所经过“路径”上的所有IP跳的最大传输单元的最小值。或者从另外一个角度来看,就是无需进一步分片就能穿过这条“路径”的最大传输单元的最大值。
RFC 1191描述了“路径最大传输单元发现方法”,这是一种确定两个IP主机之间路径最大传输单元的技术,其目的是为了避免IP分片。在这项技术中,源地址将数据报的DF(Don’t Fragment,不要分片)位置位,再逐渐增大发送的数据报的大小——路径上任何需要将分组进行分片的设备都会将这种数据报丢弃并返回一个“数据报过大”的ICMP响应到源地址——这样,源主机就“学习”到了不用进行分片就能通过这条路径的最大的最大传输单元了。
然而当前越来越多的网络封杀了ICMP的传输(譬如说为了防范DDOS攻击)——这使得路径最大传输单元发现方法不能正常工作,其常见表现就是一个连接在低数据流量的情况下可以正常工作,但一旦有大量数据同时发送,就会立即挂起(例如在使用IRC的时候,客户会发现在发送了一个禁止IP欺骗的ping之后就得不到任何响应了,这是因为该连接被大量的欢迎消息堵塞了)。而且,在一个使用因特网协议的网络中,从源地址到目的地址的“路径”常常会为了响应各种各样的事件(负载均衡、拥塞、断电等等)而被动态地修改——这可能导致路径最大传输单元在传输过程中发生改变——有时甚至是反复的改变。其结果是,在主机寻找新的可以安全工作的最大传输单元的同时,更多的分组被丢失掉了。
对于时下大多数使用以太网的局域网来说,最大传输单元的值是1500字节。但是像PPPoE这样的系统会减小这个数值,这就使得在使用最大传输单元发现方法时可能会产生这样的结果:一些处于配置不当的防火墙之后的站点变得不可达了。对于这种情况,还是可能找到变通的方法的,但这取决于你控制的是网络的哪一部分。这些方法包括改变用来在防火墙一端建立TCP连接的第一个分组的MSS(Maximum Segment Size,最大分段大小)。
MTU属于网络模型中的哪层?
从下面这个表格中可以看到,在7层网络协议中,MTU是数据链路层的概念。MTU限制的是数据链路层的payload,也就是上层协议的大小,例如IP,ICMP等。
OSI中的层 | 功能 | TCP/IP协议族 |
---|---|---|
应用层 | 文件传输,电子邮件,文件服务,虚拟终端 | TFTP,HTTP,SNMP,FTP,SMTP,DNS,Telnet |
表示层 | 数据格式化,代码转换,数据加密 | 没有协议 |
会话层 | 解除或建立与别的接点的联系 | 没有协议 |
传输层 | 提供端对端的接口 | TCP,UDP |
网络层 | 为数据包选择路由 | IP,ICMP,RIP,OSPF,BGP,IGMP |
数据链路层 | 传输有地址的帧以及错误检测功能 | SLIP,CSLIP,PPP,ARP,RARP,MTU |
物理层 | 以二进制数据形式在物理媒体上传输数据 | ISO2110,IEEE802,IEEE802.2 |
MTU有什么用?
举一个最简单的场景,你在家用自己的笔记本上网,用的是路由器,路由器连接电信网络,然后访问了www.baidu.com
,从你的笔记本出发的一个以太网数据帧总共经过了以下路径:
笔记本 -> 路由器 -> 电信机房 -> 服务器
其中,每个节点都有一个MTU值,如下:
1500 1500 1500
笔记本 -> 路由器 -> 电信机房 -> 服务器
假设现在我把笔记本的MTU最大值设置成了1700,然后发送了一个超大的ip数据包(2000),这时候在以外网传输的时候会被拆成2个包,一个1700,一个300,然后加上头信息进行传输。
1700 1500 1500
笔记本 -> 路由器 -> 电信机房 -> 服务器
路由器接收到了一个1700的帧,发现大于自己设置的最大值:1500,如果IP包DF标志位为1,也就是不允许分包,那么路由器直接就把这个包丢弃了,根本就不会到达电信机房,也就到不了服务器了,所以,到这里我们就会发现,MTU其实就是在每一个节点的管控值,只要是大于这个值的数据帧,要么选择分片,要么直接丢弃。
为啥是1500呢?其实一个标准的以太网数据帧大小是:1518
,头信息有14字节,尾部校验和FCS占了4字节,所以真正留给上层协议传输数据的大小就是:1518 – 14 – 4 = 1500,那么,1518这个值又是从哪里来的呢?
如果取一个更大的值会咋样?假设MTU值和IP数据包大小一致,一个IP数据包的大小是:65535,那么加上以太网帧头和为,一个以太网帧的大小就是:65535 + 14 + 4 = 65553
,看起来似乎很完美,发送方也不需要拆包,接收方也不需要重组。
那么假设我们现在的带宽是:100Mbps
,因为以太网帧是传输中的最小可识别单元,再往下就是0101所对应的光信号了,所以我们的一条带宽同时只能发送一个以太网帧。如果同时发送多个,那么对端就无法重组成一个以太网帧了,在100Mbps
的带宽中(假设中间没有损耗),我们计算一下发送这一帧需要的时间:
( 65553 * 8 ) / ( 100 * 1024 * 1024 ) ≈ 0.005(s)
在100M网络下传输一帧就需要5ms,也就是说这5ms其他进程发送不了任何数据。如果是早先的电话拨号,网速只有2M的情况下:
( 65553 * 8 ) / ( 2 * 1024 * 1024 ) ≈ 0.100(s)
100ms,这简直是噩梦。其实这就像红绿灯,时间要设置合理,交替通行,不然同一个方向如果一直是绿灯,那么另一个方向就要堵成翔了。
既然大了不行,那设置小一点可以么?假设MTU值设置为100,那么单个帧传输的时间,在2Mbps带宽下需要:
( 100 * 8 ) / ( 2 * 1024 * 1024 ) * 1000 ≈ 5(ms)
时间上已经能接受了,问题在于,不管MTU设置为多少,以太网头帧尾大小是固定的,都是14 + 4,所以在MTU为100的时候,一个以太网帧的传输效率为:
( 100 - 14 - 4 ) / 100 = 82%
写成公式就是:( T - 14 - 4 ) / T
,当T趋于无穷大的时候,效率接近100%
,也就是MTU的值越大,传输效率最高,但是基于上一点传输时间的问题,来个折中的选择吧,既然头加尾是18,那就凑个整来个1500,总大小就是1518,传输效率:
1500 / 1518 = 98.8%
100Mbps传输时间:
( 1518 * 8 ) / ( 100 * 1024 * 1024 ) * 1000 = 0.11(ms)
2Mbps传输时间:
( 1518 * 8 ) / ( 2 * 1024 * 1024 ) * 1000 = 5.79(ms)
总体上时间都还能接受
为什么是64呢?这个其实和以太网帧在半双工下的碰撞有关,感兴趣的同学可以自行去搜索。
分片与分段有啥区别?
分片是IP层的概念。检查IP分片的标志是检查IP层头部的Flag字段里的df bit和more fragment位。检查是否分片和有否后续的分片报文。
同时在IP层包头的最后有个字段为ip fragments会详细写明分片的帧数及长度。(由此可以判断我们发送出去没有进行IP分片)
分段是TCP层的概念。此时将会用到MSS。在本例中,我们选用1460做为MSS。根据协商的结果动态产生。现象就是在每个(除第一个)SMTP
消息的Body报文中,都会看到每一个的TCP净载数据大小为1460。通过发给对方的第一个TCP的SYN报文里的option字段会携带MMS字段通知对方自己所使用的MSS。而对方会在对SYN的回应中返回自己的MMS字段。这样,双方协商成功。发送方根据收到的ACK里含有的对方MMS大小与本机比较选取较小值进行MMS进行分段。
由于此时我们的MSS小于接口的MTU。所以我们选用1460做为TCP负载的分片大小。加上20字节的IP包头和20字节的TCP头部。总共为1500 字节。如果此时,超过接口MTU 1500的话,仍然将进行分片。但此时没超。刚好等于。所以我们没有进行分片。
MTU故障与解决方法案例:
案例1:
MTU引起的网络故障,网络架构如下:
VPN客户端使用win2003的RRAS做为VPN拔号客户端,进行远程拔号连接,Client网络中,USER通过RRAS路由,与VPN Server进行数据传输,Web浏览与Mail,FTP下载都很正常,两边网络(VPN Client与VPN Server)中都有路由器与防火墙;
现在,需要在VPN Client端的网络中,安装一台FTP Server,从VPN Server端上传数据,但总是不成功,传输文件很小时如4KB以下时成功,但稍微大点都显示不成功,当传输到几KB之后就会出现TIME OUT错误提示;
故障排除步骤:
- Mail,FTP下载,WEB浏览等一切正常,证明网络连接与设备一切正常;
- 当在WIN2003上安装好FTP Server做测试时,发现FTP上传正常,但USER在网络中通过RRAS再路由时,上传就失败;
- 当Ping远程VPN Server时,MTU数据包大小只能为1370,当大于此值时就会Fragment,如ping -f -l 1400 192.168.5.1,就会出现Packet needs to be fragmented but DF set,这与两端防火墙的MTU设置和ISP允许的最大值有关,而Win2003与XP默认的MTU值大小为1500,所以,更改win2003上默认的MTU值大小为网络允许的最大值之后,FTP上传正常。
案例2:
部分网络可以访问,部分无法访问,使用omnipeek监测网络状况,发现数据包都很小(594),检查mtu值的设置,发现很小(貌似病毒引起),修改mtu后一切正常。
如何在Windows系统中修改MTU,详细步骤:
- 运行regedit.exe,
- 找到以下路径:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\在Interfaces下面会列出系统所有的网卡;
- 找到物理上正在工作的网卡,查看IP地址等值来确定需要更改的网卡,然后在选择的网卡下面,新建dword值,命名为:MTU,双击输入十进制值;
- 重启;
- ***在Linux系统中修MTU步骤:直接运行 ifconfig 修改MTU,如:ifconfig eth0 mtu 1370;
(END)