我想通过互联网在两个地方之间传输文件。现在我有 VPN，可以浏览、下载和传输文件。所以我的问题实际上并不是如何传输文件；相反，我想使用最有效的方法，因为这两个地方不断共享大量数据。
我想放弃 VPN 的原因是它太慢了。在住宅区，高速上传非常昂贵/不可能，所以我想使用不同的方法。
我正在考虑使用以下程序http://www.dropbox.com 。Dropbox 的问题在于免费版本仅提供 2 GB 的存储空间。我认为他们提供的交易还不错，我可能愿意付费来提高速度。但我担心传输数据的速度。Dropbox 会将文件上传到他们的服务器，然后将其从服务器发送到其他位置。我希望它能更快。
无论如何，我在想为什么不自己创建一个程序。这是我正在考虑的算法。如果听起来太疯狂，请告诉我。
（记住我的目标是尽快传输文件）
我将在这个算法中使用的东西：
- 互联网上的服务器名为 S（具有快速的下载和上传速度。我付费托管了一个网站和一些服务。我想利用它。）
- 位置 1 的客户 A
- 位置 2 的客户 B
假设在位置 1 处创建了 20 个大文件，需要将其传输到位置 2。
- 客户端 A 以尽可能高的压缩率压缩文件。
- 客户端 A 开始通过UDP给客户 B。
- 因为我使用的是 UDP，所以我将在每个数据包上包含序列号。
- 让服务器 S 帮助加快速度。例如，每次丢失数据包时，我们都可以使用服务器 S 通知客户端 A 需要重新发送数据包。
无论如何，我认为这种方法将提高传输速率。我不知道是否可以在压缩数据时开始发送数据。或者，即使我们还没有收到整个文件，是否可以开始解压缩数据。也许不压缩就立即开始发送文件会更快。如果我知道我将始终发送大型文本文件，那么我显然会使用压缩。我需要这个作为通用算法。
所以我想我的问题是我可以通过使用 UDP 而不是 TCP 并使用额外的服务器来跟踪丢失的数据包来提高性能吗？和我应该如何在发送之前压缩文件？使用最高压缩率压缩一个 1 GB 的文件大约需要 1 小时！我想利用这段时间，在压缩的同时发送它。
答案1
只需使用rsync。它非常高效地使用 TCP，只传输发生变化的文件，并且您可以根据需要选择使用压缩。
您不会找到一种方法来击败高效使用 TCP 的应用程序。TCP 在过去约 40 年中已被许多非常非常聪明的人定义和改进，因此很难被击败。
支持现代 TCP 堆栈解雇能够非常高效地检测和报告丢失的数据包，因此只有丢失的数据包才会被重新传输。在中间放置服务器不会加快速度，只会增加延迟。
真正能够在数据传输性能上超越 TCP 的唯一方法是让网络拥塞变得更糟。TCP 会尽可能快地运行，但当出现拥塞迹象时会暂时退缩。如果您创建了一个基于 UDP 的协议，而它并不关心自己会给所经过的任何链接增加多少拥塞，那么您可能会大量发送导致大量拥塞问题的数据包，但平均而言，吞吐量可能会略高于 TCP。