我建立一个大型网站，会员将被允许上传内容（图片，视频）到大小为20MB（也许有点不太一样15MB，我们还没有一个最后的上传限制解决尚未但是这将是10之间的某处-25MB）。
我的问题是，我应该用HTTP或FTP上传走在这种情况下。 请记住，上传的80-90％将是更小的尺寸一样CCA 1-3MB但时不时一些成员也将要上传大文件（10MB +）。
是HTTP这样的大文件上传足够可靠的，或者我应该去用FTP？ 有没有同时上传文件HTTP和FTP之间明显的速度差异？
我问，因为我使用的是已经有文件上传的HTTP适配器Zend框架，万一我选择FTP我会写我自己的适配器它。
谢谢！
HTTP肯定把较少的在你的客户的负担。 很多地方有代理或阻止所有FTP流量（或缩小）的防火墙。
HTTP的最大优点是它越过防火墙，它很容易进行加密---只使用HTTPS端口443上，而不是HTTP的80端口上都经过代理服务器和防火墙。 而这些天它很容易上传使用POST在HTTP / HTTPS一个20MB的文件。
与HTTP的问题是，它没有重新启动的上传。 如果你发送文件的80％，然后是有故障，则需要在开始重新启动。 这就是为什么厂商越来越多地使用基于闪存的，基于JavaScript的基于java或上传和下载者。 这些系统可以看到有多少文件已发送，发送一个MAC，以确保它正常到来，重新发送缺少的部分。
MAC是比你想象的更重要。 TCP校验和只有32位，所以有1英寸-4-十亿机会错误不被检测到。 这可能发生了很多与今天的互联网。
是HTTP这样的大文件上传足够可靠
FTP的一个主要优点是恢复中止上传的能力。 大多数FTP服务器和客户端支持这一点，但它并不总是被激活。 而对于HTTP，这是理论上的可能使用特殊的头，但是一个正常的客户端（即浏览器）将不支持它。
另一个优点是批量上传：在FTP很简单，不是那么HTTP。
但是，为什么不只是提供两个选项？ HTTP对于那些谁是背后的代理或不会/不能使用FTP客户端和FTP的谁要做上传多个或大量上载在不可靠的连接的人。
我不wanto是讽刺，但文件传输协议必须在文件传输更可靠:)
资源可用性/使用率超过可靠性或速度中的问题。 每个上传消耗资源 - 对上传的时间在Web服务器上 - 线程/内存/等。 如果内容上载流量大文件显著这将是更好地使用FTP简单地释放你的HTTP服务器，以更快地响应页面请求。
我肯定，选择这里的人，其余的HTTP方法。 这样做的原因是你说的最多的文件从一到三兆是什么。
问题是，对于“休息”，那么：
你有没有考虑允许用户通过电子邮件发送大文件的守护程序脚本，获取电子邮件和上传电子邮件与发送者相关联的帐户？ 或有Flash上传的解决方案，在一个类似Facebook的做法。
FTP将消耗比HTTP带宽少，因为后者将需要编码（BASE64）的二进制内容成纯文本从而增加总传输大小。 （1/3）。
然而，带宽消耗可能不一定是主要关注的问题，比其他因素，如可用性和安全性，在HTTP为准。
