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

Question

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

给定:

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

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

• 压缩 选择哪一个？我们并不局限于 gzip 或 deflate，只是因为它们在 HTTP 流量中最为流行。如果有一些不寻常的压缩方案，可以为我们的任务产生更好的结果 - 就这样吧。
• 拆分 显然，文件需要拆分并在多个并行 session 中传输。
• 背景 传输一个巨大的文件需要很长时间。它是否会影响解决方案(如果有的话)？
• 安全 HTTPS 是可行的方法吗？还是考虑到数据量，我们应该采取另一种方法？
• 现成的 我已经做好了自己编码的准备(应该很有趣)，但我无法回避这个问题是否有任何现成的解决方案可以满足我的需求。

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

编辑1

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

编辑2

更正 - HTTPS 始终打开，有时(但不总是)HTTP 也打开。但仅此而已。

Answer 1

您可以在端口 80 上使用任何协议(protocol)。使用 HTTP 是一个不错的选择，但您不一定非要使用它。

Compression Which one to choose? We do not limit ourselves to gzip or deflate, just because they are the most popular for HTTP traffic. If there is some unusual compression scheme, which yields better results for our task - so be it.

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

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

Splitting Obviously, the file needs to be split and transfered in several parallel sessions.

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

Background Transfering a huge file takes a long time. Does it affect the solution, if at all?

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

Security Is HTTPS the way to go? Or should we take another approach, given the volume of data?

无论数据量如何，我确信它没问题。

off-the-shelf I am fully prepared to code it myself (should be fun), but I cannot avoid the question whether there are any off-the-shelf solutions satisfying my demands.

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

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