WarpSend vs FTP 基準測試：小檔案傳輸的 40 倍差距

跨國交付數百個小檔案時，時間往往花在檔案之間的等待，而不只是資料傳送本身。在既有的 256 個、每個 1 MiB 小檔案測試中，WarpSend 的整筆平均速率中位數約為 FTP 基準的 40 倍。要理解這個差距，需要看每個檔案傳送前後，工具還做了哪些工作。

這也是 WarpSend 批次處理特別能發揮作用的情境：一個包含許多獨立素材的專案資料夾。至於大型單檔，後續美國至德國的完成紀錄也已有超過 200 MB/s 的平均傳輸速度。

256 個小檔案，約 40 倍的速率差距

這組比較使用隨機產生的測試檔案，資料夾總容量為 256 MiB，傳輸方向為德國至美國，往返延遲約 143 ms。兩端皆為 Linode 伺服器，配置 2 vCPU 與約 4 GB 記憶體。FTP 基準使用 curl 搭配 vsftpd 進行被動模式上傳，並設定 BBR 與較大的 TCP 緩衝區。

三次 WarpSend 結果約為 FTP 基準的 38–42 倍，中位數比值為 24.6 / 0.61 = 40.3。這裡使用完整傳送命令的耗時計算，因此資料夾的準備與完成處理，也已計入結果。

測試紀錄採用 2026 年 7 月 10 日的 FTP 基準，以及同一路線上 7 月 11 日的 WarpSend 開發版本測試。FTP 未加密，WarpSend 則包含端點加密傳輸流程；約 40 倍的差距對應的是這組檔案與設定。

為什麼小檔案能拉開這麼大的差距？

一個由相機原始素材、專案檔、縮圖與中繼資料組成的資料夾，需要傳輸工具找到並處理其中每一個檔案。即使網路還有頻寬，檔案之間的短暫等待也會逐漸累積。這也是為什麼只看資料夾的總容量，還不足以估計交付時間。

FTP 使用分開的控制連線與資料連線，這個架構定義於 RFC 959。若用戶端為每個檔案建立資料連線，就會在整個資料夾的傳輸過程中反覆執行連線準備與完成確認。跨國路線上的往返延遲，可能讓連線在兩個檔案之間等待。用戶端如何處理連線，以及同時傳送多少檔案，都會影響這些等待能否重疊進行。

WarpSend 透過批次處理與重疊執行檔案處理階段，減少這類工作的空檔。前一批資料正在傳送時，後續檔案可以接續準備，讓傳輸持續進行。因此，評估一個專案的交付時間，除了總容量，也要看檔案數量與目錄結構；單一大檔的速度無法涵蓋整個資料夾的表現。

關於這個差異，可接著閱讀大量小檔案傳輸為什麼慢，以及 FTP 長距離傳輸變慢的原因。

大型單檔，也有超過 200 MB/s 的完成紀錄

以下三筆已完成傳輸皆使用 WarpSend 的 Tunnel 路徑，由 US-ContentServer 傳送至 DE-ContentServer。傳送的檔案為 large-2048mb.bin，介面顯示大小為 2.15 GB。

數值取自 WarpSend 傳輸歷史。速度使用十進位 MB/s，耗時依應用程式顯示取整數。這三筆紀錄呈現該路線當時的表現；其他路線的速度仍會受可用頻寬、端點硬體與儲存裝置影響。

這裡是應用程式記錄的大檔傳輸區間速度；前面的小檔表則採用整個命令的平均速率。兩組資料的檔案組成、日期與方向不同，各自用來說明對應工作負載的表現。

對專案交付的實際意義

單一大檔的速度，只呈現交付流程的一部分。相機附屬檔、縮圖、專案素材與其他小檔案，可能讓反覆準備的時間成為主要等待。小檔測試呈現的差距，正好說明減少這些重複工作有多重要：網路有頻寬，不代表資料夾就能持續快速傳送。

對大型成片，超過 200 MB/s 的紀錄呈現 WarpSend 在該美國至德國路線上的持續傳輸表現。對整個資料夾，批次處理與重疊執行的檔案處理流程，則有助於減少檔案之間的空檔。當交件內容同時包含影音素材與製作專案，這兩種能力都派得上用場。

WarpDirect可在安裝 WarpSend 的裝置之間傳送檔案，包含支援的桌面系統與 NAS。在兩端安裝 WarpSend後，選擇來源檔案與接收裝置即可開始。若要了解特定路線的網路與儲存限制，可參考長距離傳輸指南。