FTP vs Web文件传输：2026年浏览器为何胜出
FTP与现代Web文件传输对比。了解基于浏览器的加密传输为何在安全性和易用性上取代传统FTP。
基于浏览器的 Web 传输已经在几乎所有非遗留工作流中全面取代 FTP。FTP 定义于 RFC 959（1985 年），默认在 TCP 端口 21 上以明文传输凭据和文件内容。现代 Web 传输运行在 TLS 1.3 之上的 HTTPS，在客户端用 AES-256-GCM 加密文件，收件人只需一个浏览器，无需任何额外设置。FileZilla 的安装计数器依然在走，但纯 FTP 的新企业部署已几近消失。SFTP 和 FTPS 在服务器间自动化场景中继续存活；人工交互传输已经迁移到 Web。
FTP 的设计初衷
FTP 假设网络是可信的。RFC 959 规范发布于 1985 年 4 月，早于商业互联网——NSFNET 直到 1988 年才对公众开放。端口 21 承载命令通道，端口 20 承载数据，一切以 ASCII 或二进制模式流动，没有任何密码保护。NAT 穿透是十年后才加上去的事后诸葛亮，由此产生了"被动模式"。
该协议的年龄体现在各种奇怪的设计上。主动模式与被动模式的混淆、防火墙讨厌的独立控制连接与数据连接、用户名和密码以明文字符串传输、没有原生完整性校验。一次经过故障路由器的传输可以静默损坏一个 .zip 文件而不报任何错误。
纯 FTP 为何实际上已被废弃
各大浏览器分批次移除了 FTP 支持。Chrome 在版本 95（2021 年 10 月）中删除，Firefox 在版本 90（2021 年 7 月）中删除，Safari 从未真正提供过交互式 FTP 支持。这意味着 ftp://files.example.com/report.zip 这样的链接对大多数用户已经失效——他们需要安装 FileZilla、Cyberduck 或 WinSCP 才能取回一个文件。
合规框架给它的命运按下了确认键。PCI DSS 4.0 第 4.2.1 节要求在公共网络上传输持卡人数据时使用强密码加密。HIPAA 技术保障措施 45 CFR 164.312(e)(1) 要求对 ePHI（电子受保护健康信息）的传输进行加密。纯 FTP 两项都不满足，审计人员一眼就会标记出来。
SFTP 与 FTPS 是两回事
人们经常混淆它们。SFTP（SSH 文件传输协议）运行在 SSH 端口 22 上，使用 SSH 认证，尽管名字里有"FTP"，但与 FTP 协议没有任何关系。FTPS 是在 TLS 上包装的 FTP，使用端口 990（隐式）或端口 21 加 AUTH TLS（显式）。两者是不同的东西，故障模式也不同。
SFTP 是服务器间自动化传输的更好选择——单一连接、对防火墙友好，并与团队已经用于基础设施的 SSH 密钥管理集成。FTPS 给一个仍受双连接和 NAT 复杂性困扰的协议加了 TLS，并没有根本改变其架构问题。
Web 传输替代了 FTP 的哪些用途
现代 Web 传输服务处理了 FTP 历史上所有权的用例：
- 一次性向客户交付文件（以前是共享 FTP 账户）
- 供应商文件投递（以前是只写入的匿名 FTP 文件夹）
- 合作伙伴公司之间的大文件交换（以前是 VPN 加 FTP）
- 向终端用户分发软件（以前是公开 FTP 镜像）
不同之处：无需账户预配置，无需防火墙规则，无需客户端软件安装，且默认端到端加密。
架构对比
| 维度 | FTP（纯文本）| FTPS | SFTP | Web 传输 | |---|---|---|---|---| | 端口 | 21、20 | 990 或 21 | 22 | 443 | | 加密 | 无 | TLS | SSH | TLS 1.3 + 客户端 AES-256-GCM | | 所需客户端 | FileZilla/WinSCP | FileZilla/WinSCP | OpenSSH/WinSCP | 仅浏览器 | | 防火墙友好性 | 差（双通道） | 差 | 好 | 好 | | 断点续传 | 视服务器而定 | 视服务器而定 | 是 | 是（tus/分块） | | 认证模型 | 用户名/密码 | 用户名/密码 + 证书 | SSH 密钥 | 链接 + 可选密码 | | 2026 年最佳用途 | 已废弃 | 遗留集成 | 服务器自动化 | 人工文件共享 |
被大多数人忽略的延迟问题
FTP 在某些客户端中每次下载打开一个 TCP 连接。通过 FTP 传输 10,000 个小文件意味着 10,000 次 TCP 握手。这就是为什么用 FTP 备份 .git 仓库慢得像爬，而同样的数据通过 HTTP/2 多路复用只需一小段时间。
HTTPS 配合 HTTP/2 或 HTTP/3（QUIC）可以在单个连接上多路复用多个文件请求，大幅降低往返开销。使用 tus.io 等协议的分块上传 Web 传输服务，在连接中断后能从精确的断点恢复，而纯 FTP 在不同服务器上对此的处理并不一致。
FTP 顽强存活的场景
广播自动化系统仍然通过 FTP 向附属电视台推送内容，因为 Grass Valley 或 Ross Video 等厂商的播出设备是在 FTP 时代设计的。传统零售系统通过 FTPS 推送每晚的 .csv 库存转储文件到总部。高校机构运行匿名 FTP 镜像用于软件归档（尽管大多数已迁移到 HTTPS 等效方案）。
服务器间自动化场景特别适合 SFTP。一个通过 SSH 密钥认证将夜间备份投递到加固 SFTP 隔离区的定时任务，在 2026 年仍然是良好架构。消亡的是人工操作的 FTP。
Web 传输明显胜出的场景
任何涉及非技术收件人的场景。客户不会安装 FileZilla。外部审计师不会配置 FTPS 设置。监管机构需要收据和基于链接的交付证明。对于 PR 机构发送新闻资料包、律师事务所交换证据开示材料、设计工作室向客户发送 .psd 文件来说，浏览器内的链接是唯一无需 IT 支持工单就能运作的交付方式。
HexaTransfer 代表了这一转变——上传最多 10 GB 的文件，分享链接，收件人通过浏览器下载。无需预配置或回收 FTP 凭据。
安全态势
纯 FTP 会将凭据暴露给网络上任何被动监听者——机场 Wi-Fi、酒店网络、共享办公基础设施。FTPS 和 SFTP 修复了传输层，但仍然让服务器运营商在端点解密后以明文访问文件内容。
具有零知识加密的 Web 传输服务在文件离开浏览器之前就在客户端完成加密。服务器只存储密文。即使服务器遭到完全入侵，没有存放在 URL 片段中的每文件密钥，暴露的数据也毫无用处。这在安全态势上比 FTPS 能提供的要坚实得多。
迁移路径
如果你还在运行 FTP 用于外部文件交付，迁移通常比较简单。识别工作流（客户交付、供应商收件、合作伙伴交换），选择符合文件大小和合规要求的 Web 传输服务，等流量干涸后停用 FTP 服务器。自动化服务器任务迁移到使用 SSH 密钥认证的 SFTP——这一部分在过渡中得以保留。
结论
FTP 运行了 40 年。它输掉了竞争，因为 Web 协议栈解决了 FTP 解决的所有问题，还额外提供了加密、防火墙友好性，以及通过已经预装在每台设备上的浏览器实现的通用客户端支持。对于新的交互式文件共享，使用 Web。对于自动化服务器管道，使用 SFTP。把纯 FTP 和传真机放在同一个架子上吧。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。