1Gbit LAN 上的 scp 性能

Question 1

从理论上来看，它确实看起来很慢，尽管我在家用硬件上实际上没有看到任何传输速度更快。

您可能想尝试一些实验来排除可能的限制因素：

/dev/zero通过从复制到来评估您的原始 SSH 速度/dev/null。这排除了高清瓶颈。
```
ssh remote_host cat /dev/zero | pv > /dev/null
```
检查其他未加密的协议，例如 HTTP。 HTTP 实际上只发送一个标头来发送文件。通过 HTTP 发送大文件是 TCP 速度的合理衡量标准。
检查您是否没有强制流量通过路由器，而只是通过以太网交换机。例如，如果您的计算机有公共 IP 和本地 IP，则 scp 到/来自本地 IP。这是因为家庭路由器通常必须通过其 CPU 处理 WAN 流量，这会造成瓶颈。即使两台机器都在 LAN 上，使用公共 IP 也可以强制数据包通过 CPU，就像数据包要发送到 WAN 一样。
同样，我会使用 IPv4。一些家庭路由器对 IPv6 有一个奇怪的行为，它们要求将所有本地流量转发到路由器。
如果可能的话尝试使用千兆交叉电缆而不是路由器。这应该排除路由器。

Answer

从理论上来看，它确实看起来很慢，尽管我在家用硬件上实际上没有看到任何传输速度更快。

您可能想尝试一些实验来排除可能的限制因素：

/dev/zero通过从复制到来评估您的原始 SSH 速度/dev/null。这排除了高清瓶颈。
```
ssh remote_host cat /dev/zero | pv > /dev/null
```
检查其他未加密的协议，例如 HTTP。 HTTP 实际上只发送一个标头来发送文件。通过 HTTP 发送大文件是 TCP 速度的合理衡量标准。
检查您是否没有强制流量通过路由器，而只是通过以太网交换机。例如，如果您的计算机有公共 IP 和本地 IP，则 scp 到/来自本地 IP。这是因为家庭路由器通常必须通过其 CPU 处理 WAN 流量，这会造成瓶颈。即使两台机器都在 LAN 上，使用公共 IP 也可以强制数据包通过 CPU，就像数据包要发送到 WAN 一样。
同样，我会使用 IPv4。一些家庭路由器对 IPv6 有一个奇怪的行为，它们要求将所有本地流量转发到路由器。
如果可能的话尝试使用千兆交叉电缆而不是路由器。这应该排除路由器。

Question 2

1Gbit LAN 上的正常 scp 传输速度是多少？

112 兆字节/秒

与 Micosoft Windows 弹出窗口或scpLinux 中一样，复制速度以每秒 MB（兆字节）为单位报告。请注意不要将其与网络速度以每秒位数报告。 让我们从现在开始标准化，复制速度应该以每秒字节数 (MB/s) 为单位，而不是每秒位数 (Mb/s)

理由：

每秒 1 GB = 每秒 1000 兆位 (mbps)；这是宣传的网络速度。
1000 Mbps / 8 = 125 MB/s（每秒字节数）理论的最大预期值。
我在 1gpbs 有线网络上观察到稳定的 112 MB/秒（并且从未见过更大的速度）；计算出效率为 89.6%，看起来很合理。
- 这是scp在linux下，从linux到linux系统
- 这也适用于来自 linux 的 samba 共享，在 microsoft windows 中的复制弹出窗口中也报告了稳定的 112 MB/秒
- 在过去的 10 年里，我在 Windows 7 及更高版本中观察到了这一点，现在使用 RHEL/CentOS 7.x，在工作中的有线 1gbps 网络（思科企业交换机）上，网络和计算机上无疑还有其他流量，我正在做转移。还有一个 10 美元的 Tigerdirect 4 端口有线交换机。
我不认为 SSH 会导致过多的开销，因为从 Windows 到 Linux 通过 Samba 传输时也观察到了同样的约 10% 的损失（从 125 MB/秒下降到 112 MB/秒）。在我看来，这约 10% 的损失（从 125 MB/秒下降到 112 MB/秒）只是 TCP/IP 开销。我从未见过比 112 MB/秒更好的情况。
在传输开始时，我有时会看到高达 115 MB/秒，并且可能会在 110-115 之间波动，但它几乎总是平均并稳定在 112 MB/秒。
即使两个系统都在处理，Windows 和 Linux 之间通过 samba 以及scpLinux 和 Linux 之间的持续 112 MB/秒的传输速度也可能发生（例如在 64 计算机上以 100% 的速度显示 60 个核心的实数运算工作）。核心服务器）。
注意：在运行 rhel 7.x 之前，当我还是一个 SLES 11.4 的人时，我一直观察到scp大约 80 MB/秒，但我从未找到原因，但是我的 SLES 11.4 通过 samba 到 windows 的速度仍然是 112 MB/秒。

也不要忘记磁盘缓存。例如，如果您的服务器有 128 GB RAM，而您的 win10 PC 有 32GB RAM，并且您只需 7-zip tar 一个 10 GB 的单个文件，则该 10GB 单个 tar 文件可以全部位于 RAM 中，而不是位于磁盘上。因此，在这种情况下，复制传输速度不会受到磁盘 I/O 的阻碍，直到与要复制的文件大小相比耗尽 RAM 为止磁盘缓存无法跟上，此时您会观察到由于磁盘 I/O 的原因，恒定的 112 MB/秒复制速度直接下降到较低的速度（旋转磁盘与 SSD 的情况更是如此）。以及其他一些独立于 1 Gbps 有线网络和相关网络硬件的因素，可能会降低 112 MB/秒的传输速度。

作为比较，我声称的 112 MB/秒是 896 Mb/秒。

值得注意的是：复制具有许多子文件夹和[小]文件的文件夹是传输速度的一个巨大杀手，可以将传输速度从 112 MB/秒降低到每秒千字节，因此如果您想要传输速度，请不要这样做。在这种情况下，最好先将其全部 tar 或 iso 到一个文件中，无论该文件有多大，然后仅传输该文件并在目的地提取它。

2022 年 1 月 20 日更新：

这密码和MACin/etc/ssh/sshd_config可以在 ssh scp 速度中发挥重要作用。
scp我知道在 100gbps HDR infiniband 网络上进行的测试，该网络比 1gbps 快 100 倍，并在两台 RHEL 7.9 服务器之间观察到以下情况：
- 我认为使用Ciphers aes256-ctr,aes192-ctr,aes128-ctrandMACs hmac-sha2-512,hmac-sha2-256是最安全的，但不是性能最好的
  - 在 1gbps LAN 上仍然达到 112 MB/秒，因此 LAN 是薄弱环节，而不是 2.9ghz xeon cpu
  - 在 HDR infiniband 上，我以为我会接近 112 x 100 = 11,200 MB/秒，但我的最大速度约为 270 MB/秒，因此 2.9ghz cpu 似乎无法足够快地加密来满足 infiniband 网络的需求
  - 这是在测试时设置的Ciphers并且MACs每个特定的一个，所以我知道它正在使用那个。否则我相信它会选择第一个指定的密码，如果这不起作用，那么将尝试指定的下一个密码或 mac。
  - 更改Ciphers并且MACs在sshd_config（抱歉我忘记了）中scp我获得的超过 100gbps HDR infiniband 的最大速度约为 700 MB/秒。我将其归因于 700 MB/秒，并且没有接近 11,200 MB/秒，因为 2.9 ghz cpu 无法足够快地处理所选的 SSH 加密；在这种情况下，薄弱环节是 cpu，而不是 HDR infiniband 网络。
  - 即使在 100gbps HDR infiniband 上，某些Ciphers选择也会导致速度低至 60 MB/秒。scp

Answer

1Gbit LAN 上的正常 scp 传输速度是多少？

112 兆字节/秒

与 Micosoft Windows 弹出窗口或scpLinux 中一样，复制速度以每秒 MB（兆字节）为单位报告。请注意不要将其与网络速度以每秒位数报告。 让我们从现在开始标准化，复制速度应该以每秒字节数 (MB/s) 为单位，而不是每秒位数 (Mb/s)

理由：

每秒 1 GB = 每秒 1000 兆位 (mbps)；这是宣传的网络速度。
1000 Mbps / 8 = 125 MB/s（每秒字节数）理论的最大预期值。
我在 1gpbs 有线网络上观察到稳定的 112 MB/秒（并且从未见过更大的速度）；计算出效率为 89.6%，看起来很合理。
- 这是scp在linux下，从linux到linux系统
- 这也适用于来自 linux 的 samba 共享，在 microsoft windows 中的复制弹出窗口中也报告了稳定的 112 MB/秒
- 在过去的 10 年里，我在 Windows 7 及更高版本中观察到了这一点，现在使用 RHEL/CentOS 7.x，在工作中的有线 1gbps 网络（思科企业交换机）上，网络和计算机上无疑还有其他流量，我正在做转移。还有一个 10 美元的 Tigerdirect 4 端口有线交换机。
我不认为 SSH 会导致过多的开销，因为从 Windows 到 Linux 通过 Samba 传输时也观察到了同样的约 10% 的损失（从 125 MB/秒下降到 112 MB/秒）。在我看来，这约 10% 的损失（从 125 MB/秒下降到 112 MB/秒）只是 TCP/IP 开销。我从未见过比 112 MB/秒更好的情况。
在传输开始时，我有时会看到高达 115 MB/秒，并且可能会在 110-115 之间波动，但它几乎总是平均并稳定在 112 MB/秒。
即使两个系统都在处理，Windows 和 Linux 之间通过 samba 以及scpLinux 和 Linux 之间的持续 112 MB/秒的传输速度也可能发生（例如在 64 计算机上以 100% 的速度显示 60 个核心的实数运算工作）。核心服务器）。
注意：在运行 rhel 7.x 之前，当我还是一个 SLES 11.4 的人时，我一直观察到scp大约 80 MB/秒，但我从未找到原因，但是我的 SLES 11.4 通过 samba 到 windows 的速度仍然是 112 MB/秒。

也不要忘记磁盘缓存。例如，如果您的服务器有 128 GB RAM，而您的 win10 PC 有 32GB RAM，并且您只需 7-zip tar 一个 10 GB 的单个文件，则该 10GB 单个 tar 文件可以全部位于 RAM 中，而不是位于磁盘上。因此，在这种情况下，复制传输速度不会受到磁盘 I/O 的阻碍，直到与要复制的文件大小相比耗尽 RAM 为止磁盘缓存无法跟上，此时您会观察到由于磁盘 I/O 的原因，恒定的 112 MB/秒复制速度直接下降到较低的速度（旋转磁盘与 SSD 的情况更是如此）。以及其他一些独立于 1 Gbps 有线网络和相关网络硬件的因素，可能会降低 112 MB/秒的传输速度。

作为比较，我声称的 112 MB/秒是 896 Mb/秒。

值得注意的是：复制具有许多子文件夹和[小]文件的文件夹是传输速度的一个巨大杀手，可以将传输速度从 112 MB/秒降低到每秒千字节，因此如果您想要传输速度，请不要这样做。在这种情况下，最好先将其全部 tar 或 iso 到一个文件中，无论该文件有多大，然后仅传输该文件并在目的地提取它。

2022 年 1 月 20 日更新：

这密码和MACin/etc/ssh/sshd_config可以在 ssh scp 速度中发挥重要作用。
scp我知道在 100gbps HDR infiniband 网络上进行的测试，该网络比 1gbps 快 100 倍，并在两台 RHEL 7.9 服务器之间观察到以下情况：
- 我认为使用Ciphers aes256-ctr,aes192-ctr,aes128-ctrandMACs hmac-sha2-512,hmac-sha2-256是最安全的，但不是性能最好的
  - 在 1gbps LAN 上仍然达到 112 MB/秒，因此 LAN 是薄弱环节，而不是 2.9ghz xeon cpu
  - 在 HDR infiniband 上，我以为我会接近 112 x 100 = 11,200 MB/秒，但我的最大速度约为 270 MB/秒，因此 2.9ghz cpu 似乎无法足够快地加密来满足 infiniband 网络的需求
  - 这是在测试时设置的Ciphers并且MACs每个特定的一个，所以我知道它正在使用那个。否则我相信它会选择第一个指定的密码，如果这不起作用，那么将尝试指定的下一个密码或 mac。
  - 更改Ciphers并且MACs在sshd_config（抱歉我忘记了）中scp我获得的超过 100gbps HDR infiniband 的最大速度约为 700 MB/秒。我将其归因于 700 MB/秒，并且没有接近 11,200 MB/秒，因为 2.9 ghz cpu 无法足够快地处理所选的 SSH 加密；在这种情况下，薄弱环节是 cpu，而不是 HDR infiniband 网络。
  - 即使在 100gbps HDR infiniband 上，某些Ciphers选择也会导致速度低至 60 MB/秒。scp

Question 3

除了其他答案之外：

检查您的有线连接是否都是全双工的（从第一台机器到目标机器），
并确保除了您的 scp 以及协商和返回数据包（ack 等）之外，没有其他任何东西正在使用 1gps 链接
并且您用于 scp 的加密不会压垮两端的 CPU 能力
您拥有较大的 tcp 窗口（以及您的跃点可以处理的所有其他内容）以允许更多数据包和更少的 tcp 开销 paquet
如果文件尚未压缩并且它不会压垮任一 CPU，您可以尝试即时压缩

如果一切完全对您有利，您应该接近 1gbps 的 70-80%（即每秒 1024 兆比特的 80%，即每秒 0.8*1024/8 兆字节），但这可能会损害其他类型的连接（数据包大小较小，或需要更高的响应能力和更少的延迟）

最后，永远不要低估携带 USB 密钥（或驱动器）的带宽...（步行，这也是一项健康福利）

Answer

除了其他答案之外：

检查您的有线连接是否都是全双工的（从第一台机器到目标机器），
并确保除了您的 scp 以及协商和返回数据包（ack 等）之外，没有其他任何东西正在使用 1gps 链接
并且您用于 scp 的加密不会压垮两端的 CPU 能力
您拥有较大的 tcp 窗口（以及您的跃点可以处理的所有其他内容）以允许更多数据包和更少的 tcp 开销 paquet
如果文件尚未压缩并且它不会压垮任一 CPU，您可以尝试即时压缩

如果一切完全对您有利，您应该接近 1gbps 的 70-80%（即每秒 1024 兆比特的 80%，即每秒 0.8*1024/8 兆字节），但这可能会损害其他类型的连接（数据包大小较小，或需要更高的响应能力和更少的延迟）

最后，永远不要低估携带 USB 密钥（或驱动器）的带宽...（步行，这也是一项健康福利）

Question 4

38MB/s 等于 304 Mbps，这在 1Gbps 链路上是相当不错的传输速度，

- 如果您遇到传输速度缓慢的情况，涉及多个因素：

1- 服务器本身的吞吐量。

2- 服务器上的 I/O 性能 [使用 #iostat -xm 1] 检查是否有任何磁盘的读/写利用率 >90%。

3- 中间的 L2 设备可能会导致速度如此缓慢 [尝试直接连接以避免这种情况]。

Answer