WarpSend 比 FTP 快 618× 是怎麼做到的

618×。在我們的基準測試裡，WarpSend 傳輸 1,024 個小檔案的速度，就是比 FTP 快這麼多——美東到法蘭克福，真實機器，真實網路條件。

如果這個數字聽起來灌水，合理——多數「快 N 倍」的行銷在你追問「比什麼快？什麼情境下？」的當下就崩了。所以下面是完整的數學。

測試設定

兩台機器。一台在 us-east-1，一台在 eu-central-1。兩端都是乾淨的連線——沒有流量整形、沒有人為上限。兩個情境：

1. 一個 1 GB 的單一檔案（簡單模式）
2. 1,024 × 1 MB 檔案（困難模式——總位元組數一樣，協定行為完全不同）

同一個來源、同一個目的端、同一個網路。只換傳輸引擎。

為什麼 TCP 在這種距離下是錯誤工具

這是 long-fat 網路的問題，課本級的。

us-east-1 與 eu-central-1 之間的來回時間（RTT）大約 85 ms。單一 TCP 連線的吞吐量被以下公式所限：

throughput ≤ window_size / RTT

這就是 頻寬延遲乘積（Bandwidth-Delay Product） 的天花板。預設 64 KB 接收視窗、85 ms RTT 之下，你只能跑到大約 750 KB/s——不管這條連線實際上有多少容量。在一條 10 Gbps 的管線上，那是 0.06% 的利用率。剩下 99.94% 就放著爽。

你可以在核心端硬幹這件事。更大的接收緩衝區、視窗縮放、用 BBR 取代 CUBIC、SACK、TCP offload。全都是真的，全都有用，全都很複雜，全都得逐台調。而且 BBR——大家伸手就拿的那個壅塞控制演算法——會隨 RTT 增大而劣化。在跨洲場景，它不是萬靈丹。

就算把所有東西都調好，單一 TCP 串流在長距離連線上通常很難突破 20% 的利用率，過了那條線你就開始跟路由公平性硬碰硬。這就是 FTP、SFTP 與 rsync 共同的天花板。

小檔案問題讓情況更糟

那個 618× 的結果，不只是 TCP 延遲的問題。是當你丟一千個檔案給 FTP（而不是一個大檔）時，它會做出的反應。

FTP 每傳一個檔案就開一條新的資料連線。每條新連線都需要 TCP handshake——三個來回才能讓第一個 byte 的 payload 動起來。85 ms RTT 之下，那是 每個檔案 ~255 ms 的死亡時間。

1,024 files × 255 ms = 261 seconds of handshake alone

光是 handshake 就超過四分鐘的純額外開銷，資料還沒離開來源端。SFTP 在這裡也沒有意義上的改善——它一樣是 packet-oriented 跑在 TCP 上，每個 chunk 一樣有類似的「讀—回 ack」循環。瓶頸不是頻寬，是這場對話本身。

WarpSend 怎麼做

三個改變，相乘起來：

1. UDP 傳輸 + 自訂可靠性。 封包之間不再等 ack。我們的引擎用自己的方式處理遺失偵測、重傳與順序。這跟 FASP（Aspera）、AFTP（bTrade）、GridFTP、UDT 共同採用的架構動作完全一樣——它們沒人是基於 TCP，理由也一樣。代價是我們這邊要寫更多 code。回報是壅塞控制變成我們可以自己調的東西。

2. 封包封裝（packet packing）。 傳輸前，我們會掃過小檔案、把它們捆成大塊。一千個 1 MB 檔案不會產生一千次 handshake——它們會被打成一條串流、在內部做框架。每檔開銷幾乎歸零。

3. 多執行緒管線。 掃描、封裝、加密與傳送全部並行跑。傳送執行緒不會卡在等磁碟；磁碟也不會卡在等網路。

結果：在 1,024 檔案測試裡，WarpSend 大約 21 秒完成，FTP 花了超過 3.5 小時。在單一 1 GB 檔案上，差距比較小——15 秒 對上 ~85 秒——因為 TCP 在這時候得以把它的 handshake 攤提到更多資料上。

在哪些場景最有感

618× 這個數字，最有切身感的場景，是你經常搬「大量」檔案：

• 一天拍攝下來的原始素材（剪輯師整併前往往是幾百個小 clip）
• 辦公室之間的專案資產（npm 那種帶幾千個小檔的樹狀結構）
• NAS 到 NAS 的備份與複寫
• ML 訓練資料集（往往是幾百萬個小 tensor）

任何符合「總共才 1 GB 看起來沒事，為什麼要跑三小時」這種輪廓的東西——那就是 FTP 的小檔懲罰跑進你工作流裡的樣子。

如果你寧可看比讀更直接，免費試試看——每月 1 TB 流量，免信用卡。