比较传输文件的 HTTP 和 FTP

小开

这是两者的性能比较。HTTP 对于小文件的请求-响应更具响应性，但是如果适当地调优，FTP 对于大文件可能更好。FTP 过去通常被认为是更快的。FTP 要求除了 TCP 状态之外还要维护控制通道和状态，但 HTTP 不需要。在数据开始以 FTP 方式传输之前，有6次数据包传输，但在 HTTP 方式只有4次。

我认为适当调优的 TCP 层比应用层协议之间的差异对速度的影响更大。太阳蓝图了解 TCP 优化有详细信息。

这里是另一个很好的比较的每个协议的个别特征。

小开

一个需要考虑的问题是 FTP 可以使用非标准端口，这可能使得通过防火墙变得困难(特别是如果您使用 SSL)。HTTP 通常位于已知端口上，因此这很少是个问题。

如果您决定使用 FTP，请确保阅读有关主动和被动 FTP的内容。

就性能而言，最终它们都是直接向 TCP 连接喷出文件，因此应该是大致相同的。

小开

许多防火墙丢弃了不连接到端口80或443的出站连接; 有些甚至丢弃了连接到那些非 HTTP (S)端口的连接。FTP 可能被允许，也可能不被允许，更不用说活动/PASV 模式了。

此外，HTTP/1.1允许更好的部分请求(“只从字节123456发送到文件末尾”)、条件请求和缓存(“只在内容发生变化/如果上次修改日期发生变化时发送”)和内容压缩(gzip)。

通过代理使用 HTTP 要容易得多。

根据我的轶事证据，HTTP 更容易处理掉落/缓慢/片状连接，例如，在(重新)启动传输之前，不需要(重新)建立登录会话。

OTOH，HTTP 是无状态的，因此您必须自己进行身份验证并建立“ who did what when”的线索。

我注意到的唯一速度差异是传输大量小文件: 使用流水线的 HTTP 传输速度更快(尤其是减少往返次数)。在高延迟网络上显而易见)。

请注意，HTTP/2提供了更多的优化，而 FTP 协议已经有几十年没有更新了(甚至 FTP 的扩展也没有得到用户的重视)。因此，除非您是通过时间机器传输文件，否则 HTTP 似乎胜出了。

(切题: 有一些协议更适合文件传输，比如 rsync或 BitTorrent，但它们没有那么多的思维共享，而 HTTP 是 Everywhere TM)

小开

它们都使用 TCP 作为传输协议，但是 HTTP 使用持久连接，这使得 TCP 的性能更好。

小开

我刚刚基准测试了 FTP 和 HTTP 上的文件传输:

超过两个非常好的服务器连接
使用相同的1GB. zip 文件
在相同的网络条件下(一个接一个地测试)

结果是:

使用 FTP: 6分钟
使用 HTTP: 4分钟
使用并发的 http 下载软件(fdm) : 1分钟

所以，基本上在“现实生活”的情况下:

1)下载一个大文件时，HTTP 比 FTP 快。

2) HTTP 可以使用并行块下载，根据网络条件的不同，它的速度是 FTP 的6倍。

小开

FTP 的一个优点是有一种使用 dir或 ls列出文件的标准方法。正因为如此，ftp 可以很好地使用诸如 Rsync之类的工具。当然，rsync通常是在 ssh上完成的，但也有选择。