![WAN 上的 scp 传输速度慢](https://linux22.com/image/8691/WAN%20%E4%B8%8A%E7%9A%84%20scp%20%E4%BC%A0%E8%BE%93%E9%80%9F%E5%BA%A6%E6%85%A2.png)
我有一条 300mbit 对称光纤线路,并且必须将 51MBYTE tar 文件从主机 A(光纤 300mbit)传输到主机 B(具有超过千兆位带宽的 digitalocean 机器)。
在两侧,我都得到了不错的速度测试结果(A 为 300mbit,B 为 700),但是当我从 A 到 BI 进行 scp 时,得到了以下结果:
assets.tar 100% 51MB 220.3KB/s 03:55
最高速度只有220kbit。
但如果我从 HOST B 到 AI 这样做,就会得到一个非常好的结果:
assets.tar 100% 51MB 8.4MB/s 00:06 ***REALLY GOOD SPEED***
可能是什么问题?
答案1
如果使用 openssh 或某些衍生工具,请检查您的 sshd 和 sshIPQoS
默认值。
IPQoS
默认为lowdelay throughput
before version V_7_8_P1
,然后更改为af21 cs1
(第一个是用于交互式会话的 TOS 标记,第二个用于批量传输)。
在我们的 WAN 路由上(即使在我们提供商的 LAN 内),CS1
优先级非常低,导致 和通过 ssh 的传输速度scp
非常sftp
差rsync
。改IPQoS
回之前的默认设置为我们解决了这个问题。
有关更改的详细信息和原因,请参阅openssh 提交信息。
不要依赖您的 openssh 软件包版本,某些发行版显然决定保留旧的默认值。对我们来说,受影响的发行版是从版本 8 开始的所有基于 Redhat 的发行版(即 CentOS、AlmaLinux、RockyLinux)。
通过 检查您的 sshd 配置sshd -T | grep -i IPQoS
。
要测试,请尝试scp -o IPQoS=throughput …
。
要永久恢复到以前的默认设置:
添加
/etc/ssh/sshd_config
:IPQoS lowdelay throughput
添加默认或特定主机规则
/etc/ssh/ssh_config
,例如:Host * IPQoS lowdelay throughput
通过 激活新配置
systemctl reload sshd
。
YMMV 并取决于您的实际网络拓扑和策略,af21
也应该更适合交互式会话,因此我建议测试不同的 TOS 标签。
答案2
SCP 是一个非常简单的工具,可以简单地来回复制文件。它并不是为超快速度而设计的,而且两侧的缓冲区都非常小。
如果您的目标是性能,则应该使用sftp
或rsync
。
关于速度测量,我们画一些图:
[host A] --- ??? mbit --- [host B]
\ /
\ 300 mbit / 700 mbit
\ /
[speedtest server]
两台主机之间的数据不必经过您测量速度的速度测试服务器(它们可能不会经过),因此这些措施与您的情况无关。如果您想测量这两个主机之间的速度,您确实需要测量这两个主机之间的流量,而不是其他任何东西。可能有一些线是不对称的或以不同的方式限制的。
答案3
我首先会测量最愚蠢的 TCP 流的速度。普通的 FTP(不是 SFTP 或 FTPS)就可以做到。如果由于某种原因 FTP 无法工作(防火墙可能是一个问题),请尝试 netcat。
FTP 只是字面上向套接字发送字节。只要它使用完整的 TCP 数据包大小,并且我们讨论的是单个文件,您就无法更有效地使用 TCP。因此,这将为您提供两台主机之间可以实现的目标的基准。
(有一些基于 UDP 的协议可以通过避免等待 TCP ACK 数据包而在 WAN 上运行得更快,但这些都不是常用标准)。
但请注意,FTP 不压缩,因此对于某些类型的数据可能需要更长的时间。这有利于我们测量原始 TCP 吞吐量的目标。
如果 FTP 也很慢/不对称,那么可能只是这些机器之间的路径上存在不对称链路。您可以通过在两端运行 Wireshark 嗅探器并检查丢失数据包等的跟踪来进行进一步的诊断。
如果 FTP 速度快且对称,那么您还会遇到其他问题。不深入钻研,很难猜测,而且还有很多可能性。例如,一台计算机的 SSH 可能配置为压缩,而另一台计算机则不配置。