跳到主要内容
文件传输协议故障排查 文件传输性能指南 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 的控制与数据连接架构。两者的客户端、连接端口、验证、防火墙行为与性能调整都不同。