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分片后为什么会造成延迟跟效率低呢？
拖两台电脑，分别设置好地址，然后抓包来看看分片的情况。
