SSH壓縮X11轉發

我在美國的東海岸，ssh方式連接到在西海岸的服務器。SSH壓縮X11轉發

我已經成功地得到X11轉發工作，所以我可以啓動對某些任務GUI應用它是有幫助的。然而，對於所有的X11轉發應用程序（尤其是emacs！），有輸入之間如此多的滯（按鍵，鼠標點擊等）和響應，它有時被非常令人沮喪有潛在危害的，當我打算去做A，但B發生是因爲滯後很大。

是SSH壓縮潛在的罪魁禍首？我應該使用什麼樣的壓縮？

來源

2012-10-19 Zearin

X11顯卡佔用了大量的帶寬。如果您的遠程主機離開一定距離（即不在局域網中），那麼您可能會在導出的X11應用程序中遭受遲鈍。

我不知道SSH壓縮。性能可能取決於其他因素，如CPU性能。從ssh手冊頁：

  -C  Requests compression of all data (including stdin, stdout, 
      stderr, and data for forwarded X11 and TCP connections). The 
      compression algorithm is the same used by gzip(1), and the 
      「level」 can be controlled by the CompressionLevel option for pro‐ 
      tocol version 1. Compression is desirable on modem lines and 
      other slow connections, but will only slow down things on fast 
      networks. The default value can be set on a host-by-host basis 
      in the configuration files; see the Compression option.

這裏有一些其他的解決方法，你可以用它來使事情更快：

而是使用X11轉發的GUI交互，可以考慮別的，具有更好的優化/壓縮，例如VNC或NX/FreeNX。
使用終端版本的emacs而不是GUI版本。

來源

2012-10-19 16:08:13 padub

猜猜我的問題不在於配置 - 而是關於我選擇的工具。之前讓VNC工作時遇到了一些麻煩，但也許值得再拍一次。謝謝！ – Zearin

實際上寫得很好的X11程序不會佔用很多帶寬。 X11的主要問題是糟糕的Xlib，它幾乎爲每個操作執行完全同步往返，而許多操作可以異步執行。如果使用另一個X11協議後端（如Xcb），而不是做虛擬的事情，比如光柵化客戶端上的整個GUI，然後通過網絡傳輸該死的東西，那麼在低帶寬，高延遲連接上純X11 TCP實際上是非常有用的。然而很多程序寫得很糟糕。我推薦使用NX或ssh，將xpra – datenwolf

+1添加到@datenwolf它比關於bandwith的往返時間和往返次數更多，而且Xlib在利用x11協議的全雙工異步性質方面做得非常糟糕（協議本身針對延遲進行了非常優化） –

正如你特別提到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）。

來源

2016-06-22 17:48:14

SSH壓縮X11轉發

回答

相關問題