问题标签 [ip-fragmentation]

我目前正在浏览我的网络幻灯片，想知道是否有人可以帮助我解决碎片化的概念

所以我理解第一部分直到“108 字节”，但我不明白的是这个“8 字节 = 13.5 => 13 * 8 字节 = 104 字节”

这些额外的字节是什么？

其余的很清楚。

我在Firewalls for Dummies, 2nd edition book, page 58中读到，出于性能目的，TCP 标头仅附加到第一个 IP 片段，而片段的其余部分仅携带应用程序有效负载。真的吗？

更新：添加了参考

据我目前所了解的，与不透明的 IP 分片不同；其中数据包在源处被分段并仅在目的地处重新组装；透明 IP 分段的中间网络系统，在传输过程中重新组装和分段 IP 数据包。在下面的示例中，两个终端系统 (A) 和 (B) 相互通信，每个终端系统分别是子网 1 和子网 3 的一部分。router1 会重新组装 A 发送的 IP 数据包片段，然后将整个未分段的数据包发送给 router2，后者将在将其发送给 B 之前将其分段？这是透明 IP 分段的工作原理吗？

通过 TCP/IP 发送时，是否有理由在应用程序中分段数据以避免 IP 层中的潜在碎片？

鉴于 IP 在冒泡到 TCP 之前会重新组装片段，那么应用程序中的分段和重组是否有任何处理/效率原理？

我们有一个应用程序进行 udp 广播。数据包大小大多高于 mtu，因此它们将被分段。

tcpdump 表示所有数据包都已收到，但应用程序并未全部收到。

如果将 mtu 设置得更大，那么整个事情就不会发生，因此不会出现碎片。（这是我们现在的解决方法 - 但德国人不喜欢解决方法）

所以看起来碎片化是问题所在。

但我无法理解数据包丢失的原因和位置。

应用程序开发人员表示，他们可以在接收数据包的套接字上看到数据包的丢失情况。所以他们的应用程序不会丢失数据包。

我的问题是：

linux设备上的tcpdump监控在哪里？

那里的数据包是否已经重新组装或稍后完成？

如何进一步调试此问题？

RFC8200明确指出，分片仅由源节点完成，不由任何中间节点完成。它还说片段在接收器处重新组装。我是否可以由此得出结论，重组只在接收方完成，除了目的地之外没有节点可以重组数据包？

我目前正在用 Visual C++ 开发一个图像采集应用程序，它从功能有限的 UDP 硬件设备接收图像数据（即没有 UDP 校验和）。该设备具有与专用交换机的 GBit 连接，PC 使用专用 NIC 和与此交换机的 10GBit 连接。

传输的图像数据由大小从 6528 到 19680 字节的数据包组成。这些数据包由硬件设备分段，并由 PC 上的网络堆栈重构。

有时一个数据包（称为数据包#4711）丢失，PC 端尝试重建它很长时间。在此时间跨度内，由于 16 位数据包 id 溢出，硬件设备会发送具有相同打包 id 的新数据包。现在 PC 收到（新）数据包 #4711 的新片段，并使用它来完成旧的、仍未组装的数据包并组装损坏的数据包。最重要的是，新的#4711 数据包的剩余片段被存储并与下一个#4711（将在几秒钟后收到）合并。因此，系统运行的时间越长，越多的数据包 id 将受到损害，直到根本无法进行通信。

由于功能有限，我们无法计算硬件设备上的 UDP 校验和。

我们不能使用 IPv6（它将提供更大的数据包 ID），因为不支持硬件设备。

我们将不得不在 UDP 之上实现我们自己的协议并“手动”分段和重建数据，但如果我们能找到一种方法将 Windows 上的数据包重建超时减少到 500 毫秒或更短，我们就可以避免这种情况。

我搜索了谷歌和 Stackoverflow 的信息，但结果并不多，而且没有一个有太大帮助。

因此，问题是：有没有办法通过注册表、Windows API 或任何其他魔法来减少 Windows 10 上 IPv4 UDP 片段的重建超时，或者您有更好的建议吗？

基本上我是网络新手，我正在尝试一个关于碎片的例子。这是问题

给出以下详细信息，以表格的形式说明分段：数据大小 = 24000 位，偏移量 = 370，M=1，D = 0，新 MTU 为 1500 字节。

这是我的答案，DF = 不要分段，MF = 更多片段，24000 位 = 3000 字节。

我想知道这个答案是否正好适合偏移列。有人可以帮忙吗？

I used a UDP socket (IPv4) sending 64KB packet to an end-system. When I capture the packets of end-system using Wireshark, I found that the IP Identification field of the reassembled IP datagram range from 0x0000-0x7fff(0-32767), i.e, when the end-system received a datagram with ID 0x7fff, the next datagram holds the id value of 0x0000 rather than 0x8000.

It confused me a lot. Why not 0x0000-0xffff(0-65536)?

My sender program is written with C# code, running on Windows7. Network interface card brand is Intel.

Please help.

我有一个位于 2 个路由器之间的 linux 系统（类似于嗅探器）。两个路由器都支持巨型帧，而我的系统仅限于 MTU 1500。

我的理解是，发送路由器会将巨型帧分段为基于 MTU 1500 的 IP 数据报，Linux 将根据 RFC 815 重新组装它们。

关于这个过程的几个问题：

1. 在 Linux 中，哪个层负责重组过程？哪个文件？

2. 此过程（分段和重组）是否适用于所有第 3 层协议（例如 IPv4\IPv6）？

3. 假设我的嗅探器构造了一个大数据包并将其发送出去，碎片是否由 linux 堆栈自动发生？

谢谢，冉