大量小檔案傳輸為什麼很慢？原因與加速方法
小檔案會逐筆重複 metadata、開關檔與網路往返。本文說明如何診斷瓶頸，並測試打包、持續連線與有限並行等改善方式。
同樣是 100 GB，一個影片檔可能很快傳完，含有數萬個素材的資料夾卻要等更久。差別在於每個檔案都需要列舉、開啟、讀寫中繼資料與建立目的檔案，有些操作還必須等待遠端回應。
先比較大檔、真實資料夾與封裝後的資料夾，再觀察網路、CPU 與磁碟使用率。這能判斷封裝、重用連線或有限並行是否有效，也能避免在儲存已飽和時繼續增加傳輸工作。
檔案數為什麼會改變傳輸時間
可以用這個模型理解：
總時間 ≈ 有效資料時間 + 檔案清單工作 + 逐檔成本 + 儲存工作 + 驗證
有效資料時間是大多數頻寬計算器顯示的部分。100 GB 通過持續 1 Gbps 路徑有可計算的下限，但資料夾不只有位元組。每個檔案可能需要：
- 讀取路徑、大小、權限與時間戳記。
- 開啟來源檔案。
- 宣告或協調下一次傳輸。
- 開啟或排程資料工作。
- 建立目的檔案。
- 傳送有效資料。
- 落盤、關閉並記錄完成。
- 視需要計算雜湊或驗證。
有些實作可以重疊這些步驟，有些大多串行。無論哪一種，檔案數越多，就有越多不會反映在總容量上的工作。
Microsoft 對 SMB 也記載同樣現象：小檔複製把較高比例時間花在建立檔案、通訊協定與檔案系統操作，而不是搬有效資料。Microsoft：SMB 檔案傳輸過慢
傳統 FTP 將控制連線與檔案資料連線分開，因此處理資料夾時可能反覆支付連線與協調成本。RFC 959：File Transfer Protocol
rsync 可以重疊執行檔案傳輸的不同階段，新版本也能在完整掃描前開始遞迴傳輸，但仍要列舉項目並處理中繼資料。請參考 rsync man page與WAN 上 rsync 過慢的診斷指南。
選擇修正方式前先診斷瓶頸
| 訊號 | 可能瓶頸 | 第一個控制測試 |
|---|---|---|
| 位元組開始移動前等很久 | 列舉、檔案清單、篩選規則或校驗碼 | 記錄第一筆有效資料時間與檢查的檔案數 |
| 大檔很快、資料夾很慢 | 逐檔中繼資料或串行協調 | 比較每秒檔案數與目的端 IOPS |
| 本機資料夾複製也慢 | 來源或目的端檔案系統 | 測量本機建立／開啟／關閉吞吐 |
| CPU 滿載、線路閒置 | 雜湊計算、加密、壓縮或掃描 | 一次只改一個 CPU 密集設定 |
| 網路與儲存都未充分使用 | 應用並行或等待 | 逐步增加有限並行 |
| 工作程序越多反而越慢 | 儲存、CPU、記憶體或佇列爭用 | 回到中位數最佳值，而非最高工作程序數 |
簡單的延遲範例
假設在 RTT 100 ms 的兩個端點間傳 100 GB：
- **工作 A：**一個 100 GB 檔案
- **工作 B：**100,000 個平均 1 MB 的檔案
有效資料總量相同，但檔案操作數完全不同。
如果每個檔案只多一個串行的網路往返，簡化後的等待時間就是：
100,000 個檔案 × 0.1 秒 = 10,000 秒
還沒算有效資料、磁碟、加密與驗證，就多出 2 小時 46 分鐘。實際工具可能會處理流程請求、重用工作階段或使用多條串流，因此這不是每個協定的預測；它只說明逐檔延遲為何重要。
同樣模型在 2 ms LAN 約為三分鐘；跨洲 100 ms 則以小時計。
實際複製大量小檔案的結果
2026 年 9 月，我們在德國與美國兩台 VM 之間（往返時間約 141 ms）複製 65,536 個 4,096 位元組的檔案，合計 268.4 MB。OpenSSH 的遞迴 SFTP 用戶端會逐一處理檔案，五次測試都沒有在 15 分鐘上限內完成。rsync 與透過 SSH 的 tar 串流不必等前一個檔案結束就能繼續送資料，兩者都以約 10 MB/s 完成。每次測試結果、另外進行的 TCP 與 QUIC 測試，以及這次設定的限制，請見大量小檔案傳輸實測。測試方法與記錄的結果也公開在基準測試研究頁（英文）。
小檔案傳輸背後的四個瓶頸
1. 逐檔網路往返
互動頻繁的協定會在步驟之間等待遠端確認或協調。距離把微小等待變成重複成本。
2. 檔案系統中繼資料與開關檔
來源必須列舉目錄並讀取中繼資料，目的端要建立項目、更新中繼資料並落盤。高速網路無法移除儲存 IOPS 上限。
3. 串行的雜湊計算、加密與排程
若工具先掃完整棵樹、再雜湊值全部、再加密，最後才開始送，階段之間網路會閒置。最慢的串行階段決定完整耗時。
4. 太小的有效資料無法填滿路徑
小檔可能在單一串流累積到足以利用高頻寬、高延遲路徑之前就結束。如果應用不斷暫停，標示 1 Gbps 也沒有意義。
先建立 ZIP 為什麼通常有效
把資料夾封裝後再傳，可以把大量檔案操作轉成一條連續串流。這也是系統管理經常建議 tar 或 ZIP 的原因。
但它只是把工作移到別處：
- 寄件端可能需要壓縮檔暫存空間。
- 收件端解壓縮時還需要一份空間。
- 封裝與解壓縮都增加總耗時。
- 一個檔案變更可能要求重建或重傳大型壓縮檔。
- 若工具沒有索引，續傳與驗證以整包為單位。
偶爾傳一次資料夾，封裝可能是最簡單答案。固定製作流程則應由傳輸系統自行處理批次封裝。
WarpSend 的並行封裝如何改善
WarpSend 把資料夾當成連續傳輸工作，而不是互不相關的上傳佇列。
並行封裝處理流程會重疊：
- 目錄掃描
- 內容雜湊計算
- 批次封裝與排程
- 加密
- 網路傳輸
- 目的端寫入
有限並行讓工作保持流動，不必把整個目錄載入記憶體。持續加密處理流程也能避免長距離路徑在每個檔案的單一步驟完成前閒置。
比較目前版本時，使用相同檔案、路線、儲存裝置與安全設定，分開記錄傳輸階段速度及取得驗證後檔案的完整交付時間。WarpSend 與 FTP 測試方法說明如何進行比較；FTP 結果也不能代表 SFTP 或 Aspera 的效能。
完整方法請見WarpSend 與 FTP 基準測試。
並行封裝何時有幫助、何時沒有
適合：
- 資料夾有數百或數千個檔案。
- 端點間 RTT 高。
- 固定傳送媒體素材、專案樹、資料集或 NAS 資料夾。
- 必須保留加密、續傳與驗證。
- 手動封裝與解壓的營運成本高。
幫助較小：
- 工作已經是一個大型連續檔案。
- 兩端都在同一低延遲 LAN。
- 儲存裝置比網路慢。
- 調校後傳輸已達路徑的實際上限。
乾淨路由上的單一大檔，調校後 FTP 可以非常快。檔案型態會改變比較結果。
如何測試自己的資料夾
準備總容量接近的三組資料：
- 一個大檔。
- 約 16 個檔案的中型批次。
- 1,000 或 100,000 個小檔的批次。
每輪記錄：
- 檔案數與平均大小
- 來源與目的端儲存
- 頻寬、RTT、封包遺失
- 加密與驗證設定
- 完成時間
- 傳輸階段吞吐量
- 密碼學驗證結果
每種工作量都要重複，回報中位數而非最快一輪。使用你實際要部署的路由與硬體。
規劃有效資料部分可用檔案傳輸時間計算器，距離影響請看長距離網路高速檔案傳輸。
用具代表性的資料夾開始 WarpSend 傳輸，再把完整耗時、驗證與復原行為和目前流程比較。
常見問題
為什麼大量小檔案比同容量的一個大檔慢？
每個小檔都會增加目錄列舉、中繼資料讀取、開關檔、目的端建立、排程與網路協調。一個大檔能把固定工作分攤到連續有效資料上，大量小檔則會重複數千次。
傳輸數千個檔案前應該先建立壓縮檔嗎？
壓縮檔可以把大量檔案操作轉成一條串流，適合一次性工作。但要把壓縮檔建立、暫存磁碟、解壓縮、續傳粒度與驗證都算進牆鐘時間。固定流程可能更適合保留檔案邊界的自動批次封裝。
增加並行傳輸一定能加速小檔案嗎？
不一定。有限並行可以重疊網路與儲存工作，但工作程序太多會爭用磁碟 IOPS、CPU、記憶體、檔案控制代碼與網路佇列。請逐步增加，當完成時間中位數不再改善時就停止。
如何對小檔案傳輸做基準測試？
用總容量接近的單一大檔、中型批次與真實小檔資料夾比較。記錄檔案數、儲存、RTT、封包遺失、CPU、加密、驗證、第一筆有效資料等待時間、牆鐘完成時間，以及重複執行的中位數。