跳到主要內容
檔案傳輸協定疑難排解 檔案傳輸效能指南 WarpSend 工程技術與效能測試

如何加速長距離 SFTP 傳輸

調整 SFTP 並行請求數與緩衝區，測試壓縮效果，並找出拖慢長距離安全檔案傳輸的儲存或網路限制。

WarpSend 工程團隊 更新 5 分鐘閱讀

同一套 SFTP 在區網傳得快、跨國卻無法使用大部分頻寬時，可以先檢查用戶端同時處理的讀寫請求與緩衝區。高往返時間會放大等待，但 CPU、磁碟或伺服器限速也可能造成相似現象。

以下用 OpenSSH 示範如何建立基準，再分別測試請求並行度、緩衝區與壓縮。每次只改一項，記錄整項工作的耗時，才能判斷設定是否有效；其他用戶端的選項名稱可能不同。

SFTP 是什麼，又不是什麼

SFTP 是在加密 SSH 傳輸層上執行檔案操作的傳輸程式。OpenSSH 的官方 sftp 手冊記載了公開金鑰驗證、壓縮、遞迴複製、續傳、請求深度與傳輸緩衝區。

SFTP 不是「安全版 FTP」。傳統 FTP 使用一條控制連線，以及另一條傳送檔案內容的資料連線。RFC 959定義了這項架構，以及串流 mode 在檔案結束時關閉資料連線造成的連線管理問題。SFTP 改用 SSH 的加密連線與通道流量控制。RFC 4254則定義 SSH 通道視窗與最大封包大小，決定寄件端在等待調整前能搬多少資料。

FTP 與 SFTP 都可能因距離而變慢，但設定與失敗原因不同。

調校前要量測的五個上限

上限要記錄什麼常見訊號
網路路徑RTT、封包遺失、抖動、可用頻寬速率依路由或時段而變
SFTP 請求處理流程尚未完成的請求與緩衝區大小CPU 與磁碟都很閒，但線路利用率低
加密 CPU傳輸中的用戶端與伺服器 CPU連線尚未用滿，單一核心先飽和
儲存來源讀取、目的端寫入與 IOPS大檔快，但建立小檔時停滯
伺服器政策頻寬、工作階段、請求或儲存配額用戶端調整不再改變結果

至少測一個大檔與一個代表性資料夾。單一大檔能隔離串流路徑，資料夾則會顯示中繼資料、目錄遍歷、建立與開關檔、逐檔協調等成本。檔案數模型請見大量小檔案為什麼傳得慢。

如果現在用的是 SSH 上的 rsync，而不是互動式 SFTP，請改用WAN 上 rsync 過慢的調校指南；rsync 的檔案清單、快速檢查與差分傳輸決策需要不同診斷順序。

1. 謹慎增加尚未完成的請求

OpenSSH sftp 可用 -R num_requests 或 -X nrequests=value 控制同時進行的讀寫請求。文件列出的預設值是 64 個請求，提高數值可能增加速度，但也會增加記憶體用量。

不要直接跳到極端值，應逐步測試：

sftp -R 64 user@example.com
sftp -R 128 user@example.com
sftp -R 256 user@example.com

每一輪都使用相同檔案、路由、用戶端與伺服器。吞吐量不再上升、記憶體不可接受，或伺服器變得不穩時就停止。更多請求不會創造頻寬，只能在請求延遲是瓶頸時減少等待。

2. 測試較大的傳輸緩衝區

OpenSSH 文件記載 SFTP 緩衝區預設為 32 KB。-B buffer_size 或 -X buffer=value 可以變更一次讀寫操作使用的最大緩衝區。緩衝區越大，同一有效資料需要的往返次數越少，但會增加記憶體用量。

sftp -B 65536 user@example.com
sftp -B 131072 user@example.com

不存在通用的最佳值。用戶端版本、伺服器上限、SSH 通道視窗、記憶體與路徑行為都會影響結果。先保留預設請求數只改緩衝區，再分開測請求深度，才能知道改善來自哪個變數。

3. 把壓縮當成檔案型態測試

OpenSSH 使用 -C 開啟 SFTP 壓縮，並把 SSH 壓縮設定套到工作階段。OpenSSH 用戶端設定手冊指出壓縮預設關閉，且會套用到整條 SSH 連線的流量。

頻寬不足且 CPU 有餘裕時，紀錄、原始碼、CSV 或未壓縮文字可能受益。JPEG、MP4、ZIP 等已壓縮資料通常幫助很小，卻仍會消耗 CPU。請比較：

sftp user@example.com
sftp -C user@example.com

如果壓縮降低速度，或 CPU 增幅大於減少的傳送位元組，就保持關閉。

4. 重用工作階段並批次處理相關工作

重複驗證與建立工作階段會增加固定成本。排程工作可用 OpenSSH 的 -b batchfile，搭配適當的非互動驗證，在一條工作階段內執行多個 SFTP 命令。

大量小檔即使留在同一工作階段，檔案系統與逐檔工作仍可能占大多數時間。建立壓縮檔可以把資料夾轉為連續串流，但會增加壓縮檔建立、暫存空間、解壓縮與整包續傳的成本。固定工作流程應比較能保留檔案邊界並自動批次封裝的傳輸引擎。

5. 檢查 CPU、儲存與伺服器限制

若請求與緩衝區沒有效果，瓶頸可能不在 SFTP 處理流程。

  • **CPU：**兩端都要執行加密與完整性處理。記錄每個核心，而不只總 CPU。
  • **儲存：**建立小檔可能耗盡目的端 IOPS，網路則維持低利用率。
  • **網路丟包：**SSH 與 SFTP 通常跑在 TCP 上，丟包和重傳會降低傳送率。
  • **限速：**確認 SFTP 伺服器、帳號、閘道與上游連線沒有設限。
  • **額外跳躍：**跳板主機會增加一段路徑，也可能成為上限。

不要為了基準數字而弱化主機金鑰驗證、使用過時加密或停用完整性控制。調校必須保留當初選擇 SFTP 的安全特性。

可重複的 SFTP 基準測試

  1. 準備一個大檔與一個實際資料夾，每輪使用相同內容。
  2. 記錄用戶端與伺服器版本、硬體、儲存、路由、RTT、封包遺失和目前選項。
  3. 測量完整總耗時，不只看進度列峰值。
  4. 預設設定至少執行三次並採中位數。
  5. 變更請求深度、重測，保留最穩定的最佳值。
  6. 變更緩衝區、重測，保留最穩定的最佳值。
  7. 用真實檔案型態比較壓縮開與關。
  8. 中斷非正式環境傳輸，確認續傳與最終完整性。

有效資料時間下限可用1TB 傳輸時間計算器，路由設計與協定選擇請看長距離高速檔案傳輸指南。

何時調校 SFTP 就夠，何時該比較替代方案

如果 SFTP 能達到必要完成時間、符合既有自動化，也符合安全與存取模型，就繼續使用。它仍是普及且容易腳本化的選擇。

比較目前版本時，使用相同檔案、路線、儲存裝置與安全設定，分開記錄傳輸階段速度及取得驗證後檔案的完整交付時間。WarpSend 與 FTP 測試方法說明如何進行比較；FTP 結果也不能代表 SFTP 或 Aspera 的效能。

WarpSend 不會取代 SFTP 伺服器需求，也沒有實作 SFTP。它是給能安裝受支援端點，並需要直接傳輸、瀏覽器分享連結或代管資料夾同步的團隊使用的另一種流程。請先看 WarpDirect，再用 SFTP 基準的同一組檔案免費測試 WarpSend。

常見問題

為什麼 SFTP 在長距離連線上很慢？

常見限制包括往返延遲、封包遺失、保守的請求與緩衝區設定、SSH 加密的 CPU 成本，以及來源或目的端儲存。高速接取線路不會消除這些上限。請用同一組檔案測試，同時記錄 RTT、封包遺失、CPU、儲存吞吐量與完整耗時。

哪些 OpenSSH SFTP 設定可以改善速度？

OpenSSH 可用 -R 或 -X nrequests 控制尚未完成的請求數，用 -B 或 -X buffer控制每次請求的緩衝區。較大的值可減少高延遲路徑上的等待，但會使用更多記憶體；若瓶頸是 CPU、儲存、丟包或伺服器限制，則不會改善。一次只改一個設定再重測。

應該開啟 SFTP 壓縮嗎？

請實測，不要預設一定有幫助。頻寬受限而資料是可壓縮文字時可能有效，但壓縮會消耗 CPU，對 JPEG、MP4、ZIP 等已壓縮格式通常幫助很小。OpenSSH 預設關閉壓縮。

SFTP 和 FTPS 一樣嗎？

不一樣。SFTP 在加密的 SSH 傳輸層上執行檔案操作；FTPS 是受 TLS 保護的 FTP，仍保留 FTP 的控制與資料連線架構。兩者的用戶端、連接埠、驗證、防火牆行為與效能調整都不同。