Schnellstes Remote X von Windows

Ich habe folgendes eingerichtet:

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

und ich möchte von meinem Windows-Computer aus mit minimaler Latenz auf meine Emacs- und Eclipse-Fenster auf der Linux-Box zugreifen .

Meine Optionen scheinen zu sein:

• VNC
• Virtualisierung eines Linux-Gasts auf meinem lokalen Windows-Host mithilfe von beispielsweise Virtualbox mit Ubuntu und anschließend von dort ssh -Xauf die Linux-Box (hier ist ein Thread, in dem Konfigurationen für schnelles SSH-X-Tunneling erläutert werden ).
• Cygwin mit einem X-Server und ssh -Xzur Remote-Box.

Im Moment benutze ich RealVNC, aber ich habe eine bemerkenswerte Latenz festgestellt . Nach einigen Recherchen habe ich auf Wikipedia Folgendes gelesen :

Das VNC-Protokoll ist pixelbasiert . Dies führt zwar zu einer großen Flexibilität (dh jeder Desktoptyp kann angezeigt werden), ist jedoch häufig weniger effizient als Lösungen, die das zugrunde liegende Grafiklayout besser verstehen, wie z. B. X11 oder Windows Remote Desktop Protocol

Ich frage mich daher, welche Optionen ich habe, um von einem lokalen Windows-Computer aus den schnellsten Zugriff auf Remote-X-Fenster zu erhalten.

Ich denke, der Stand der Technik für die maximale Bandbreite ist NX , ein X11-Protokollkomprimierungsprogramm. Es sollte auch in Bezug auf die Latenz gut funktionieren. Versuchen Sie es mit dem Windows NX-Client und dem kostenlosen NX-Server unter Linux.

Verwenden Sie nach Möglichkeit eine direkte TCP-Verbindung anstelle von SSH. Dies ist natürlich nur in einer kontrollierten Umgebung ohne Sicherheitsbedenken möglich.

Ich denke, in den meisten Setups bietet eine lokal ausgeführte virtuelle Maschine die beste Latenz. Führen Sie Emacs und Eclipse noch besser unter Windows aus. Lassen Sie sie entfernte Dateien bearbeiten oder (für noch bessere Ergebnisse) lokale Dateien bearbeiten, die Sie dann mit Unison oder über ein Versionskontrollsystem synchronisieren.

Windows Remote Desktop funktioniert einwandfrei - solange Sie xrdp auf der Linux-Box ausführen (und meiner Erfahrung nach ist es deutlich weniger ärgerlich und reaktionsschneller als VNC).

xrdp führt einen X-Server auf der Linux-Box aus und verbindet diesen dann mit RDP.

Obwohl ich normalerweise Linux an beiden Enden dieses Kabels habe, bevorzuge ich normalerweise rdesktop gegenüber xrdp gegenüber VNC, wenn sich die einfache X11-Weiterleitung als zu träge herausstellt. VNC ist nur ein französisches Akronym für "funktioniert nicht sehr gut".

Ich bin damit einverstanden, dass Mobaxterm bei der x-Weiterleitung schnell ist. Dann finde ich heraus, dass es ssh basierend auf Cygwin verwendet, aber es ist immer noch schneller als mein Cygwin / SSH. Nachdem ich mir die Debug-Informationen angesehen habe, stelle ich fest, dass das Geheimnis von Mobaxterm darin besteht, aes128-ctr anstelle der üblicheren aes256-cbc- Verschlüsselung zu verwenden, hmac-sha1 zu verwenden und die Komprimierung standardmäßig zu aktivieren.

In Cygwin,

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

sollte Ihnen eine Leistung nahe an Mobaxterm geben. Wenn Sie immer noch glauben, dass Mobaxterm schneller ist, können Sie direkt _ssh.exe verwenden, das Sie in Ihrer Mobaxterm-Wurzel finden.

Einige Blogs / Antworten schlugen Chiffren wie Arcfour oder Blowfish vor . Sie sollten etwas besser sein als aes128-ctr (für alte CPU), aber sie sind veraltet und nicht unbedingt auf allen Plattformen verfügbar. Sie können alle unterstützten Chiffren und Macs von anzeigen

ssh -Q cipher
ssh -Q mac

Dieser Benchmark zeigt, dass aes128-gcm Ihnen die beste Leistung auf modernen CPUs bieten sollte.

Aktualisieren:

Einige schlagen gegen Komprimierung vor. Ich würde sagen, -C hilft immer noch, es sei denn, Ihre Testversion stellt sich anders heraus, selbst wenn Sie glauben, dass Ihr Netzwerk perfekt ist. Da die Datenübertragungsmenge sehr groß ist und das Komprimierungsverhältnis beeindruckend ist, z

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

Eigentlich habe ich versucht, x-Weiterleitung sowohl mit direktem TCP als auch mit SSH mit Komprimierung und einer geeigneten Verschlüsselung über eine interne 100-Mbit / s-LAN-Verbindung mit einer Latenz von <1 ms durchzuführen. Die ssh-Option ist offensichtlich schneller.

Eigentlich war ich schockiert, dass Mobaxterm superschnell ist.

Ich bin ein Softwareentwickler und verwende die IDE namens Qt Creator. Qt Creator ist bekanntermaßen sehr, sehr schnell, aber Putty + Xming waren zu langsam damit, als dass ich es aufgegeben hätte, es über einen Remote-X-Server zu verwenden. Schließlich schockierte mich Mobaxterm mit seiner Geschwindigkeit. Versuch es.