客户端将文件上传到远程服务器的最佳方式是什么？

Question

我有两台服务器。 第一个（Main）是安装了脚本和数据库的服务器 第二个（远程）是仅上载文件的服务器（仅用于存储）。

现在我对如何上传文件感到困惑，我有两个想法，我不知道它们是否是最好的方法。

想法：

1. 首先通过ajax将文件上传到主服务器并进行全部安全保护 操作（检查大小，类型等），然后上传 再次到第二台服务器（远程服务器）。

2. 通过ajax将文件直接上传到第二个（远程服务器）， 并在那里进行所有检查和安全操作，然后将文件信息发送到第一台服务器（主），将文件信息存储到数据库中（不推荐）。
   

我想知道大型上传网站在存储用户上传的文件方面的表现，以及如何将文件上传到远程服务器的想法？

Answer 1

这两种机制都是有效的。事实上，我们在两个产品中尝试了这两种产品。他们每个人都有自己的优点和缺点。

假设：主服务器提供Web UI。 让我们有两个名为main.com和remote.com的服务器。

您需要考虑的主要因素是：

1. 跨源资源共享（CORS）：检查这是否是一个大问题的最直接方法是您是否需要支持IE＆lt; = 9。旧版IE不支持XHR2，因此无法上传AJAX文件。有流行的后备（例如iframe传输），但每个都有自己的问题。

2. 带宽：如果文件首先上传到main.com，然后再上传到remote.com，则所需带宽会翻倍。根据您的服务器是否落后于负载平衡器，需求会有所不同。直接上传到remote.com会有效地使用带宽。

3. API响应时间：除非您的API正在执行乐观更新，否则需要等到文件完全重新上传到remote.com，然后才能可靠地响应。此外，这取决于main.com和remote.com之间的RTT。

4. API域数：这是一个小问题。 Web客户端必须指定用于哪个API的域。但它确实与上面的CORS问题有关。

5. 性能：如果Web服务器正在处理文件上载，则当服务器处理大型文件（或大量文件）时，它可能会遇到性能问题。它可能会影响其他用户。

<强> 机制

<强> 1。客户端上传到main.com。 main.com重新上传到remote.com

• CORS：没问题
• 带宽：双倍
• 回复时间：双人（往返）;正常（乐观）
• API域：一个
• 效果：可能会影响网络服务

<强> 2。客户端上传到remote.com。 remote.com将信息发送至main.com

• CORS：有问题
• 带宽：高效
• 响应时间：高效
• API域：两个
• 表现：没问题

第3。 [EXTRA]客户端上传到main.com。 main.com将文件流式传输到remote.com。 remote.com会重新发送文件信息。

• CORS：没问题
• 带宽：双倍
• 响应时间：小于两倍（流式传输）
• API域：一个
• 性能：比方法1更好的内存占用

<强>结论

根据您的使用情况，您需要使用不同的机制。对于我们的情况，我们对遗留产品使用方法2（直接上传），因为我们需要支持旧版浏览器（IE 7，FF 3）。跨领域问题一直在刺激我们许多不同的情况（例如，当客户落后于代理等）时。

我们为新产品使用方法1。对于正常情况，带宽和响应时间问题仍然可以，但是当跨越大陆部署Web服务器和远程服务器时，性能较差。我们做了很多优化以使其可以接受，但它仍然比方法2更差。

方法3由我自己在侧面项目中使用。它包括在这里因为我认为它也是一个很好的候选人。

修改

流式传输（方法3）和重新上传（方法1）的区别主要在于文件在main.com中的存储方式。这会影响资源分配。

要重新上传，首先将上传的2GB文件存储在main.com中，然后重新上传到remote.com。 main.com必须分配资源来临时存储文件（磁盘空间，内存，IO的CPU）。此外，作为一个系列流程，完成上传到remote.com所需的总时间加倍（假设上传到main.com的时间等于上传到remote.com的时间）。

对于流媒体，上传到main.com的文件会同时上传到remote.com。由于main.com一旦收到块，就会将文件的一部分上传到remote.com，因此上传过程会重叠，从而缩短上传时间（小于两倍）。换句话说，如果main.com不需要处理，则main.com实际上是remote.com的代理。此外，由于文件未作为整体存储在main.com上（块通常存储在内存中），因此它不会消耗那么多资源而不是重新上传。但是，如果main.com需要整体处理文件，那么流式传输不会带来太多好处。