为什么ip分片必须是8字节的倍数
在计算机网络 James F.Kurose 第五版教科书中，第 4 章提到
ip 片段必须是 8 字节的倍数，并且因为 IP 中的 Flags header 占用 3 位。我不明白为什么 ip 碎片必须是 8 字节的倍数。
In the text book Computer Networking James F.Kurose Fifth Ed, ch4 mentioned
the ip fragments must be in multiples of 8 bytes, and because the Flags in the IP header takes 3 bits. I don't understand why ip fragmentation must be in multiples of 8 bytes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
除最后一个片段外，每个片段都必须包含 8 字节数据的倍数。
片段偏移量可以容纳 8192 (2^13) 个单位，但数据报不能有 8192 * 8 = 65536 字节的数据，因为 IP 标头的“总长度”字段记录了包括标头和数据在内的总大小。
IP 标头至少有 20 个字节长，因此“片段偏移”的最大值限制为 8189，这为最后一个片段留出了 3 个字节的空间。
希望这有帮助。
Every fragment except the last must contain a multiple of 8 bytes of data.
Fragment Offset can hold 8192 (2^13) units but the datagram can't have 8192 * 8 = 65536 bytes of data because "Total Length" field of IP header records the total size including the header and data.
An IP header is at least 20 bytes long, so the maximum value for "Fragment Offset" is restricted to 8189, which leaves room for 3 bytes in the last fragment.
Hope this helps.
我没有从这里的其他答案中获得太多好处。他们似乎只是顺便触及真正的问题，同时试图解释他们看到的另一个问题，所以这里是真正的答案：
消息长度字段中的位数与片段字段中的位数不同。
消息长度字段测量整个消息，跨越该消息的所有片段
当发送大数据包时，它会被分成多个片段，因此您需要标记片段并跟踪该片段中的消息部分，并将其放入当所有碎片到达时恢复顺序。您将获得 13 位来描述片段序列。 长度是一个16位整数，因此其容量（16位）为
2^16 - 1=65536-1=65535。这为您提供了 65535 个不同的字节，因此 IP 消息的长度最多为 65535 个字节。片段偏移量是字节的度量，但无法容纳消息中的字节数
理想情况下，我们希望以与长度相同的单位来测量片段，即字节。
但我们只有 13 位用于 Fragment！
他们希望以字节为单位保存片段偏移量，因此必须想办法将 16 位装入 13 位。他们发明了一种奇怪的位映射来为他们做到这一点：奇怪的
位映射
他们意识到，数字每减少 1 位，就可以表示其最大数字（例如，通过去掉一位，从 16 位减少到 15 位，例如例如），您可以拥有的唯一索引的数量除以 2。 15 位只能表示
2^15 - 1=32768-1=32767独特的位置。 14位-->再除以2； 13位-->再除以2。为了能够跟踪相同的字节总数，它必须跳过一些字节并仅对每2^n字节进行索引，其中 n 是从片段中取出的位数偏移值。由于片段偏移量需要使用 13，因此它占用了 3 位，因此它只能每第 8 (2^3) 个字节进行索引，因此索引适用于 8 字节块。因此，使用8 * Fragment Offset来计算每个片段的实际字节偏移量。注意事项
片段值是距第一个片段的第一个字节的偏移量。由于某些奇怪的原因，他们决定以字节为单位来测量偏移量，而不是片段的数量——尽管字节需要比索引更多的数据。简单地将片段偏移量设置为索引值（片段编号）可能更明智 - 但他们没有这样做！
I did not gain much of a benefit from other answers here. They seem to brush on the real issue only in passing, while trying to explain another issue they see, so here is the real answer:
The number of bits in the message length field is different from the number of bits in the fragment field.
Message Length field measures the whole message, across all fragments of that message
When sending a large packet, it gets broken into multiple fragments, so you need to label the fragment and keep track of the portion of the message in that fragment, and put it back into order when all the fragments arrive. You get 13 bits to describe the sequence of fragments. Length is a 16-bit integer, so its capacity (16 bits) is
2^16 - 1=65536-1=65535. That gives you 65535 different bytes, so an IP message can be at most 65535 bytes long.Fragment offset is a measure of bytes, but can't fit the # of bytes in the message
Ideally we'd like to measure fragments in the same unit as Length, which is bytes.
But we only have 13 bits for Fragment!
They wanted to keep the measure of Fragment offset in bytes, so they had to think of a way to fit 16 bits into 13 bits. They invented a weird bit mapping to do this for them:
Weird bit mapping
They realized that for every 1 less bit a number has for representing its maximum number (for example, going from 16 bits down to 15 bits by taking away one bit, for example), the number of unique indices you can have is divided by 2. 15 bits can only represent
2^15 - 1=32768-1=32767unique locations. 14 bits --> divide by 2 again; 13 bits --> divide by 2 again. In order to be able to keep track of the same total number of bytes, it has to skip some bytes and index only every2^nbytes, where n is the number of bits taken away from the Fragment offset value. Since Fragment offset is required to use 13, it takes away 3 bits, so it can only index every 8th (2^3) byte, so the indices were for 8-byte chunks. THUS the8 * Fragment Offsetto calculate the actual byte-offset of each fragment.Considerations
The Fragment value is an offset from the first fragment's first byte. For some odd reason, they decided to measure the offset in bytes, instead of number of fragments--even though bytes requires more data than an index. It might be more intelligent to simply make the Fragment offset an index value (fragment number)--but they did not do it this way!
请注意，Fragment Offset 字段以 8 字节为单位表示，而不是字节。
这就是为什么除了最后一个片段之外的每个片段内的有效负载大小必须是 8 字节的倍数的原因。
由于片段偏移量以 13 位编码，因此其范围在 0 到 8191 个 8 字节单位之间。然而，由于总长度还考虑了 IP 标头，因此片段偏移最大限制实际上是 8189 个单位，而不是 8191 个单位，请参见下文：
总长度以 16 位编码，这意味着它限制为 65535 字节。
然后，由于 IP 标头至少为 20 字节，因此有效负载被限制为最大 65535 字节 - 20 字节 = 65515 字节。
将这 65515 字节划分为 8 字节单元，结果最多可以有 8189 个单元，因此分段偏移量限制为最大 8189 个单元。
片段偏移值设置为最大值 8189 的 IP 片段可以具有最大 3 字节的有效负载：
最大 65535 字节 - 最小 20 字节 - (8189 单元 * 每单元 8 字节) = 最大 3 字节
Rurre
Note that Fragment Offset field is expressed in 8-byte units, not in bytes.
This is the reason why the payload size inside each of the fragment, except the last fragment, must be multiple of 8 bytes.
As the Fragment Offset is coded on 13bits, it results that its range is between 0 and 8191 units of 8 bytes. However, because the Total Length takes into account also the IP Header, the Fragment Offset maximum limit is in fact 8189 units, not 8191 units, see below:
Total Length being coded on 16 bits it means it is limited to 65535 bytes.
Then, as the IP header is at least 20 bytes it results that the Payload is limited to maximum 65535 bytes - 20 bytes = 65515 bytes.
Dividing these 65515 bytes in 8-byte units it results that there could be maximum 8189 units, hence Fragmentation Offset is limited to maximum 8189 units.
An IP fragment having the Fragment Offset value set to this maximum value of 8189, could have a payload of maximum 3 bytes:
Maximum 65535 bytes - minimum 20 bytes - (8189 units * 8 bytes per unit) = maximum 3 bytes
Rurre
在这里（https://cs.nyu.edu/courses/fall98 /G22.2262-001/class11.txt）给出：片段偏移以8字节（64位）为单位测量。这是因为片段偏移字段比总长度字段短 3 位，即 16 位（2^3 为 8）。
Here (https://cs.nyu.edu/courses/fall98/G22.2262-001/class11.txt) it is given that : fragment offset is measured in units of 8 bytes (64 bits). That is because the fragment offset field is 3 bits shorter than the total length field i.e 16 bits (and 2^3 is 8).
Wayne所说的加上事实上offset实际上是用在终端主机中的，这样它们就可以有效地将片段有效地存储在内存中，即连续存储。偏移量显示片段相对于整个数据报的相对位置。这就是为什么偏移量必须是 IP 片段必须是 8 字节的倍数，因为您实际上所做的是右移 3 位（因此是 13 位）。
What Wayne said plus the fact that offset actually is used in end hosts so that they can efficiently store the fragments in memory efficiently, that is, in a row. Offset shows relative position of a fragment with respect to the whole datagram. That's why offset has to be the IP fragments must be in multiples of 8 bytes because what you actually do is a right shift by 3 bits (hence the 13 bits).