Question

我们正在开发一个windows服务，它将充当一种从属进程。这个过程基本上是下载一个pdf，将其拆分为几个pdf，然后需要将该pdf发回。

我们目前使用http请求来检索pdf，并使用一些POST将文件发回。这使得从服务几乎可以在任何机器上运行，并且可以很容易地添加更多的从服务来减轻负载。

我的问题是：像这样使用http进行文件传输是否比仅使用复制命令（仅当从属设备位于同一机器/网络上时才有效）慢得多。

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

Answer 1

我完全基于直觉的想法是，某些协议，如NFS，在某些情况下会比HTTP快一些，甚至可能快得多。但我不认为这是足够的数据。我认为你只需要弄清楚差异对你有多重要，然后进行一些快速测试。更好的是，大胆决定哪一个更适合你的需求——HTTP当然更容易通过防火墙和开放互联网，甚至可能通过VPN——然后先尝试一下。如果你碰壁了，试试其他的选择。

Update: right after I posted this, I remembered that Backblaze, the online backup service, uses HTTPS for all its internal data transfer to and from their storage appliances. This is documented in this post: Petabytes on a budget: How to build cheap cloud storage — jump down to "A Backblaze Storage Pod Runs Free Software". There s some good thinking there on the advantages of HTTPS over a lower-level protocol. And they have to transfer a lot of data, quickly. So if it works for them, there s a good chance it ll work for you.

Answer 2

HTTP的开销并不是很高，除非你的服务器以一种非常不寻常的方式配置（或者它处理的流量太大，以至于这些请求排在来自外部世界的其他HTTP请求之后）。

如果你谈论的是一台专门为此目的而设置的机器（或者，我应该说，一个进程），它恰好使用HTTP作为其传输协议，我怀疑你会在传输数据时看到任何明显的延迟。

Answer 3

rsync或类似的二进制协议会更快，因为在构建http请求时没有任何开销。它还有一些其他不错的功能，比如速率限制，这样你就不会对目标主机负担过重。

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

但是，如果当前的解决方案对您来说足够快，就没有理由修复未损坏的部分。

友情链接