在前文中，我们提到，IPv4 元信息包的一个部分为IP分片提供了支持，在本节中，我们详细论述 IP 分片

IP 分片：根本的原因是链路层（硬件）的限制

在前文中，我们提到，我们的 IP 依托与链路层而生，那么自然，它也受制于链路层具体指标（实际上就是硬件的限制，因为链路层属于一种硬件的协议）的限制。

在这里，我们仅仅考虑 MTU 这个指标，它表示在一段链路上面，一个数据包可以具有的最大尺寸（长度）。

我们要看到的是，MTU 会伴随着硬件的改变而改变，并不存在一个明确的答案。

反映到我们的网络层数据包上面，便意味着，我们一次性可以发送的数据，往往可能会因为超出了硬件的限制，而出现“尺寸过大"的错误。

解决的策略：分片

在 IPv4 中，我们提供的解决方案，便是“具体问题、具体分析、精兵简政、分批传输"，换而言之，将一个较大的数据包，分解为一个个小数据包，再传输到目标地址之后，再进行组装。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vqhLGuG4-1683591976749)(foruda.gitee.com/images/1677… “1677494716918.png”)]

而分解出小数据包的方法，就是从大的数据包中，选取一个部分，构建小数据包，由此就形成了“数据偏移"（截取了大数据包哪一部分的数据）与“数据标识"（表示小数据包的顺序）。

而在实际的应用中，我们往往还需要一些“运行时"的信息，由此得知，这是一个“独立的数据包"还是“分片"。

由此就带来了“分片标志"，它是“具体问题具体分析"的生动写照，表示分片传输的状态。

分片标志也为我们工作的开展提供了依据。

走向 IPv6：用小包传输代替传统分片

在具体的实践中，IPv4 的分片方案尽管工作得很好，但也出现了一些问题：

IPv4 方案中展现的问题

首先，我们要看到的是，我们的 IPv4 分片策略是：只要经过的硬件需要分片，就由当地硬件再次进行打乱重组。

这就往往要损失效率，同时由于数据包不断重组，往往也会大大提升出错的可能性。

同时，我们要看到的事情是，在 IPv4 方案之中，当我们的数据分片出现遗失的时候，我们并不会选择像 TCP 那样做重传工作，而是直接丢弃与之相关的所有数据包，这也大大加重了传输失败的负担。

以及，我们要注意到，还有一部分硬件，并不支持分片工作，它们也带来了不小的挑战。

IPv6 的解决之道

IPv6 传输协议的设计团队，看到了 IPv4 方案中的不足，它们决心全力解决这些问题，于是它们做了如下的调整：

第一步：找到传输链路中最小的 MTU（PMTU）

首先，在进行数据传输之前，我们将进行如下的动作：

• 发送一个较大尺寸的数据包
• 如果出现“尺寸过大"的错误，则减小尺寸，重复第一步，反之结束
• 最后留下的尺寸，就是这条链路上一次性可以传输的最大尺寸（至少是接近）

这种做法，被称为“PMTU"，它是一项实用的做法。

第二步：在本地主机进行拆包

在我们得到 PMTU 之后，便会在本地主机上完成“拆包"工作，再进行传输。

因为这些小数据包的数据量小于链路中任何链路的 MTU，因此中间不会再发生其它的分片行为。

最后一步：目标主机组装

目标主机会根据拓展头中保留的分片信息对小数据包进行组合。