FTP 已死。该换什么了。

你花钱买了一条 gigabit 线路。你开一个 FTP 传输,发到全国另一头的办公室,它却只用 7 MB/s 慢慢爬。跨大洲更糟。于是你做了所有人都会做的事 —— 开始怪这怪那。

问题不在你的 ISP、不在你的硬盘,也不在你的路由器

随便翻一篇抱怨 FTP 慢的帖子,每次都是同一套排查流程。有人换网卡。有人怀疑 NTFS 的开销,把硬盘重新格式化。有人把那台兼职当 NAS 的路由器拔掉。有人跑 iperf3,确认链路真的能跑 900+ Mbps,于是把管道从嫌疑名单里划掉。有人调高服务器的连接数上限、关掉杀毒和防火墙检查。其中几招甚至真的有那么一点点用。

然后他们把同一个传输放到局域网上跑 —— 飞快;一跨过大洋,又挂了。这就是线索。瓶颈不在任何一端的硬件;它在中间那几千公里,以及 FTP 为了跨越这段距离、到今天还在依赖的那套 1970 年代的传输行为。

FTP 是真的老。不是「有点上年纪」的老 —— 是字面意义上的老。RFC 114 发布于 1971 年,比 TCP 自己还早六年。它是为 ARPANET 设计的,那时候的机器是隔着一个房间互相说话,不是隔着一个星球。

这段历史很重要,因为这个协议最痛的那条行为 —— 它对延迟的敏感 —— 在它被设计的时候根本不是问题。在局域网里你感觉不到。跨大洲的时候,这就是全部瓶颈所在。

带宽时延积,说人话

一条 TCP 连接的吞吐量被一个公式卡死 —— 每个网络工程师都学过,但大多数应用开发者从没见过:

throughput ≤ window_size / RTT

这就是 带宽时延积 的天花板。「窗口」是 TCP 在等待确认之前,愿意在路上同时塞多少数据。「RTT」是往返时间。

默认 64 KB 窗口、80 ms 跨大西洋 RTT,你的绝对上限大约是 800 KB/s —— 大概 6 Mbps。在一条 10 Gbps 的链路上,你用掉的是 0.06% 的可用容量。剩下 99.94% 是那根线在那里发呆,等一个还在路上的 ack。

这不是 FTP 独有的 bug。这是 TCP 单连接的 bug。所有基于 TCP 的协议 —— FTP、SFTP、HTTP/1.1、单连接上的 HTTP/2 —— 全都继承了它。

SFTP 修不了这个

很多人换成 SFTP,以为自己升级了。在安全这条线上,是升级了。在速度这条线上,没有。

SFTP 结构上是 FTP 的现代替身 —— 但它仍然是 TCP 之上的数据包式协议。客户端发一个读/写请求、等回复,再发下一个。在 1 Gbps 的局域网上,它能轻松跑出 100+ MB/s。同样一个客户端,跑在跨大西洋链路上,通常卡在 5 到 30 MB/s 之间,经常更少。

就算 TCP 调到完美 —— 窗口缩放、BBR、巨型帧、SACK,全套 —— 一条连接在长距离链路上通常都很难突破 20% 的利用率。这就是现实的天花板。

实际情况只会更差。FileZilla 跑 SFTP,在 400 Mbit 的家用带宽上,稳定在 1.1 MB/s 左右 —— 大约 2% 的线速。源端放一台 10 Gbit 的服务器,目的端放一台 1 Gbit 的客户端,中间走 SSH/SFTP,单会话吞吐量经常都摸不到 1 MB/s。磁盘没问题。CPU 闲着。网络有余量。协议本身就是全部瓶颈。

最干净的看清方式,就是把其他变量都固定,只换工具。同一个源、同一个目的、同一个网络:SFTP 走 FileZilla 大约 1.5 MB/s。rsync 大约 13 MB/s。wget 单文件大约 17 MB/s。aria2c 把同一个文件分成很多个并行的 HTTP range,大约 35 MB/s。唯一变化的只有并行度,吞吐量直接跳了大约 20×。

这就是市面上每一个基于 UDP 的快速传输产品背后的全部架构洞察:别再发一条流然后等它;并行发很多条,而且不等。

rsync 在一种特定场景下有用

rsync 值得单独提一下,因为在 某一个 场景下,它真的能赢过几乎所有东西:目的端已经有一份这个文件的部分版本或较早版本。rsync 会比较块哈希、用 gzip 压缩,只发差分。如果你在更新一个 10 GB 的数据集,而 9 GB 没变,rsync 只发 1 GB。完事。

但对 全新 传输 —— 干净的目标、没有历史状态 —— rsync 一样被卡在那条卡所有东西的 TCP 上。它是「在一条慢管道上做的聪明同步」,不是一条快管道。

那些快协议到底在做什么

每一个现代的快速传输系统都收敛到差不多同一套架构。名字不一样 —— FASP(Aspera)、AFTP(bTrade)、GridFTP、UDT、FileCatalyst,还有我们自己的引擎 —— 但动作是一样的:

1. 跑在 UDP 上,不要 TCP。 跳过「发一个、等确认、再发下一个」的回合制。先把数据推出去;可靠性单独处理。
2. 在用户态实现自定义拥塞控制。 为高带宽时延积链路调过,不是 TCP 自带的那套保守默认值。
3. 使用多条并行流。 一条 UDP 流在路由器那里仍然会撞到公平性限制;多条并行流绕过去。
4. 传之前把小文件打包成块。 单次握手开销就消失了。

调得好的系统报出来的结果:90-95% 的带宽利用率,而 SFTP 只能看到 5-20%。 这就是「因为惯性还在用 FTP」和「真的把管道吃满」之间那一个数量级的差距。

FTP 还有意义的场合

老实说?很少。

• 局域网上,跑在你换不掉的老硬件上 —— 行。
• 一次性的内部脚本,速度无所谓 —— 行。
• 其他一切场合,尤其是任何跨洲的事 —— 你正在按工作流交一笔以小时计的延迟税,每周交,永远交。2025 年了,没人应该还在交这笔钱。

WarpSend 跑的就是上面那套架构。每月免费 1 TB。如果你边读这篇文章边在等一个 FTP 传输跑完,那应该已经说明了点什么。