文件传输 - 是的，UDP协议

Question

我有一个需求，需要创建一个UDP文件传输系统。我知道TCP是可以保证可靠性更高的，但是由于我需要在不同位置之间传输大型文件，因此我认为在这个项目中速度优势胜过使用TCP。我刚开始这个项目，但如果有人做过类似的项目并能提供一些指导，我会非常感激。我将编写客户端和服务器两端，因此无需担心其他产品的功能限制。

总的来说，我需要：

- 将大型文件分段发送 - 能够从客户端控制带宽 - 创建某种数据包编号系统，以处理错误、重传和通过服务器按块组装文件（是的，这是我们从TCP免费得到的所有东西 :-） - 可配置数据报大小 - 我认为某些防火墙会抱怨数据包太大？ - 其他可能遗漏的内容

我将使用UdpClient开始这个旅程，并想用C#编写这个应用程序。除了使用TCP之外，您还有什么建议吗？

---

已经有巨大的成功案例。我们曾经使用RocketStream.com完成此项任务，但他们将其产品出售给另一家公司，只供内部使用。我们通常获得比FTP或原始TCP字节传输快30倍的速度。

- Scott

---

使用TCP :) “我认为在这个项目中，使用TCP带来的速度优势大于其好处。”什么？你真的指望能在TCP上获得任何速度优势吗（为什么）？ - ysdx

在短数据传输的情况下，UDP通常比TCP表现更佳，而在长数据传输方面则不是。 - Serge Wautier

猜测而言，UDP的速度优势恰恰来自于它不会本地实现你说你要实现的东西。 - millimoose

换句话说，文件越大，你就越需要可靠的传输方式。去找一个TFTP库。 - Hans Passant

我们现在在rocketstream.com上实际看到了这些速度，所以这不仅仅是营销。这个想法是不要对每个数据包都进行ACK确认。从任意数量的数据包开始，然后检查是否已经到达。如果到达了，就传输下一组数据包。如果没有到达或有任何错误，则重新传输并降低ACK之间的数据包数量。这个想法是在更好的网络上获得大的性能提升，在糟糕的网络上则减少提升。 - Scott

Answer 1

关于

可配置数据报大小 - 如果太大，一些防火墙可能会抱怨？

一个数据报最多可以达到65,536字节。考虑到所有IP头信息，您将得到65,507字节的有效载荷。但是您必须考虑网络路径上所有设备的配置方式。通常，大多数设备都设置了1500字节的MTU大小，因此这通常是您在互联网上的限制。如果您在位置之间设置了专用网络，则可以增加所有设备的MTU。

进一步谈到

为错误、重传和通过服务器按块组装文件创建某种数据包编号系统（是的，我们从TCP那里免费获得了所有这些东西:-）

我认为在您的情况下，最好的方法是实现应用程序级协议。像这样：

32字节序列号 8字节crc32校验和（请纠正我字节大小） 剩下的任何字节都可以用于数据

希望这给您提供了一些方向

::编辑::

从经验上来看，UDP在专用和UDP调整网络上比TCP快10-15%。

- Layticia

Answer 2

我并不确定速度的提升会有多大，但这是一个有趣的实验。这样的协议将看起来和行为更像传统基于调制解调器的协议之一，可能ZModem是其中一个更好的例子，可以从中获得一些灵感（实现了确认窗口、自适应块大小等）。

已经有一些人尝试过这个，可以查看this site。

- fvu

Answer 3

如果你成功了，那真是太棒了。

不要没有WireShark就开始。你会需要它的。

关于算法方面，我猜你已经有了开始的想法。也许这里有一些指针：

1. 从两个端点共同使用的MTU开始，并仅使用该大小的数据包，这样你就可以控制数据包的分段（当你从TCP降级时，希望这能提供更多低级别的控制）。
2. 你可能需要研究STUN或TURN来打洞到NAT中。
3. 还可以研究ZModem- 这也具有怀旧价值 :)
4. 由于你想要从链路上挤取最大的性能，请尽可能地将所有内容放在“控制数据包”中，以便不浪费任何一个字节。
5. 我不会在数据包级别上使用任何CRC，因为我猜网络底层正在处理这些事情。

- Daniel Mošmondor

Answer 4

我有一个想法...

1. 将文件分成16k的块（长度是任意的）
2. 为每个块创建哈希值
3. 使用任何协议传输所有块的哈希值
4. 在接收端，通过将硬盘、网络上的所有内容以16k的块进行哈希来准备
5. 将接收到的哈希值与本地哈希值进行比较，并重构您拥有的数据
6. 使用任何协议下载剩余部分

我知道我已经晚了6个月，但我实在忍不住。

- Daniel Mošmondor

Answer 5

其他人说了更有趣的事情，但我想指出的是，你需要确保使用一个好的压缩算法。这将会产生天壤之别。

此外，我建议验证您对速度提升可能性的假设，制作一个简单的数据发送系统（不必担心丢失、损坏或其他问题），看看您能获得多少带宽。这至少会给您一个实际的上限，可以做到什么程度。

最后，请考虑为什么要承担这个任务？在开发所花费的时间之后，速度提升是否值得？

- Guvante

---

所有都是好的观点。对于我们而言，典型的文件传输是100多吉字节，并且已经被RAR压缩了。一次传输500多吉字节并不罕见。这就是我为什么说，在我必须传输这么大的连续文件时，发明质量检查肯定是值得的原因。技术是行之有效的。我只需要找出它是如何实现的 :-) - Scott