Windowsから最速のリモートX


12

次の設定をしています。

|-----------------|                          |---------------|
|   Windows       |     LAN (or VPN)         |    Linux box  |
| (local machine) | <-------------------->   |               |
|-----------------|                          |---------------|

レイテンシ最小限に抑えながら、WindowsマシンからLinuxボックス上のEmacsおよびEclipseウィンドウにアクセスしたいと思います。

私のオプションは次のようです:

  • VNC
  • たとえば、UbuntuのVirtualboxを使用してローカルWindowsホスト上のLinuxゲストを仮想化し、そこssh -XからLinuxボックスに仮想化します(高速ssh Xトンネリングの構成を説明するスレッドです)
  • Xサーバーとssh -Xリモートボックスへのcygwin 。

現時点ではRealVNCを使用していますが、いくつかの顕著な遅延に気づきました。いくつかの調査を行った後、私はウィキペディアで以下を読みました:

VNCプロトコルはピクセルベースです。これは優れた柔軟性につながります(つまり、あらゆる種類のデスクトップを表示できます)が、X11やWindowsリモートデスクトッププロトコルなどの基本的なグラフィックレイアウトをよりよく理解しているソリューションよりも効率が悪いことがよくあります。

これにより 、ローカルのWindowsマシンからリモートのXウィンドウに最速でアクセスするにはどのようなオプションが必要ですか?


ssh -X私がパテを介して使用するものですが、一部の同僚はxmingを使用しています。
h3rrmiller

sshトンネリングが思い浮かびますが、ネットワークによって導入される遅延をどのように制御できますか?VNC導入の待ち時間は、ネットワークによって導入されるものよりも大幅に低くなる可能性があります。
Karlson、2012年

さらに、VNCとssh-X-forwardingに加えて、Spiceがあります。主に仮想マシン向けに開発されているため、使用できるかどうかわかりません。
jofel

ありがとう。@ h3rrmiller リモートXをPuttyで実行する必要 xmingがあると思いました。あなたssh -Xはどのように正確にパテにいますか?私はEnable X11 forwardingパテでクリックしましたが、これは十分ではないようです。
Amelio Vazquez-Reina

3
@ user27915816はい、パテを使用したX11転送では、バックグラウンドでxmingを実行する必要があります。
jofel

回答:


8

最大帯域幅の最先端は、X11プロトコル圧縮プログラムであるNXだと思います。レイテンシに関しても十分に機能するはずです。LinuxでWindows NXクライアント無料のNXサーバーを使用してみてください。

可能であれば、SSHではなく直接TCP接続を使用してください。もちろん、これはセキュリティ上の心配がない制御された環境でのみ実行可能です。

ほとんどの設定では、ローカルで実行されている仮想マシンが最高のレイテンシを提供すると思います。さらに良いことに、WindowsでEmacsとEclipseを実行します。リモートファイルを編集させるか、または(より良い結果を得るために)ローカルファイルを編集させ、それをUnisonまたはバージョン管理システムを介して同期させます。


2

Windowsリモートデスクトップは、Linuxボックスでxrdpを実行している限り、正常に機能します(私の経験では、VNCよりも煩わしさがなく、応答性が高くなっています)。

xrdpはLinuxボックスでXサーバーを実行し、それをRDPにフックします。

実際、私は通常、この回線の両端にLinuxを使用していますが、通常、プレーンなX11転送の速度が遅すぎる場合は、VNCよりもrdesktopよりもxrdpを優先します。VNCはフランス語で「うまく機能しない」の頭字語です。


2

Mobaxtermがx転送で高速であることに同意します。次に、cygwinに基づくsshを使用していることを確認しましたが、cygwin / sshよりも高速です。デバッグ情報を調べたところ、Mobaxtermの秘密は、より一般的なaes256-cbc暗号ではなくaes128-ctrを使用していることがわかり、hmac-sha1を使用して、デフォルトで圧縮をオンにします。

Cygwinでは、

ssh -m hmac-sha1 -c aes128-ctr -C 

mobaxtermに近いパフォーマンスが得られるはずです。それでもmobaxtermの方が速いと確信している場合は、mosaxtermルートにある_ssh.exeを直接使用できます。

一部のブログ/回答は、arcfourblowfishなどの暗号を提案しました。これらはaes128-ctr(古いCPUの場合)よりもわずかに優れているはずですが、古く、必ずしもすべてのプラットフォームで利用できるわけではありません。サポートされているすべての暗号とMacを次の方法で表示できます

ssh -Q cipher
ssh -Q mac

このベンチマークは、aes128-gcmが最新のCPUで最高のパフォーマンスを提供することを示しています。

更新:

一部は圧縮を推奨しません。ネットワークが完全であると信じていても、裁判が別の結果にならない限り、-Cが依然として役立つと思います。データ転送量が非常に大きく、圧縮率が印象的であるため、例えば

 debug1: compress outgoing: raw data 603154, compressed 141717, factor 0.23 
 debug1: compress incoming: raw data 67841628, compressed 641357, factor 0.01

実際、私は、1ミリ秒未満のレイテンシで内部100Mbps LAN接続を介して、圧縮と適切な暗号化を使用した直接tcpとsshの両方でx転送を試みました。sshオプションの方が明らかに高速です。


1

実際、Mobaxtermが超高速であることに驚きました

私はソフトウェア開発者で、Qt Creatorと呼ばれるIDEを使用しています。Qt Creatorは非常に高速であることが非常に知られていますが、パテ+ Xmingの速度が遅すぎたため、リモートxserverでの使用をあきらめました。最終的に、Mobaxtermはその速度に衝撃を与えました。それを試してみてください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.