為什麼 FTP 長距離傳輸很慢？原因與改善方法

同一份資料在辦公室內傳得快，傳到海外卻明顯變慢，通常需要同時檢查網路往返時間、TCP 設定與檔案數量。FTP 的效能不能只用方案頻寬判斷：單一大檔可能持續高速傳送，數千個小檔卻會花很多時間建立資料連線與處理檔案。

先用同一對端點測試一個大檔，再測試總容量相近的真實資料夾。這個對照能幫助你區分持續吞吐量不足與逐檔處理成本，避免調整與瓶頸無關的設定。

延遲如何限制吞吐量

TCP 可以在尚未收到確認時繼續傳送多個封包；可同時在途的資料量受接收視窗與壅塞視窗等因素限制。在視窗成為瓶頸時，可用以下關係估算上限：

throughput ≤ effective_window_size / RTT
bandwidth-delay product = bandwidth × RTT

例如，若有效視窗只有 64 KiB、RTT 為 80 ms，視窗造成的上限約為 0.82 MB/s。若想在相同 RTT 下維持 1 Gbps，則需要約 10 MB 的資料同時在途。這是容量規劃的示例，並非現代 TCP 的預設限制；TCP 視窗縮放早已允許更大的接收視窗。

實際速率還受封包遺失、壅塞控制、CPU、來源讀取與目的端寫入影響。即使區域網路測試很快，也不能直接排除硬體：長距離傳輸可能使用不同的加密、緩衝與儲存路徑。

FTP 傳小檔為什麼容易變慢

FTP 規格區分控制連線與資料連線。常見的串流 mode 會以關閉資料連線表示檔案結束，因此傳送下一個檔案時，需要再次準備資料連線。控制連線可以保留，並非每個檔案都重新登入。

單一大檔可以攤薄這些成本；大量小檔則會反覆付出協商與檔案操作的時間。跨洲 RTT 越高，串行執行的操作就越容易拉長總工時。可以先將一次性交付的資料夾封裝成封存檔，或測試有限的並行傳輸；兩者都要把打包、解包、儲存負載與完整性驗證算進完成時間。

SFTP 需要檢查另一層並行設定

SFTP 在 SSH 加密連線上執行檔案操作，與 FTP 是不同協定。它可以讓多個讀寫請求同時等待回應，並不是每傳一個區塊就必須停下來。

OpenSSH sftp 手冊提供 -R 調整同時未完成的請求數、-B 調整傳輸緩衝區。提高這些值可能改善高 RTT 路徑，但也增加記憶體使用量，且仍受伺服器支援與 SSH 處理能力限制。調整方法與驗證步驟見長距離 SFTP 加速指南。

TCP 或 SFTP 都沒有通用的「只能使用 20% 頻寬」上限。是否需要換工具，應以實際路徑上的完整傳輸時間判斷。

rsync 適合減少重複傳送的資料

如果目的端已有舊版本，rsync 的差分演算法可以減少需要傳送的內容。但掃描、讀取與比對也有成本；目的端沒有任何資料的第一次複製，通常無法獲得相同效益。壓縮則需明確啟用，已壓縮的影片或封存檔通常不適合再壓縮。

已有穩定 rsync 工作的團隊，可以先依WAN 上 rsync 慢速排查找出耗時階段，再決定是否更換傳輸路徑。

什麼時候值得測試加速傳輸

當上傳頻寬與儲存仍有餘裕，卻無法在交付窗口內完成資料夾傳輸時，可比較具有持續連線、小檔批次處理、續傳與完整性檢查的工具。UDP 加速協定會自行實作可靠性與流量控制；並行 TCP 工具也可能有效。協定名稱本身不足以保證結果。

WarpSend 的端點直傳適合在受支援裝置之間搬移完整資料夾。用同一份資料、同一對端點與相同安全要求，分別記錄 FTP、調校後方案與 WarpSend 的完成時間及中斷復原結果。若現有工具已能穩定達到要求，保留它通常更省維護成本。

你可以從長距離傳輸測試指南建立基準，再開始試用 WarpSend。UDP 端點速度方案與 WarpShare 上傳計費分開，現行方案見價格頁。