HTTP与FTP上载

HTTP无疑会减轻客户的负担。很多地方都有代理或防火墙来阻止所有的FTP流量(输入或输出)。

HTTP的最大优点是它可以越过防火墙,而且很容易加密——只需在端口443上使用HTTPS,而不是在端口80上使用HTTP。两者都通过代理和防火墙。现在,通过http/http s上传一个20MB的文件很容易。

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

Mac比你想象的更重要。TCP校验和只有32位,因此有14亿分之一的可能没有检测到错误。这在今天的互联网上可能会发生很多。

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

ftp的一个主要优势是能够恢复中止的上传。大多数FTP服务器和客户机都支持这一点,但并不总是激活它。而对于HTTP,理论上可以使用特殊的头文件,但是普通的客户机(即浏览器)不支持它。

另一个优势是批量上传:在ftp中非常简单,而在http中则不是。

但为什么不简单地提供这两种选择呢?HTTP用于那些在代理之后或者不会/不能使用FTP客户机的人,而FTP用于那些必须通过不可靠的连接上载许多或大量上载的人。

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

资源可用性/使用比可靠性或速度更重要。每次上载都会在上载期间消耗Web服务器上的资源(线程/内存等)。如果内容上传流量对于大文件来说很重要,那么最好使用ftp来释放HTTP服务器,以便对页面请求作出更大的响应。

我肯定,选择HTTP方法作为这里的其他人。原因是你所说的大部分文件都是1到3兆字节。

问题在于“休息”,所以:

您是否考虑过允许用户通过电子邮件将更大的文件发送到接收电子邮件并将电子邮件上载到与发件人关联的帐户的Deamon脚本? 或者有一个类似于Facebook的FlashUploader解决方案。

ftp将比http占用更少的带宽,因为后者需要将二进制内容编码(base64)为纯文本,从而增加总传输大小。(1/3)。

然而,与HTTP占主导地位的可用性和安全性等其他因素相比,带宽消耗可能不一定是主要关注的问题。