有没有好奇过路由器宽带拨号mtu值为什么是1492呢？了解MTU与分片

小编：迷魂冰更新时间：2022-08-21

作者：一天首发公众号：网络之路博客（ID：NetworkBlog）

MTU与IP分片（可选内容了解）

这里来讲一个比较有趣的内容，相信大家都有设置过家用路由器的经历，不知道有没有发现一个事情，在设置拨号的时候，里面有一个MTU，值通常是1492或者1480，如果接入方式改为DHCP的情况下，MTU就变成了1500，为什么呢？

（1）了解MTU的作用

Maximum Transmission Unit（MTU）：最大传输单元。还是以上面的例子，为什么路由器拨号的时候要把MTU设置成1492呢？在这之前已经知道了以太网头部，一个标准的以太网数据帧最大为1518，其中源MAC 6字节，目的MAC 6个字节，Type 2个字节，FCS 4个字节（前导码不算在内，在物理层就已经去掉了），6+6+2+4=18个字节，1518-18=1500，这1500正好是是留给上层协议传输的大小，也就是我们说的数据帧的大小是1500个字节，包括IP头部以及上层协议与数据整体在内，也就是说在二层以太网中，实际能传输的数据是1500个字节。

举一个最常见的例子，我们平时在家里用手机或者笔记本连接家用路由器看电视剧、刷抖音，数据包都是这样的路径，每个节点都有对应的MTU值，正常都为1500.

假设某一天，外网的对接方式变了，变成了拨号的形式，正常设置后，发现打开网页很慢或者打不开，咨询路由器客服后，把MTU值改成1492或者更小点，惊奇的事情发生了，都能正常访问了，这就回到之前的问题了，为什么现在的路由器MTU都会设置成1492呢？

那是因为宽带拨号使用的协议是PPPoE，由于还没涉及这一块的知识点，我们在这知道它占用8个字节就行，并且是封装在以太网中的。比如访问者发送了一个1495字节的数据包给视频服务器，但是由于家用路由器采用的是这就在原来1500的字节上多出来了8个字节，超过了标准的MTU值1500字节，所以这个时候家用路由器会将这个数据包进行分片，分为2个，一个为数据包为1500个字节，另外一个数据包为3个字节，到了服务器这边在进行重组。（实际会更加复杂点，待会我们来做个小实验）

（2）IP分片带来的问题

IP分片其实在网络中是一种比较糟糕的情况，带来了几个问题

传输效率降低：分片会降低传输效率（这个待会我们用简单的实验可以看到）
增加设备的压力：原本一个数据包大小正好在1500字节的范围内，直接就发送了，如果超过了1500个字节，就需要涉及到分片，如果这种数据包一多，对应的设备压力就会增大，占用设备的资源。
延迟加大：分片另外一个问题就是当同一个数据包的多个分片抵达目的地后，目的终端需要将数据包重组排列后才能够去读取里面的内容。好比一个大的物件被拆分成多个小的物件发送出去，接收后，需要进行重新组装，更糟糕的是万一某一个组件晚到，那么其他到了的组件就得等待；在IP分片重组中也是这样的，所以会导致延迟加大。
丢包：更严重的是，在复杂的网络环境中，万一某一个分片丢失了，那其余接收到的数据就没任何意义了，组不成一个完整的数据包，从而被丢弃。
某些应用访问失效：比如上面的网页打开失败或者很慢就是因为分片造成的，有的服务器有保护措施，拒绝接收分片的数据包。

（3）为什么MTU是1500呢，明明IP字段的总长度是65535？

之前学过IP头部的内容，IP头部里面有一个总长度，最大值是65535，表示IP协议是能够承载这么大数据包的，但是由于以太网的数据部分最大为1500，所以你在很多书籍或者称呼里面会看到IP的数据包最大是1500个字节，多了就会被分片，那为什么以太网要把数据部分定在1500，不能跟IP头部一样用65535吗？那效率不是高很多。

以太网最小字节为什么要求是64呢？

最早的以太网是工作在共享网络下的，任何一个终端节点发送数据之前，都需要侦听线路上是否有数据在传，如果有，需要等待，如果发现线路可用，才可以发送。假设A与B终端同时传输1个bit给对方的话，会产生冲突，其中一个就需要等待一端发送完成后在过一个时间间隙才能发送，这个时间间隙是57.6μs。

在10Mbps的以太网中，在57.6μs时间内，能够传输576个bit，以太网中要求数据帧最小长度为576个bit，原因是这个长度正好能够让最极端的冲突环境都能够被检测到（CSMA/CD），而576个bit换算成字节是72，去掉8个字节的前导符，正好是64个字节，这也是以太网帧数据部分要求的最小长46的原因（46+18），不够46的会自动填充。

MTU值为什么是1500

这个是了解64字节的由来，是因为早期工作方式的原因（CSMA/CD），那1500字节又是什么原因呢？

假设以太网没有这个限制，IP协议最大可以承载65535字节，加上以太网头部和尾部，是65535+14+4=65553字节，如果早期在10Mbps的以太网上传输，会占用共享链路50ms,这样严重影响了其他主机的通信，如果有延迟敏感的应用，那肯定是无法接收的，另外如果线路的质量差，大包引起的丢包几率也会大很多。（50ms的计算方法：（65553*8）/（10*1024*1024）≈0.05（s）（小知识点科普：Mbps为每秒传输百万位比特，而65535是字节单位，1字节=8比特，所以需要*8，10Mbps换算成bps就是10*1024*1024））

竟然大的不行，换成小的呢？，比如MTU等于100，就拿上面学过的ICMP的Ping来说，如果以太网长度为100，ICMP实际数据= 100-ICMP头部（8个字节）-IP头部（20个字节）-以太网头部（18个字节）=100-8-20-18=54，你会发现有效率实在太低了，有效率=54/100=54%

最终得到一个通过层层计算，发现如果以太网长度为1518的时候，有效传输效率=1472/1518=96.9%，这个值既能保证有一个较大的帧长度，又保证了有效传效率。更大的或者更小的就会出现上述的问题，这个也是一个折中的长度：1518字节，对应上层IP 就是1500字节（1518-18），这个就是最大传输单元MTU的由来。

为什么不改善这个问题呢？

出现这个问题是因为早期以太网通过Hub这些设备工作，处于共享方式，效率很低，而现在的网络早已不是10M的网络了，交换机已经支持1G，10G、100G，而且带宽独享，可以同时收发的特性，那有效传输效率跟质量提升了非常多，但是如今的网络你会发现常见的还是用的mtu 1500的标准，只有数据中心或者某些特殊环境使用了一个叫做巨型帧 Jumbo Frame，可以支持大于9000字节的大小，如果全网都使用这种，那传输大的文件这些不是更快、延迟很小吗？

但是现实环境没这么简单，因为MTU在每个设备的每一个接口（网卡）上面都是存在的

如果访问者支持MTU 9000，发送了一个9000大小的数据包交给无线路由器，无线路由正好也支持这么大，交给互联网设备，互联网中设备非常多，并不是所有设备都能够去支持巨型帧的特性，很多地方还使用的非常老的设备在运行，如果要支持势必是大面积更换，成本会非常大，那如果一个数据包9000大小经过一个MTU是标准1500的设备，那势必就会造成分片了，还有许多比如超长帧会造成延时、CRC错误变多等问题，导致至今无法大面积普及使用的主要原因。

（4）IP分片后为什么会造成延迟跟效率低呢？

拖两台电脑，分别设置好地址，然后抓包来看看分片的情况。

说下命令，Ping 192.168.255.2这个都能够知道啥意思，-l表示ICMP的数据部分（不含其它任何头部信息）为1473，-c 1只发送一次。

通过抓包，可以看到有几个信息（wireshark升级了下，界面看起来更美观了~）

ARP：这个是获取对方IP对应的MAC
ICMP，这个是正常的ICMP协议的报文
IP Fragmented：IP分片包

有IP分片包出现，说明刚刚的数据包整体超过1500个字节了。

数据明明是1473怎么就超过1500字节了呢？

这里要注意，1473表明的是ICMP数据部分的大小，不计算头部在内，那么加上头部后呢？ 1473+8（ICMP头部）+20（IP头部）=1501，这样正好超过了1500个字节，所以导致分片了。MTU是二层概念，二层以上的头部加数据不能超过1500，否则会进行分片。

从192.168.255.1到192.168.255.2为什么只有一个分片包

这里对于刚接触抓包的朋友来说，可能有点看不懂，我们来看几个参数

IP头部里面有一个identification 这个是标识符，分片的包会打上相同的包，方便目的端区分
Flags里面的MF位是1，表示这个不是最后一个包，如果是最后一个包会为0
offset：偏移符，表示数据包的位置，这个为0，表示是第一个分片包
Data：你这里会发现数据是1480，并且是没有ICMP头部的（这个内容其实是包含了头部信息的，1480-8，1472，注意：只有第一个分片会携带头部信息，抓包没有显示出来）。

那还有1个字节的包在抓包里面没有显示，这可能是抓包中把尾包省略了，但是可以从另外一个地方看出来。

在看一个完整的包可以上面的疑惑了

IP头部里面有一个identification 这个是标识符，分片的包会打上相同的包，方便目的端区分
抓包软件里面有一个IPV4 Fragments的组合解析，发现有两个分片，Frame：3，数据负载是0~1479（1480个字节），Frame：4，数据负载是1480-1481（1个字节），总共就是1481
DATA部分为1473，是因为1481里面有8个字节的头部，1481-8=1473个字节

为什么会影响效率跟增加延迟呢？

可能数据包小，感受不到分片带来的问题，上图数据大小改成了5000，会发现4个分片（最后一个是隐藏了），那就会多出4个IP头部，这些是无故多出来的数据，并且这4个头部不管是中间设备还是接收方都需要去解封装来看是什么内容，并且接收方根据IP头部的分片给的信息去组装，假设某一个分片中途延迟，那么这个数据包就不会完整，必须等待这片来组装后才能读取到实际的内容，这种会影响效率（多余的头部处理），增加延迟（某一个分片没到，对应的数据没法重组，导致数据请求迟迟得不到响应。）更严重的其实是会加重设备的负担（可能实际中不只一个数据包分片，接收方需要把收到的进行缓存，等待所有对应的分片来才能读取到实际的数据，随着分片越多，缓存越大，对于设备的压力负担也越重），如果某一片分配丢失了，会造成这个数据包不完整，被丢弃。

（5）怎么设置合适的MTU呢

由于现在很多协议还没学习，不同的应用对应的头部不一样，自然包含的内容也不一样，这个会随着后面学习的深入，慢慢的了解，设置合适的MTU可以用Windows自带的命令可以探测，比如某个应用有问题，通过抓包发现发送的数据超过了MTU的大小，就可以适当的调整。