为什么ssh的执行速度比iperf3慢？

Question

我感到沮丧的是，开放的客户机/服务器的最高性能是1.03G/S，而iperf3可以轻松地在相同的点对点链接上维持7.03G/S。

• 强迫Nagle，
• ProxyCommand使用nc作为ssh，
• 禁用压缩禁用压缩
• 强制特定密码，

所有这些都没有效果；

• 在iperf测试和ssh传输测试期间，两个盒子的cpu负载都低于70% (占总数的2400% )，
• 不涉及块设备。

我只是不明白，ssh根本就不能达到10 get吗？是密码还是哈希让我慢下来了？有人在openssl客户端源代码中硬编码千兆位限制吗？我必须打开8+独立的ssh连接才能以直线速度在管道上抛出数据吗？

如下图所示，微小的绿色斑点是cat /dev/zero | ssh target 'cat >/dev/null'；紫色/橙色的斑点是ssh端口转发的iperf3，高的斑点是规则的iperf3。

一些统计；

• 在专用链路上的iperf3 :7.11Gbit/S(我怀疑我对光纤的错误处理已经从原来的~9 9Gbit性能新的se la vi减少了这一点)
• iperf3 over专用链路(mtu=9000)：7.55Gbit/S
• gbe上的iperf3 :941 over /S
• iperf3在ssh上的直接链接:1.03Gbit/S
• 千兆位上的iperf3 :941 using /S(很明显，ssh使用的是正确的路径，它仍然比常规的gbe略快)
• iperf3 over与ProxyCommand nc: 1.1Gbit/s (另一个非常小的增益)
• iperf3 over与ProxyCommand nc (mtu=9000)：1.01Gbit/s (本例中mtu似乎取消了链路速度)

Answer 1

似乎SSH只是无法更快地传输，无论如何，对于一个实例来说。我终于意识到，我应该在环回上运行这个测试(在Linux4.10.0上，回环可以支持12 Mbits/S)和ssh回送仍然只在125~135 Mbit/S附近执行；然而，即使是在ssd上的ext4文件系统可能也只能勉强提高30-50 Mbits/ or；对于大型传输，我已经决定建立一个物理安全的链接，并使用dd over netcat；磁盘阵列吞吐量上的瓶颈不是文件系统，也不是传输协议。我还使aria2能够使用sftp，所以我放弃了并行ssh客户端传输。似乎还有很长的路要走

Answer 2

几乎7 7Gbps显然是一个假值，因为它只是一个最大峰值(“闪点”)，而不是一个持续的传输速率。这可能是因为您的网络软件估计传输速度的方式(没有占用所有带宽的小包可能会更快到达)。事实上，在7 7Gbps读数的同一行中，有一个200 7Gbps的平均值。尝试持续传输一个足够大的文件，例如> 1GB