为什么 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 上传计费分开，现行方案见价格页。