☰

SSH 隧道缓慢

tag-icon • tag-icon ssh putty tunneling
SSH 隧道缓慢

我刚刚搬到了地球的另一边，遇到了一个奇怪的连接问题。我有一个 4 Mbps 的 dsl 连接，可以成功 ssh 到我的服务器，并设置一个隧道。我使用 PuTTY（在我的台式机 - PC 上）和 Terminal（在我的 Mac 上）。我的台式机的速度平均为 0.5 Mbps。如果我直接测试离我的服务器最近的服务器（即没有代理/隧道）的速度，我会得到广告中说的 4 Mbps。

唯一的区别是台式机使用 CAT5 连接，而 Mac 通过 DSL 路由器无线连接。我通过将电缆插入 Mac 来检查，发现隧道速度为 4 Mbps。与路由器的其他以太网连接也获得 4 Mbps 的速度。

下面是 putty.log。我不确定是路由器的问题还是 putty 连接的配置的问题，在 Google 上搜索了 4 个小时后，我还是不知所措。

任何帮助都将不胜感激。服务器本身运行的是 Ubuntu 10.04。

2011-08-01 14:14:13 Looking up host "x.x.x.x"
2011-08-01 14:14:13 Connecting to x.x.x.x port 22
2011-08-01 14:14:13 Server version: SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
2011-08-01 14:14:13 We claim version: SSH-2.0-PuTTY_Release_0.60
2011-08-01 14:14:13 Using SSH protocol version 2
2011-08-01 14:14:14 Doing Diffie-Hellman group exchange
2011-08-01 14:14:14 Doing Diffie-Hellman key exchange with hash SHA-256
2011-08-01 14:14:14 Host key fingerprint is:
2011-08-01 14:14:14 ssh-rsa 2048 aa:bb:cc:dd:0f:a3:1e:06:bc:c8:7d:dd:cc:bb:aa:11
2011-08-01 14:14:14 Initialised AES-256 SDCTR client->server encryption
2011-08-01 14:14:14 Initialised HMAC-SHA1 client->server MAC algorithm
2011-08-01 14:14:14 Initialised AES-256 SDCTR server->client encryption
2011-08-01 14:14:14 Initialised HMAC-SHA1 server->client MAC algorithm
2011-08-01 14:14:15 Reading private key file "C:\key.ppk"
2011-08-01 14:14:17 Offered public key
2011-08-01 14:14:18 Offer of public key accepted
2011-08-01 14:14:20 Access granted
2011-08-01 14:14:21 Opened channel for session
2011-08-01 14:14:21 Local port 1080 SOCKS dynamic forwarding
2011-08-01 14:14:21 Allocated pty (ospeed 38400bps, ispeed 38400bps)
2011-08-01 14:14:21 Started a shell/command

答案1

作为 ssh 连接/隧道速度的一般规则...Putty 是单线程应用程序，因此即使在多核系统上，您也会受到单个 CPU 核心速度的限制。对于高速，请选择快速密码 - Blowfish。在 putty 中配置它，或者如果使用命令行 ssh，请指定ssh -c blowfish ...使用它。使用这种方法，您在 Gbit 本地网络上的速度仍然会被限制在大约 10 MB/s 左右。

编辑：现在是 2018 年，所有当前 CPU 和操作系统都应支持硬件 AES 加速（AES-NI 指令）。因此，Blowfish 的建议现在仅适用于较旧的硬件（或路由器等较慢的硬件）。硬件加速 AES 提供超过 1 GB/s 的加密速率，因此对于 ssh 和/或 openssl 来说已经足够了。

答案2

我在跨大西洋的高延迟链路上使用 WinSCP（基于 PuTTY 的 SSH 实现）时遇到了类似的问题。PuTTY 和 WinSCP 处理其网络缓冲区的方式不允许 TCP 窗口缩放完成其工作，而这对于高延迟链路来说确实是必要的。它总是会发送两个数据包，一个大，一个小。第一个的有效载荷为 1460 字节，第二个的有效载荷为 76 字节。

此主题对为什么 1460+76 字节很重要有很好的解释。

无论如何，我自己解决了这个问题，放弃了PuTTY/WinSCP，转而使用Bitvise 隧道，它不会出现这种缓冲/窗口缩放问题。

相关内容