我被赋予了使用 UDP 传输文件的经典任务。在不同的资源上，我已经阅读过检查数据包的错误（在数据包中添加 CRC）是必要的，并且 UDP 已经检查损坏的数据包并丢弃它们，所以我只需要担心重新发送丢弃的数据包。
哪一个是正确的？是否需要手动对到达的数据包进行完整性检查，或者不正确的数据包已经被丢弃？
顺便说一下，该项目的语言是 Java。
编辑：一些来源（课程书籍、互联网）说校验和仅涵盖标头，因此确保发送方和接收方 IP 是正确的等。一些来源说校验和 也 涵盖数据段。一些消息来源说校验和可能覆盖数据段，但它是可选的，由操作系统决定。
编辑 2：问我的教授，他们说数据段的 UDP 错误检查在 IPv4 中是可选的，在 IPv6 中是默认的。但我仍然不知道它是否在程序员的控制，或操作系统，或其他层......
【问题讨论】：
标签： java file udp protocols transfer
UDP 协议使用与 TCP 协议相同的策略来检查包含错误的数据包 - 数据包标头中的 16 位校验和。
UDP 数据包结构众所周知（与 TCP 一样），因此如果不加密，数据包很容易被篡改，添加另一个校验和（例如 CRC-32）也会使其更加健壮。如果目的是加密数据（手动或通过 SSL 通道），我不会费心添加另一个校验和。
请注意一个数据包可以发送两次。确保您相应地处理。
您可以在 Wikipedia 上查看两个数据包结构，两者都有校验和：
您可以更详细地检查 TCP 数据包结构，以获取有关如何处理丢弃数据包的提示。 TCP 协议为此使用“序列号”和“确认号”。
我希望这会有所帮助，祝你好运。
【讨论】：
第一个事实：
UDP 有一个 16 位校验和字段，从数据包头的第 40 位开始。这有（至少）两个弱点：
这意味着，UDP 的内置校验和可能足够可靠，也可能不够可靠，具体取决于您的环境。
第二个事实：
比传输过程中的数据损坏更现实的威胁是数据包丢失重新排序：USP 不保证
确实，UDP 根本没有内置机制来处理大于单个数据包的有效负载，这是因为它不是为此而构建的。
结论：
在没有额外措施的情况下在接收到的数据包后附加数据包必然会产生与发送流不同的接收流，但在最有利的环境中除外。这使其不是直接文件传输的最佳协议。
如果您确实想要或必须使用 UDP 来传输文件，您需要构建这些部分，它们是 TCP 不可或缺的部分，而不是 UDP 到应用程序中的一部分。不过有一种说法，这很可能会导致 TCP 的重新实现效果不佳。
成功的实施包括许多对等文件共享协议，其中防止连接中断和数据包丢失或重新排序需要成为应用程序功能的一部分，以击败或减轻过滤器。
实施建议：
对我们有用的是分块窗口实现：有效负载被分成固定且方便长度的块，（我们使用 1023 字节）在发送端和接收端保存 N 个这样的块的状态数组。
发送方：
在接收方：
发送方：
在接收方：
显然，发送端需要一个特殊的消息类型，如果发送窗口滑出文件的末尾，表示接收到一个 ack 而不发送块 N+i，我们通过简单地发送 N 来实现它块多于存在，但没有有效负载。
【讨论】：
您可以确定您收到的数据包与发送的数据包相同（即，如果您发送数据包 A 和接收数据包 A，您可以确定它们是相同的）。对数据包的传输层 CRC 检查确保了这一点。但是，由于 UDP 不保证交付，因此您需要确保收到所有发送的内容，并且需要确保正确订购。
换句话说，如果数据包 A、B 和 C 按顺序发送，您实际上可能只收到 A 和 B（或没有）。您可能会使它们乱序，C、B、A。因此，您的检查需要注意 TCP 提供的保证交付方面（验证排序，确保所有数据都在那里，并通知服务器重新发送您没有发送的任何内容） t 接收）你需要的任何程度。
首选 UDP 而不是 TCP 的原因是，对于某些应用程序而言，数据排序和数据完整性都不重要。例如，当流式传输 AAC 音频数据包时，单个音频帧非常小，以至于可以安全地丢弃其中的一小部分或乱序播放，而不会在很大程度上破坏聆听体验。如果 99.9% 的数据包被正确接收和排序，你可以很好地播放流并且没有人会注意到。这适用于某些蜂窝/移动应用程序，您甚至不必担心重新发送丢失的帧（请注意，在某些情况下，Shoutcast 和其他一些服务器确实使用 TCP 进行流传输 [以促进带内元数据]，但它们不'不必）。
如果您需要确保所有数据都在那里并且正确排序，那么您应该使用 TCP，它将负责验证数据是否都在那里，正确排序，并在必要时重新发送。
【讨论】：
UDP 将丢弃不符合内部每个数据包校验和的数据包； CRC 检查有助于在应用层确定，一旦有效负载看起来完整，接收的内容是否实际完整（没有丢弃的数据包）并且与发送的内容匹配（没有中间人或其他攻击） .
【讨论】：