☰

与 telnet 相比，SSH 的开销是多少？

tag-icon • tag-icon ssh performance telnet
与 telnet 相比，SSH 的开销是多少？

我好奇：开销有多大 SSH相比介绍telnet？

显然这里有不同的部分：

  1. 由于加密的额外往返而导致的初始连接时间开销
  2. 是否存在带宽开销？
    • 每个传输的数据包是否有开销
    • 或者我们最后只有一些填充？
  3. 客户端的 CPU 开销
  4. 服务器端的 CPU 开销
    • 它有多大？
    • 具有 AES 模块的较新的 CPU 怎么样？
    • 那么具有数十或数百个 SSH 连接的服务器该怎么办？
    • 客户端和服务器的每个连接的 CPU 开销是否对称？
  5. 有内存开销吗？
  6. 我是不是忘了什么？

这更像是一个理论问题。我完全清楚，在服务器仅维护几个 ssh 连接的典型情况下，这实际上没有什么区别。

答案1

我会快速回答你，因为冗长的解释很容易填满 90 分钟的讲座或演讲。这些只是估算，因为它很大程度上取决于系统负载、你在服务器上建立的连接类型，当然还有所使用的硬件。

  1. 是也不是。1 GB 数据或 1 小时连接时间后需要重新密钥。还可能取决于是否使用密钥进行身份验证。Diffie-Hellman 通常比 RSA 密钥交换更昂贵，但由于它只发生一次（左右），所以没什么大不了的。
  2. 是的，存在开销：您必须添加至少 4 个字节的随机填充（SSH2），并且每个数据包都会获得某种 HMAC。取决于使用的内容。我不知道具体是多少，但最多 33 个字节（完整 sha2 长度）时会更少，最大有效载荷为 35000 - 4 字节填充。您获得大约 37/34996 = 0.001% 的开销或更少。
  3. CPU 开销最小。这是 AES 标准的目标之一。
  4. 我也是。它大致是对称的，因为加密操作是对称的（类似于乘法和除法是对称的），当然这需要知道密钥。服务器可以处理多少个连接？取决于连接。如果您有简单的终端会话：很多。如果有人向您发送 1 GBit 连接并通过 scp 复制 10 GB 的数据：使用标准英特尔 i7 可能一次复制两三个。很可能您的 NIC 或存储瓶颈首先出现。
  5. 不确定。有点可能。我认为不会超过正常 telnet 会话内存的两倍。

答案2

总结

隧道模式下的 SSH 带宽开销可以忽略不计

在这个 LAN 测试场景中，相反方向的数据包甚至更少，减少了大约 50％。

如何获取带宽开销的详细信息：

设置：

在服务器上运行

iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------

在客户端我们建立与服务器的 SSH 连接， 但未启用 SSH 压缩。ssh -L 5001:127.0.0.1:5001 [email protected]

为了监控流量，我们添加了

sudo iptables -A INPUT -p tcp --src 192.168.178.55/32 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dst 192.168.178.55/32 -j ACCEPT

因此首先尝试直接连接：

iperf -c 192.168.178.55 -n 1000M
------------------------------------------------------------
Client connecting to 192.168.178.55, TCP port 5001
TCP window size: 83.1 KByte (default)
------------------------------------------------------------
[  3] local 192.168.178.21 port 60824 connected with 192.168.178.55 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-89.5 sec  1000 MBytes  93.8 Mbits/sec

第一个结果

sudo iptables -L -v
Chain INPUT (policy ACCEPT 609 packets, 30850 bytes)
 pkts bytes target     prot opt in     out     source               destination
 342K   14M ACCEPT     tcp  --  any    any     192.168.178.55      anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 968 packets, 99600 bytes)
 pkts bytes target     prot opt in     out     source               destination
93424 1053M ACCEPT     tcp  --  any    any     anywhere             192.168.178.55

iptables -Z 在第二次尝试中，计数器被刷新

sudo iptables -L -v
Chain INPUT (policy ACCEPT 387 packets, 19661 bytes)
 pkts bytes target     prot opt in     out     source               destination
 344K   14M ACCEPT     tcp  --  any    any     192.168.178.55      anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 626 packets, 64440 bytes)
 pkts bytes target     prot opt in     out     source               destination
93166 1053M ACCEPT     tcp  --  any    any     anywhere             192.168.178.55

现在 ssh 连接

iperf -c 127.0.0.1 -n 1000M
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[  3] local 127.0.0.1 port 38080 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-89.4 sec  1000 MBytes  93.8 Mbits/sec

第一个发现：尽管我们有一个 Raspberry PI 3B 作为服务器和一个 Raspberry PI 4B 作为客户端，通过 2 个交换机通过有线 LAN 连接，并且 PI 3B 进行备份，从而在测试时发送了大量数据（这里我们只测量了从 PI4 发送到 PI3B 的数据），但速度是一样的

sudo iptables -L -v
Chain INPUT (policy ACCEPT 27327 packets, 1050M bytes)
 pkts bytes target     prot opt in     out     source               destination
 154K 6540K ACCEPT     tcp  --  any    any     192.168.178.55      anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 27791 packets, 1050M bytes)
 pkts bytes target     prot opt in     out     source               destination
79099 1053M ACCEPT     tcp  --  any    any     anywhere             192.168.178.55

使用 ssh 时，我们传输的数据包更少，但总数据量相同。因此带宽开销微不足道，尤其是与 OpenVPN 相比，OpenVPN 的最大数据包大小约为 5%https://serverfault.com/questions/249935/openvpn-performance

第二次尝试

sudo iptables -L -v
Chain INPUT (policy ACCEPT 27450 packets, 1050M bytes)
 pkts bytes target     prot opt in     out     source               destination
 190K 8025K ACCEPT     tcp  --  any    any     192.168.178.55      anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 27683 packets, 1050M bytes)
 pkts bytes target     prot opt in     out     source               destination
90036 1054M ACCEPT     tcp  --  any    any     anywhere             192.168.178.55

这里我们比第一次尝试多出了大约 14% 的数据包，但仍然比直接连接少了 3000 个数据包。与直接连接相比，我们多传输了 1MB。在这种情况下，也就是 0.09%，而且由于我们以 MB 级别进行测量，因此开销可能会少很多。

我认为输入端驻留的数据包明显较少，是因为 ssh 会合并一些 TCP_ACK 并将它们合并发送。我真的很惊讶通过 ssh 隧道传输的数据较少，并搜索了此实验中的任何错误，但找不到它。

相关内容