HTTP 与 FTP 上传答案

【问题标题】：HTTP vs FTP uploadHTTP 与 FTP 上传
【发布时间】：2010-11-17 08:21:29
【问题描述】：

我正在建立一个大型网站，允许会员上传最大 20MB 大小的内容（图像、视频）（可能会小于 15MB，我们尚未确定最终的上传限制，但它将是介于 10-25MB 之间）。

我的问题是，在这种情况下我应该使用 HTTP 还是 FTP 上传。请记住，80-90% 的上传文件会是较小的文件，例如 1-3MB，但有时有些会员还想上传大文件 (10MB+)。

对于如此大的文件，HTTP 上传是否足够可靠，或者我应该使用 FTP 吗？上传文件时 HTTP 和 FTP 之间是否存在明显的速度差异？

我问是因为我使用的是 Zend Framework，它已经有用于文件上传的 HTTP 适配器，如果我选择 FTP，我将不得不为它编写自己的适配器。

谢谢！

【问题讨论】：

标签： php zend-framework upload file-upload

【解决方案1】：

HTTP 绝对减轻了您的客户的负担。很多地方都有阻止所有 FTP 流量（进出）的代理或防火墙。

【讨论】：

使用 FTP over HTTP 有许多技术原因，但我认为用户体验胜过所有这些。

【解决方案2】：

HTTP 的最大优势在于它可以通过防火墙并且非常容易加密——只需在端口 443 上使用 HTTPS 而不是在端口 80 上使用 HTTP。两者都通过代理和防火墙。如今，使用 POST 通过 HTTP/HTTPS 上传 20MB 的文件非常容易。

HTTP 的问题在于它无法重新启动以进行上传。如果您收到了 80% 的文件发送，然后出现故障，则需要从头开始重新启动。这就是为什么供应商越来越多地使用基于 Flash、基于 java 或基于 javascript 的上传器和下载器。这些系统可以查看已发送多少文件，发送 MAC 以确保它已正确到达，并重新发送丢失的部分。

MAC 比您想象的更重要。 TCP 校验和只有 32 位，因此有 40 亿分之一的机会无法检测到错误。在当今的互联网上，这种情况可能经常发生。

【讨论】：

HTTP POST 确实不能重启，但是 Flash 和 Javascript 不能像 Java 一样对文件做 HTTP PUT。
是的，我的回答是供应商越来越多地使用基于 Flash 和 java 的上传器，因为它们是可重启的。
433 端口不是更典型的 HTTPS 而不是 437 吗？
端口 443。感谢您接听。

【解决方案3】：

HTTP 上传是否足够可靠？这么大的文件

FTP 的一个主要优势是能够恢复已中止的上传。大多数 FTP 服务器和客户端都支持这一点，尽管它并不总是被激活。而对于 HTTP，理论上可以使用特殊标头，但普通客户端（即浏览器）不支持它。

另一个优点是批量上传：在 FTP 中非常简单，在 HTTP 中则不然。

但是为什么不简单地提供两种选择呢？ HTTP 适用于那些使用代理或不会/不能使用 FTP 客户端的人，而 FTP 适用于必须通过不可靠的连接上传大量或大量上传的人。

【讨论】：

FTP 上传无法使用 FPT 客户端完成。它将通过 PHP 代码中的 Web 浏览器完成。唯一的麻烦是我必须为 FTP 上传编写自己的适配器类（因为 Zend 框架目前只支持 HTTP），这需要我一些时间，而且我有一个截止日期。
我看不出服务器部分的实现与客户端使用的内容有什么关系。网络浏览器根本不一定支持 FTP 上传（Firefox 不支持，但我认为有一个插件）。但是如果你不能使用现有的 FTP 服务器，那么自己实现肯定不是一个好主意。

【解决方案4】：

我不想讽刺，但文件传输协议在文件传输上必须更可靠:)

【讨论】：

不是。它只是旧了。
HTTP 是一项相当古老的技术，我猜大概是 1990 年左右。但你知道吗？ 30 年后的 2020 年，它仍在摇摆不定：D FTP 早了几年 ietf.org/rfc/rfc959.txt，但它不是一个好的评估参数。

【解决方案5】：

资源可用性/使用情况比可靠性或速度更重要。每次上传都会在上传期间消耗您的网络服务器上的资源 - 线程/内存/等。如果内容上传流量对于大文件来说很重要，那么最好使用 FTP 来释放您的 HTTP 服务器，以便更好地响应页面请求。

【讨论】：

它仍然必须在同一台机器上运行，因此除非特定的 FTP 实现比特定 HTTP 服务器中的 HTTP 上传更有效/性能更高，否则不会有任何自动收益。或者，如果您使用某种共享存储，您也可以拥有一个单独的专用上传 HTTP 服务器，因此没有理由偏爱其中一个。
您为什么认为这些必须在同一台机器上运行？
想必HTTP服务器需要访问上传的文件。
您对我的帖子的原始回复讨论了共享存储，因此您了解 HTTP 服务器可以从任何地方获取文件。这条评论没有解释为什么 FTP 服务器和 HTTP 服务器必须在同一台机器上运行。他们没有。我什至不确定你为什么最初发布你所做的事情。您在这里有另一个响应，基本上支持 FTP 解决方案，但您在这里说没有理由偏爱其中一个。

【解决方案6】：

我肯定会像这里的其他人一样选择 HTTP 方法。原因是您所说的大多数文件都在 1 到 3 兆字节之间。

问题在于“休息”，所以：

您是否考虑过允许用户通过电子邮件将较大的文件发送到守护程序脚本，该脚本会获取电子邮件并将电子邮件上传到与发件人关联的帐户？或者有 Flash 上传器的解决方案，采用类似 facebook 的方式。

【讨论】：

【解决方案7】：

FTP 将比 HTTP 消耗更少的带宽，因为后者需要将二进制内容编码（base64）为纯文本，从而增加总传输大小。（按 1/3）。

但是，与 HTTP 占主导地位的其他因素（如可用性和安全性）相比，带宽消耗可能不一定是主要问题。

【讨论】：

什么？ base64 上传？不，它没有。使用 multipart/form-data 它以二进制形式上升。