java - udp文件传输项目-是否必须进行错误检查？

Question

我已经获得了使用UDP传输文件的经典任务。在不同的资源上，我已经阅读了检查数据包中的错误(将CRC和数据一起添加到数据包中)的必要信息，并且UDP已经检查了损坏的数据包并将其丢弃，因此我只需要担心重新发送丢失的数据包。

其中哪一个是正确的？我是否需要手动对到达的数据包执行完整性检查，或者已经丢弃了不正确的数据包？

顺便说一下，该项目的语言是Java。

编辑:一些资料(类(class)书，互联网)说校验和仅覆盖标题，因此确保发送方和接收方IP正确等。一些资料说校验和也覆盖数据段。一些消息来源说，校验和可能覆盖数据段，但它是可选的，由操作系统决定。

编辑2:问我的教授，他们说对数据段的UDP错误检查在IPv4中是可选的，而在IPv6中则是默认的。但是我仍然不知道它是在程序员的控制之下，还是在操作系统的控制之下，还是在另一层……

Answer 1

第一个事实:

UDP具有一个16位的校验和字段，从数据包头的第40位开始。这遭受(至少)两个弱点:

校验和不是强制性的，所有设置为0的位都定义为“无校验和”。

从字面上严格来说是16位check- 和，因此很容易受到未检测到的损坏。

总之，这意味着UDP的内置校验和可能不够可靠，具体取决于您的环境。

第二个事实:

比传输过程中的数据损坏更现实的威胁是丢包重新排序:USP无法保证

所有(最终)到达的数据包都到达所有

数据包以与发送

相同的顺序到达

实际上，UDP根本没有内置机制来处理大于单个数据包的有效负载，这是因为事实并非如此。

结论:

在没有额外措施的情况下，逐个分组接一个分组地接收，势必会产生一个与发送流不同的接收流，除了最有利的环境之外，这使得它不是直接文件传输的最佳协议(protocol)。

如果 想要或必须使用UDP来传输文件，则需要构建这些部分，这些部分对于TCP是不可或缺的，但对于应用程序中的UDP则不是。有一句话，这很可能导致TCP的重新实现。

成功的实现包括许多对等文件共享协议(protocol)，其中无论如何都要对连接中断和数据包丢失或重新排序进行保护，以使过滤器失效或减轻过滤器的损坏。

实现建议:

对我们有用的是分块窗口实现:有效负载被分为固定长度和方便长度的块(我们使用了1023个字节)，状态N的这样的块被保留在发送和接收端。

在发送方:

启动UDP消息，该消息包含这样的块，流中的序列号(不止一次)以及校验和或哈希。

状态数组将该块标记为带有时间戳

的“已发送/待处理”

如果使用了完整的状态数组(发送窗口)，则发送停止

在接收方:

接收到的数据包将根据其校验和

进行检查
如果序列号的所有副本都同意，则否定地确认

损坏的数据包，否则丢弃

OK数据包在状态数组中被标记为“已接收/待处理”，带有时间戳

确认通过发送一个ack数据包来工作，如果已经接收到足够的数据块来填充ack数据包，或者最早的“接收/未决”的时间戳太旧(从几毫秒到100毫秒)。

Ack数据包需要校验和，但无需排序。

已发送确认的

块在状态数组

中被标记为带有时间戳的“ack/pending”

在发送方:

接收并检查Ack数据包，丢弃损坏的数据包

在状态数组

中将收到其确认的块标记为“ack/done”

如果状态数组中的第一个块标记为“ack/done”，则状态数组将向上滑动，直到再次完成其第一个块为止。

这可能会释放一个或多个未发送的块以进行发送。

对于状态为“已发送/未决”的块，使用

，由于原始块可能已丢失，因此时间戳上的超时会触发该块的新发送。

在接收方:

接收块i + N(N为窗口宽度)将块i标记为ack/done，从而使接收窗口向上滑动。如果不是所有滑出接收窗口的块都被误认为是“ack/pending”，则这构成了不可恢复的错误。

对于状态为“ack/pending”的块的

，由于原始ack消息可能已丢失，因此时间戳上的超时会触发对该块的新ack。

显然，从发送端需要一种特殊的消息类型，如果发送窗口滑出文件的末尾，以信号通知接收到一个ack而没有发送块N + i，我们通过简单地发送N个块来实现它。存在，但没有有效载荷。