比较 HTTP 和 FTP 文件传输
通过 Internet 传输文件时，其中一种方法相对于另一种方法有哪些优点（或限制）？
（我知道这两种协议的安全形式。我想听听个人经验在性能、可靠性、文件大小限制等方面的比较。）
What are the advantages (or limitations) of one over the other for transferring files over the Internet?
(I am aware of secure forms of both protocols. I'd like to hear comparisons through personal experiences in terms of performance, reliability, file size limitations etc.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
以下是两者的性能比较。 HTTP 对于小文件的请求响应响应速度更快，但如果调整得当，FTP 对于大文件可能会更好。 FTP 过去通常被认为更快。 除了 TCP 状态之外，FTP 还需要控制通道和状态维护，但 HTTP 不需要。 FTP 中数据开始传输之前有 6 个数据包传输，而 HTTP 中只有 4 个数据包传输。
我认为适当调整的 TCP 层对速度的影响比应用层协议之间的差异更大。 Sun 蓝图 了解调整 TCP 有详细信息。
这是每个协议各自特征的另一个很好的比较。
Here's a performance comparison of the two. HTTP is more responsive for request-response of small files, but FTP may be better for large files if tuned properly. FTP used to be generally considered faster. FTP requires a control channel and state be maintained besides the TCP state but HTTP does not. There are 6 packet transfers before data starts transferring in FTP but only 4 in HTTP.
I think a properly tuned TCP layer would have more effect on speed than the difference between application layer protocols. The Sun Blueprint Understanding Tuning TCP has details.
Heres another good comparison of individual characteristics of each protocol.
我刚刚对 FTP 和 HTTP 上的文件传输进行了基准测试：
结果：
fdm）：1分钟所以，基本上在“现实生活”情况下：
1) 下载一个大文件时，HTTP 比 FTP 更快。
2) HTTP 可以使用并行块下载，这使其比 FTP 快 6 倍，具体取决于网络条件。
I just benchmarked a file transfer over both FTP and HTTP :
The result:
fdm): 1 minuteSo, basically under a "real life" situation:
1) HTTP is faster than FTP when downloading one big file.
2) HTTP can use parallel chunk download which makes it 6x times faster than FTP depending on the network conditions.
许多防火墙会丢弃不是端口 80 或 443 (http 和 https) 的出站连接； 有些甚至会丢弃与非 HTTP(S) 端口的连接。 FTP 可能会也可能不会被允许，更不用说主动/PASV 模式了。
此外，HTTP/1.1 允许更好的部分请求（“仅从字节 123456 发送到文件末尾”）、条件请求和缓存（“仅在内容更改/如果上次修改日期更改时发送”）和内容压缩（gzip）。
通过代理使用 HTTP 更容易。
根据我的轶事证据，HTTP 更容易处理掉线/慢速/不稳定的连接； 例如，在（重新）启动传输之前不需要（重新）建立登录会话。
OTOH，HTTP 是无状态的，因此您必须自己进行身份验证并构建“谁在何时做了什么”的跟踪。
我注意到的唯一速度差异是传输大量小文件：带有管道的 HTTP 速度更快（减少往返，尤其是在高延迟网络上明显）。
请注意，HTTP/2 提供了更多优化，而 FTP 协议尚未看到任何更新几十年来（甚至 FTP 的扩展也没有被用户接受）。 因此，除非您通过时间机器传输文件，否则 HTTP 似乎获胜了。
（切题：有些协议更适合文件传输，例如 rsync 或 BitTorrent，但这些协议没有那么多的关注度，而 HTTP is Everywhere™）
Many firewalls drop outbound connections which are not to ports 80 or 443 (http & https); some even drop connections to those ports that are not HTTP(S). FTP may or may not be allowed, not to speak of the active/PASV modes.
Also, HTTP/1.1 allows for much better partial requests ("only send from byte 123456 to the end of file"), conditional requests and caching ("only send if content changed/if last-modified-date changed") and content compression (gzip).
HTTP is much easier to use through a proxy.
From my anecdotal evidence, HTTP is easier to make work with dropped/slow/flaky connections; e.g. it is not needed to (re)establish a login session before (re)initiating transfer.
OTOH, HTTP is stateless, so you'd have to do authentication and building a trail of "who did what when" yourself.
The only difference in speed I've noticed is transferring lots of small files: HTTP with pipelining is faster (reduces round-trips, esp. noticeable on high-latency networks).
Note that HTTP/2 offers even more optimizations, whereas the FTP protocol has not seen any updates for decades (and even extensions to FTP have insignificant uptake by users). So, unless you are transferring files through a time machine, HTTP seems to have won.
(Tangentially: there are protocols that are better suited for file transfer, such as
rsyncor BitTorrent, but those don't have as much mindshare, whereas HTTP is Everywhere™)考虑之一是 FTP 可以使用非标准端口，这可能会使穿过防火墙变得困难（特别是如果您使用 SSL）。 HTTP 通常位于已知端口上，因此这很少会成为问题。
如果您决定使用 FTP，请务必阅读主动和被动 FTP。
就性能而言，归根结底，它们都是直接通过 TCP 连接喷射文件，因此应该大致相同。
One consideration is that FTP can use non-standard ports, which can make getting though firewalls difficult (especially if you're using SSL). HTTP is typically on a known port, so this is rarely a problem.
If you do decide to use FTP, make sure you read about Active and Passive FTP.
In terms of performance, at the end of the day they're both spewing files directly down TCP connections so should be about the same.
FTP 的一个优点是有一种使用
dir或ls列出文件的标准方法。 因此，ftp 与 rsync 等工具配合得很好。 诚然，rsync通常是通过ssh完成的，但选项是存在的。One advantage of FTP is that there is a standard way to list files using
dirorls. Because of this, ftp plays nice with tools such as rsync. Granted,rsyncis usually done overssh, but the option is there.FTP 是从很久以前就有的； 在 2000 年初，我就使用它来代替 HTTP 来处理 Web 图片。 然后连接速度非常慢，一些 Mb 图片对于 HTTP 来说是一个沉重的负载，并且通常图片无法加载（因为连接失败）。 FTP 可以很好地完成这项工作...但是许多公司客户联系我，因为他们看不到这些图片，因为他们的防火墙不允许 FTP 连接。
现在，只有少数地方/原因可能需要使用 SFTP，甚至更少的 FTPS，因为需要额外的端口和防火墙配置，尽管 SFTP 可能需要更复杂的安全配置才能正确使用。 使用 SSH 然后使用 FTP 与使用 SFTP 相同。
FTP is from the old days; I've used it instead of HTTP for Web pictures in the 2000 early days. Then connections were very slow, and some Mb picture were a heavy load for HTTP, and often the picture didn't load (because of connection fails). FTP were fine to do the work... but many corporative clients contacted me because they couldn't see that pictures, as their firewall didn't allow the FTP connections.
Now there are only a few places/reasons where may make sense to use SFTP, and even less FTPS, because of the additional port and firewall configuration needed, although SFTP may need a more complex security configuration to be used properly. Using SSH and then FTP is just the same as using SFTP.
两者都使用TCP作为传输协议，但是HTTP使用持久连接，这使得TCP的性能更好。
Both of them uses TCP as a transport protocol, but HTTP uses a persistent connection, which makes the performance of the TCP better.