WAN 上的 scp 传输速度慢

Question 1

如果使用 openssh 或某些衍生工具，请检查您的 sshd 和 sshIPQoS默认值。

IPQoS默认为lowdelay throughputbefore 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 标签。

Answer

如果使用 openssh 或某些衍生工具，请检查您的 sshd 和 sshIPQoS默认值。

IPQoS默认为lowdelay throughputbefore 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 标签。

Question 2

SCP 是一个非常简单的工具，可以简单地来回复制文件。它并不是为超快速度而设计的，而且两侧的缓冲区都非常小。

如果您的目标是性能，则应该使用sftp或rsync。

关于速度测量，我们画一些图：

[host A]   --- ??? mbit  ---    [host B]
        \                      /
         \ 300 mbit           / 700 mbit
          \                  /
           [speedtest server]

两台主机之间的数据不必经过您测量速度的速度测试服务器（它们可能不会经过），因此这些措施与您的情况无关。如果您想测量这两个主机之间的速度，您确实需要测量这两个主机之间的流量，而不是其他任何东西。可能有一些线是不对称的或以不同的方式限制的。

Answer

SCP 是一个非常简单的工具，可以简单地来回复制文件。它并不是为超快速度而设计的，而且两侧的缓冲区都非常小。

如果您的目标是性能，则应该使用sftp或rsync。

关于速度测量，我们画一些图：

[host A]   --- ??? mbit  ---    [host B]
        \                      /
         \ 300 mbit           / 700 mbit
          \                  /
           [speedtest server]

两台主机之间的数据不必经过您测量速度的速度测试服务器（它们可能不会经过），因此这些措施与您的情况无关。如果您想测量这两个主机之间的速度，您确实需要测量这两个主机之间的流量，而不是其他任何东西。可能有一些线是不对称的或以不同的方式限制的。

Question 3

我首先会测量最愚蠢的 TCP 流的速度。普通的 FTP（不是 SFTP 或 FTPS）就可以做到。如果由于某种原因 FTP 无法工作（防火墙可能是一个问题），请尝试 netcat。

FTP 只是字面上向套接字发送字节。只要它使用完整的 TCP 数据包大小，并且我们讨论的是单个文件，您就无法更有效地使用 TCP。因此，这将为您提供两台主机之间可以实现的目标的基准。

（有一些基于 UDP 的协议可以通过避免等待 TCP ACK 数据包而在 WAN 上运行得更快，但这些都不是常用标准）。

但请注意，FTP 不压缩，因此对于某些类型的数据可能需要更长的时间。这有利于我们测量原始 TCP 吞吐量的目标。

如果 FTP 也很慢/不对称，那么可能只是这些机器之间的路径上存在不对称链路。您可以通过在两端运行 Wireshark 嗅探器并检查丢失数据包等的跟踪来进行进一步的诊断。

如果 FTP 速度快且对称，那么您还会遇到其他问题。不深入钻研，很难猜测，而且还有很多可能性。例如，一台计算机的 SSH 可能配置为压缩，而另一台计算机则不配置。

Answer