FTP 已死。該換什麼了。

你付錢買了一條 gigabit 線路。你開一個 FTP 傳輸到全國另一頭的辦公室，它卻只用 7 MB/s 慢慢爬。跨洲更糟。於是你做了所有人都會做的事——開始怪東怪西。

問題不在你的 ISP、你的硬碟，也不在你的路由器

隨便找一篇在抱怨 FTP 慢的討論串，每次都會看到同一套排查戲碼。有人換網卡。有人懷疑 NTFS 的開銷，把硬碟重新格式化。有人把那台兼差當 NAS 的路由器拔掉。有人跑 iperf3，確認線路真的能跑 900+ Mbps，於是把管線從嫌疑名單上劃掉。有人調高伺服器的連線數上限、關掉防毒和防火牆檢查。其中幾招甚至真的有一點點用。

然後他們把同一個傳輸放到 LAN 上跑——飛快；一跨過海洋，又掛了。這就是線索。瓶頸不在任何一端的硬體；它在中間那幾千公里，以及 FTP 為了跨越這段距離、至今仍依賴的那套 1970 年代的傳輸行為。

FTP 很老。不是「看起來有點年紀」那種老——是真的老。RFC 114 在 1971 年發表，比 TCP 本身還早六年。它是為 ARPANET 設計的，給那些隔著房間互相說話的機器用，不是給整個星球用。

這段歷史很重要，因為這個協定最痛的行為——對延遲的敏感——在它被設計時根本不是個議題。在 LAN 上你不會注意到。跨洲時，它就是整個瓶頸。

把頻寬延遲乘積講白

單一連線的 TCP 吞吐量被一條公式所限——這條公式每個網路工程師都學過、多數應用程式開發者一輩子沒看過：

throughput ≤ window_size / RTT

這就是 頻寬延遲乘積（bandwidth-delay product） 的天花板。「視窗」是 TCP 在停下來等 ack 之前，可以維持多少 in-flight 的資料。「RTT」是來回時間。

預設 64 KB 視窗加上 80 ms 跨大西洋 RTT，你的絕對天花板大約是 800 KB/s——大概 6 Mbps。在一條 10 Gbps 連線上，你用了 0.06% 的可用容量。剩下 99.94% 是電線坐在那邊發呆，等一個還在路上的 ack。

這不是 FTP 專屬的 bug。是 TCP 單一連線的 bug。每個 TCP-based 協定——FTP、SFTP、HTTP/1.1、HTTP/2 跑在單一連線上——都繼承了這個問題。

SFTP 沒有修

大家會伸手拿 SFTP，以為自己升級了。在資安這條軸上是有，在速度這條軸上沒有。

SFTP 在結構上是 FTP 的現代替代品——但它仍然是 packet-oriented 跑在 TCP 上。Client 送一個讀/寫請求、等回應、再送下一個。在 1 Gbps 的 LAN 上它能爽快推到 100+ MB/s。跨大西洋連線、同一個協定、同一個 client，吞吐量通常落在 5 到 30 MB/s 之間，往往更低。

就算 TCP 調到完美——視窗縮放、BBR、jumbo frames、SACK，整套全上——單一連線在長距離連線上通常很難突破 20% 的利用率。那就是現實的天花板。

實務上比這更糟。FileZilla 透過 SFTP 在 400 Mbit 民用管線上大約穩定在 1.1 MB/s——大約 2% 的線速。把一台 10 Gbit 伺服器擺在來源端、目的端是一台 1 Gbit client，跑 SSH/SFTP，每個 session 的吞吐量常常連 1 MB/s 都過不去。磁碟沒事。CPU 閒著。網路還有餘裕。整個瓶頸就是這個協定。

最乾淨的看法，是把其他東西全部固定、只變換工具。同一個來源、同一個目的端、同一個網路：FileZilla 透過 SFTP 拉到大約 1.5 MB/s。rsync 拉到大約 13 MB/s。wget 拉一個檔案是 17 MB/s。aria2c 把同一個檔案拆成多個並行 HTTP range，拉到 35 MB/s。唯一改變的就是並行度，吞吐量跳了大約 20×。

這就是市面上每個 UDP-based 快速傳輸產品背後完整的架構洞察：別再送一條串流然後等它；送很多條，並行，且不要等。

rsync 在一個特定情境下有救

rsync 值得單獨提一筆，因為在 一個 情境下它的確打趴幾乎所有東西：當目的端已經存在一個部分或較早版本的檔案時。rsync 比對區塊雜湊、用 gzip 壓縮，只送 delta。如果你在更新一個 10 GB 的資料集、其中 9 GB 沒變過，rsync 就只送 1 GB。完。

但對 全新 傳輸——乾淨的目的端、沒有前置狀態——rsync 受到跟其他東西一樣的 TCP 瓶頸限制。它是「在慢管子上聰明同步」，不是「快管子」。

那些快速協定到底做了什麼

每個現代快速傳輸系統最後都收斂到差不多一樣的架構。名字不同——FASP（Aspera）、AFTP（bTrade）、GridFTP、UDT、FileCatalyst，還有我們自己的引擎——但動作都一樣：

1. 跑在 UDP 上，不是 TCP。 跳過「等 ack 再送」的舞步。把資料推出去；可靠性另外處理。
2. 在 userspace 實作自訂壅塞控制。 為高 BDP 連線調校，不是 TCP 出廠那組保守預設值。
3. 使用多條並行串流。 單一 UDP flow 在路由器上一樣會碰到公平性限制；很多條並行 flow 會聚合著繞過去。
4. 送之前先把小檔案打包成 chunk。 每次握手的懲罰就消失了。

調得好的那些報出來的成績：在 SFTP 只跑出 5-20% 的連線上，可以做到 90-95% 的頻寬利用率。 這就是「還在用 FTP 純粹因為慣性」與「真的把你的管線塞滿」之間的數量級差距。

FTP 在哪些情況還合理

老實說？很少。

• 在 LAN 上，跑在你動不了的老舊硬體上 ——可以。
• 一次性的內部腳本，速度不重要 ——可以。
• 其他所有情況，特別是任何跨洲的事 ——你每週、每個工作流，永遠都在付一份用「小時」計算的延遲稅。2025 年了，沒人應該還在付這個。

WarpSend 跑的就是上面那個架構。每月 1 TB 免費。如果你在讀這篇文章的同時，正在等一個 FTP 傳輸跑完，那本身就告訴了你一些事。