简单地说，我们的系统由一个服务器和一个代理组成。代理生成一个巨大的二进制文件，可能需要传输到服务器。
给定:
- 系统现在必须处理高达1G的文件，在2年内可能会增长到10G
- 必须通过HTTP传输，因为其他端口可能被关闭。
- 这不是文件共享系统——代理只需要将文件推送到服务器。
- Agent和Server都是用Java编写的。
- 二进制文件可能包含敏感信息，因此传输必须是安全的。
我正在寻找技术和库来帮助我传输巨大的文件。我所知道的一些主题是:
- 压缩选择哪一个?我们并不局限于gzip或deflate，因为它们是HTTP流量中最流行的。如果有一些不寻常的压缩方案，可以为我们的任务产生更好的结果-那就这样吧。
- 拆分显然，文件需要在几个并行会话中拆分和传输。
- Background传输一个大文件需要很长时间。如果有的话，它会影响解决方案吗?
- Security HTTPS是正确的吗?或者考虑到数据量，我们是否应该采取另一种方法?
- 现成的我完全准备好自己编码(应该很有趣)，但我无法回避是否有任何现成的解决方案满足我的需求。
有人在他们的产品中遇到过这个问题吗?是如何处理的?
编辑1
有些人可能会质疑选择HTTP作为传输协议。问题是服务器和代理可能彼此相距很远，即使它们位于同一个公司网络中。我们已经遇到了许多与客户在其公司网络的节点上只开放HTTP端口相关的问题。它没有给我们留下太多选择，但使用HTTP。使用FTP很好，但它必须通过HTTP进行隧道传输——这是否意味着我们仍然拥有FTP的所有好处，还是会削弱它，使其成为其他更可行的替代方案?我不知道。编辑2
更正- HTTPS总是打开的，有时(但不总是)HTTP也是打开的。
您可以在端口80上使用任何协议。使用HTTP是一个很好的选择，但你不必使用它。
压缩选择哪一个?我们并不局限于gzip或deflate，因为它们是HTTP流量中最流行的。如果有一些不寻常的压缩方案，可以为我们的任务产生更好的结果，那就这样吧。
最佳压缩取决于内容。为了简单起见，我会使用Deflator，但是BZIP2可以提供更好的结果(需要一个库)
对于你的文件类型，你可能会发现先做一些特定于该类型的压缩，可以使发送的数据更小。
拆分显然，文件需要在多个并行会话中拆分和传输。
这对我来说不明显。并行下载数据通过抢占更多可用带宽(即挤占相同带宽的其他用户)来提高性能，这可能是不希望的，甚至没有意义(如果没有其他用户)
后台传输一个大文件需要很长时间。如果有的话，它会影响解决方案吗?
您将希望能够在任何时候重新开始下载。
安全性HTTPS是正确的选择吗?或者考虑到数据量，我们是否应该采取另一种方法?
不管数据量有多大，我确信它很好。
我已经完全准备好自己编写它(应该很有趣)，但是我无法回避是否有任何现成的解决方案满足我的需求。
我会尝试使用现有的web服务器，看看他们是否能胜任这项工作。如果没有一个免费的web服务器能做到以上所有的事情，我会很惊讶。
这是一个选择http://www.java-sources.net/open-source/web-servers