SSH压缩X11转发

Question

我在美国东海岸，通过SSH连接到美国西海岸的服务器。

我已经成功地实现了X11转发，可以启动图形界面应用程序来完成某些任务。然而，对于所有经过X11转发的应用程序（特别是emacs！），输入（按键，鼠标点击等）和响应之间存在很大的延迟，有时这会从极度沮丧变成潜在的危险——因为延迟太大，我的本意是要执行A，但结果做了B。

SSH压缩是否可能是罪魁祸首？我应该使用什么类型的压缩？

- Zearin

---

很好的开场 :) :) - SanThee

很好的开场 :) :) - undefined

Answer 1

X11图形占用大量带宽。如果您的远程主机距离较远（即不在局域网内），那么您可能会在导出的X11应用程序中遇到迟缓。

关于SSH压缩，我不确定。性能可能取决于其他因素，例如CPU性能。从ssh手册页中得知：

     -C      请求压缩所有数据（包括stdin、stdout、stderr以及转发的X11和TCP连接的数据）。压缩算法与gzip（1）使用相同，“级别”可以通过协议版本1的CompressionLevel选项进行控制。在调制解调器线路和其他慢速连接上，压缩是可取的，但会使快速网络变慢。默认值可以在配置文件中按主机设置；请参见压缩选项。

以下是其他可用于加速的解决方法：

• 考虑使用具有更好优化/压缩的内容而不是通过X11转发与GUI进行交互，例如VNC或NX/FreeNX。
• 使用终端版的emacs而不是GUI版。

- padub

---

我的问题可能不在于配置，而是我选择的工具。之前我在使用VNC时遇到了一些麻烦，但也许值得再试一次。谢谢！ - Zearin

实际上，写得好的X11程序不会占用太多带宽。 X11的主要问题在于糟糕透顶的Xlib编写方式，它几乎为每个操作执行完整的同步往返，而许多操作可以异步执行。如果使用另一个X11协议后端（如Xcb），并且不做像将整个GUI光栅化到客户端然后只是将该东西简单地覆盖到网络上这样愚蠢的事情，那么在低带宽、高延迟连接上，纯X11通过TCP实际上非常可用。然而，很多程序编写得很糟糕。我建议使用NX或ssh附加的Xpra。 - datenwolf

+1 给 @datenwolf。这更多关乎延迟和往返次数，而不是带宽。Xlib 在利用 X11 协议的全双工异步特性方面表现非常糟糕（协议本身对延迟进行了优化）。 - Andrey Sidorov

尽管SSH文档中提到使用-C选项压缩会有一些缺点，但我发现它总是能够提高X11转发的性能。这并不意味着它非常好，但比起几乎无法使用要好得多。我不确定为什么它会在快速网络上拖慢速度。也许这份文档是在1990年代编写的，那时还没有发明出快速计算机。 - Noah Spurrier

我可以确认Noah Spurrier的评论 - 在我的局域网上，C导致Firefox使用20-30 Mbps而不是120 Mbps，并且它更加响应。 - danno

@NoahSpurrier，我认为ssh主要用作远程shell。在这种情况下，应用于用户键入的按键和命令提示符中的回显的压缩可能会引入明显的不适延迟。因此，我想这就是为什么默认禁用压缩的原因。如果有人需要使用sshfs或类似工具，则可以启用压缩。我以前从未尝试过压缩，也从未注意到延迟。我还在所有地方使用tmux。它具有一些特殊的输出缓冲区，我相信会丢弃一些用户无法注意到的快速stdout“帧”。 - Victor Yarema

Answer 2

你特别提到了emacs：有一个命令行选项

  -nw, --no-window-system
          Tell Emacs not to create a graphical frame.  If you  use
          this switch when invoking Emacs from an xterm(1) window,
          display is done in that window.

当通过ssh工作时，这可以更快（因为它只需传输字符，而不是在X11上重新绘制整个屏幕）。

- serv-inc