如何实现从文件生成器到服务器（Java）的巨大二进制文件的HTTP传输？

Question

简单地说，我们的系统由服务器和代理组成。Agent会生成一个巨大的二进制文件，可能需要将其传输到Server。

鉴于：

1. 目前系统必须处理最大1G的文件，两年后可能会增长到10G
2. 传输必须通过 HTTP，因为其他端口可能会关闭。
3. 这不是一个文件共享系统 - 代理只需将文件推送到服务器。
4. Agent和Server都是用Java编写的。
5. 二进制文件可能包含敏感信息，因此传输必须安全。

我正在寻找技术和库来帮助我传输大文件。我所知道的一些主题是：

• 压缩选择哪一个？我们不限制自己使用 gzip 或 deflate，只是因为它们是 HTTP 流量中最流行的。如果有一些不寻常的压缩方案可以为我们的任务带来更好的结果 - 那就这样吧。
• 显然，文件需要在多个并行会话中拆分和传输。
• 背景传输大文件需要很长时间。如果有的话，它会影响解决方案吗？
• 安全HTTPS 是正确的选择吗？或者考虑到数据量，我们应该采取另一种方法吗？
• 现成的我完全准备好自己编写代码（应该很有趣），但我无法避免这样的问题：是否有任何现成的解决方案可以满足我的需求。

有人在他们的产品中遇到过这个问题吗？是如何处理的？

编辑1

有些人可能会质疑选择 HTTP 作为传输协议。问题是服务器和代理可能彼此相距很远，即使位于同一公司网络中也是如此。我们已经遇到了许多与客户仅在其公司网络的节点上打开 HTTP 端口这一事实相关的问题。它并没有给我们留下太多的选择，而是使用HTTP。使用 FTP 很好，但它必须通过 HTTP 进行隧道传输 - 这是否意味着我们仍然拥有 FTP 的所有优势，还是会削弱 FTP 的性能，而使其他替代方案变得更加可行？我不知道。

编辑2

更正 - HTTPS 始终开放，有时（但并非总是）HTTP 也开放。但就是这样。

Answer 1

您可以在端口 80 上使用任何协议。使用 HTTP 是一个不错的选择，但您不必使用它。

压缩选择哪一个？我们不限制自己使用 gzip 或 deflate，只是因为它们是 HTTP 流量中最流行的。如果有一些不寻常的压缩方案可以为我们的任务带来更好的结果 - 那就这样吧。

最佳压缩取决于内容。为了简单起见，我会使用 Deflator，但是 BZIP2 可以给出更好的结果（需要一个库）

对于您的文件类型，您可能会发现首先对该类型进行一些特定的压缩，可以使发送的数据更小。

显然，文件需要在多个并行会话中拆分和传输。

这对我来说并不明显。并行下载数据通过获取更多可用带宽（即挤出相同带宽的其他用户）来提高性能，这可能是不可取的，甚至是毫无意义的（如果没有其他用户）

背景 传输大文件需要很长时间。如果有的话，它会影响解决方案吗？

您将希望能够随时重新开始下载。

安全 HTTPS 是正确的选择吗？或者考虑到数据量，我们应该采取另一种方法吗？

我确信它没问题，无论数据量有多大。

现成的 我完全准备好自己编写代码（应该很有趣），但我无法避免这样的问题：是否有任何现成的解决方案可以满足我的需求。

我会尝试使用现有的网络服务器来看看它们是否能胜任这项工作。如果没有一个免费的网络服务器可以完成上述所有工作，我会感到惊讶。

这是一个选择http://www.java-sources.net/open-source/web-servers