http通过网络发布文件的效率远低于复制吗？

Question

我们正在开发一种Windows服务，它将充当一种“奴隶”过程。这个过程基本上下载了一个pdf，将其拆分成几个pdf，然后需要将该pdf发回。

我们目前正在使用http请求来检索pdf和许多POST以将文件发回。这样就可以从几乎任何机器上运行从属服务，并且可以根据需要轻松添加更多的从属服务来减轻负载。

我的问题是：正在使用http进行文件传输，比如显着慢，例如，只使用复制命令（仅当从属设备位于同一台机器/网络时才有效）。

使用普通命令是可行的，但我喜欢能够在任何地方添加新奴隶的灵活性。

Answer 1

HTTP的开销不是很高，除非您的服务器以非常不寻常的方式进行配置（或者它正在处理如此多的流量，以至于这些请求在来自外部世界的其他HTTP请求后排队等待。）

如果你正在谈论一个专门用于此目的的机器（或者，我应该说，一个过程），恰好使用HTTP作为其传输协议，我怀疑你会看到传输数据有任何明显的延迟

Answer 2

我完全基于肠道的想法是，某些协议（例如NFS）在某些情况下会在某种程度上甚至可能比HTTP快得多。但我认为没有足够的数据可供使用。我想你需要弄清楚多少差异对你来说很重要，然后进行一些快速测试。更好的是，直接调用哪个更适合您的需求 - 通过防火墙和开放式互联网，甚至可能通过VPN更容易获得HTTP - 并且只是先尝试​​一下。如果你碰壁，试验其他选项。

我发布此消息后立即

更新：，我记得在线备份服务Backblaze使用HTTPS进行与其存储设备之间的所有内部数据传输。这篇文章记录了这一点：Petabytes on a budget: How to build cheap cloud storage - 跳到“Backblaze Storage Pod运行免费软件”。关于HTTPS优于低级协议的优势，有一些很好的思考。他们必须快速传输很多数据。因此，如果它对他们有用，那么它很有可能对你有用。

Answer 3

rsync或类似的二进制协议会更快，因为构建http请求不会产生任何开销。它还有一些其他很好的功能，如速率限制，所以你不要过度使用目标主机。

更重要的是，您不必消耗运行Web服务器的资源，并且担心像apache这样的服务的正常运行时间/管理。

但是，如果当前的解决方案足够快，那么就没有理由修复未破坏的问题。