☰

无需在服务器上安装软件即可实现更快的 SSH/x11 转发

tag-icon • tag-icon ssh xorg x11-forwarding
无需在服务器上安装软件即可实现更快的 SSH/x11 转发

除了使用更快的密码和压缩之外，有人知道在 SSH 上加速 X11 转发的任何方法吗？无需在服务器上安装任何软件？就我而言，我没有任何权限在服务器上安装软件。它属于我的大学。但是，我希望在服务器上运行并显示在我家计算机上的 GUI 程序实际上是可用的。

答案1

通过 ssh 隧道传输 X11 非常耗费带宽，而且 X 协议对于高 RTT 链路来说并不理想。您可能没有足够的带宽，或者延迟太大，无法使用。

您似乎已经缩小了选择范围：

  • 需要您在两端安装软件的选项（X 协议优化器，例如 x2go、FreeNX 或其他，或者使用除 X over SSH 之外的其他协议，例如 VNC 或远程桌面）

  • 使用压缩（或者不使用，最好同时使用两种方法）：选项 -C

  • 使用较便宜的密码协议，如 BlowFish-CBC 或 arcfour（第二个不太安全）：添加选项 -c blowfish-cbc

你似乎错过的唯一一个是你的X程序是否是Firefox，在这种情况下，设置network.http.pipelining和使用ssh多路复用似乎可以做出改变。

答案2

我用SSH-HPN 客户端，一系列针对官方 SSH 代码的补丁，以提高性能，适用于我需要高性能 SSH 的任何时候。一些平台（如 FreeBSD）开箱即用，在其他平台上，您可以通过包管理器安装它，或者您可以从源代码编译它并自行添加补丁。

如果您在一个流行的平台上，您可能可以找到 ssh-hpn 的二进制分发版（但出于明显的安全原因，使用这样的软件从源代码构建总是更好）。

如果你真的不关心安全性，你可以使用通过 netcat 进行 X11（又名nc）而不是 ssh。它可能也已安装在您的机器上。

答案3

想法 #1：关闭压缩。是的，关闭。您的问题可能不是带宽问题，而是延迟问题。在通道中使用压缩通常会使 GUI 应用程序的延迟非常严重。如果您的带宽充足，我建议您尝试一下看似奇怪的方法：关闭所有压缩。

想法#2：尝试使用另一个 ssh 实现。然后 openssh 的速度有点出名。可能部分原因是它的开发人员专注于安全性，速度对他们来说是次要的。延迟的原因可能是不是加密算法很慢，但对同时传输数据事件（包括传入和传出等多个方向）的处理效率低下，而且在单线程而非面向事件的软件中进行计算/压缩/加密。（例如：软件的典型工作方式：首先加密一个数据块，然后将其发送到网络，最后读取远程端发送给我们的数据，然后解密。这似乎完全没问题，但它包含一个可怕的延迟：到达的数据块在实际块压缩尚未准备好之前不会被读取...它应该以多线程或至少异步的方式实现，而 openssh 在这方面非常非常糟糕）。

想法#3：检查双方的配置。可以在服务器和客户端配置中设置压缩。在我看来，也许你只在其中一侧设置压缩并不不切实际。检查一下，确实检查一下它是否真的发生在两侧（尽管在发送侧可能并不重要，因为你的鼠标移动和键盘点击不会占用太多带宽）。也许一个不对称的解决方案，也在服务器->客户端侧压缩大型图像操作，同时发送未压缩的、低延迟的客户端->服务器数据，这有望获得最佳结果。

相关内容