文件从办公室电脑传到异地 Linux 服务器，速度只有每秒几兆，并不一定是网络故障。磁盘读写、加密计算、服务器负载、网络丢包，甚至单个小文件过多，都可能让传输表现变差。有效的远程文件传输速度瓶颈定位，应当先拆分变量，再做对照测试。

先看现象：速度慢属于哪一类

可以先观察传输曲线和资源占用。速度从开始就很低，且本地磁盘占用接近满载，优先检查本地磁盘；速度忽高忽低、延迟明显，重点查看网络链路；网络测试正常但服务器 CPU 或磁盘持续繁忙，则更可能是服务器性能限制。

第一步：排除本地磁盘因素

先不要使用远程协议，直接在源设备上做本地复制。Linux 可用 dd 或 cp 进行顺序读写对照；Windows 可用资源监视器查看磁盘活动时间、读取速度和响应时间。测试文件最好使用一个数 GB 的大文件，因为大量小文件会受到打开、关闭和元数据操作影响。

1. 记录从源盘读取文件时的持续速度，并观察磁盘活动时间。
2. 将同一文件复制到本机另一块磁盘，比较读取与写入速度。
3. 检查源盘剩余空间、健康状态和是否存在后台备份、杀毒扫描或压缩任务。

如果本地复制只有约 20 MB/s，远程传输不可能稳定超过这个水平。机械硬盘顺序读写通常低于 SATA SSD，碎片化、随机读写和小文件数量还会进一步拉低实际速度，因此不能只看接口标称带宽。

第二步：单独测网络链路吞吐量

文件传输工具同时受到协议开销和磁盘性能影响，所以应使用 iperf3 单独测网络。分别在客户端与服务器安装后，在服务器执行 iperf3 -s，客户端执行 iperf3 -c 服务器地址。测试期间暂停大规模传输，并尽量选择与实际传输相同的网络路径。

以千兆以太网为例，理论上限约为 125 MB/s，扣除协议、系统和设备开销后，稳定达到约 80–115 MB/s 并不罕见；跨地域公网、企业防火墙或高峰拥塞可能明显低于这一范围。若 iperf3 结果正常，而文件工具只有几 MB/s，就不应继续更换网线，而要检查协议、文件形态和两端存储。

延迟和丢包也要单独看

使用 ping 只能辅助判断延迟，不能代表完整带宽。可再用 traceroute 或 Windows 的 tracert 查看路径。少量丢包会让 TCP 反复重传，表现为速度周期性下降；跨洲链路即使带宽较大，较高往返延迟也会限制单连接传输效率。

第三步：检查服务器写入和协议开销

在服务器端同时观察磁盘、CPU 和内存。Linux 可使用 iostat 查看设备利用率与等待时间，使用 top 或 htop 查看进程负载。如果目标盘写入等待很高，继续增加并发连接通常只会让队列更长。

协议选择也会造成差异。SCP 配置简单，适合一次性复制，但加密和校验会消耗 CPU；SFTP 便于目录操作和权限控制，适合日常管理；rsync 能通过校验和与增量同步减少重复数据，适合多次同步，但首次传输仍要读取和发送完整内容。对大量小文件，先打包成归档文件再传输，往往比逐个发送更高效；不过归档会增加本地处理时间，也要考虑压缩带来的 CPU 消耗。

1. 用一个大文件测试单连接速度，确认基础吞吐量。
2. 再用同等总容量的小文件目录测试，比较文件数量带来的损耗。
3. 观察客户端和服务器 CPU；若 CPU 接近满载，可降低压缩级别、改用更高效的加密算法，或减少不必要的校验。
4. 分别测试目标本地磁盘写入和远程写入，判断限制是否出在服务器存储。

用对照表完成远程文件传输速度瓶颈定位

每次只改变一个条件，并记录文件大小、文件数量、协议、并发数、测试时间和两端资源占用。这样得到的结论才可复现。完成远程文件传输速度瓶颈定位后，再决定是优化磁盘、调整链路，还是更换传输方式，避免把服务器问题误判成网络问题。

常见问题

问：为什么测速很快，传文件仍然慢？

测速通常使用连续数据流，文件传输还会受到磁盘写入、协议加密、权限检查和文件数量影响，两者测量对象不同。

问：增加并发连接一定能提速吗？

不一定。链路有余量且单连接受延迟限制时可能有效；如果目标磁盘或服务器 CPU 已满，增加并发反而会降低整体速度。

问：大文件和小文件应采用同一种方法吗？

大文件适合直接使用 SCP、SFTP 或其他稳定传输方式；大量小文件可先归档，或使用支持增量和批量处理的同步工具。

问：测试时最容易忽略什么？

最常见的是忽略文件数量、后台任务和目标盘性能。测试应至少覆盖一个大文件和一组真实目录，并同步记录两端 CPU、磁盘与网络状态。