Najszybszy zdalny X z Windows

12

Mam następujące ustawienia:

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

i chciałbym uzyskać dostęp do moich okien Emacs i Eclipse na komputerze z systemem Linux z mojego komputera z minimalnym opóźnieniem .

Moje opcje wydają się:

VNC
Wirtualizacja gościa Linuksa na moim lokalnym hoście Windows przy użyciu na przykład Virtualbox z Ubuntu, a następnie ssh -Xz niego do Linuxa (tutaj jest wątek omawiający konfiguracje do szybkiego tunelowania ssh X )
cygwin z serwerem X i ssh -Xzdalnym urządzeniem.

W tej chwili używam RealVNC, ale zauważyłem pewne znaczące opóźnienie . Po przeprowadzeniu badań przeczytałem na Wikipedii :

Protokół VNC jest oparty na pikselach . Chociaż prowadzi to do dużej elastyczności (tzn. Można wyświetlać dowolny typ pulpitu), często jest mniej wydajne niż rozwiązania lepiej rozumiejące podstawowy układ graficzny, taki jak X11 lub Windows Remote Desktop Protocol

Zastanawiam się, jakie opcje muszę uzyskać, aby uzyskać najszybszy dostęp do zdalnych okien X z lokalnego komputera z systemem Windows?

— Amelio Vazquez-Reina
źródło

ssh -Xto jest to, czego używam za pomocą Kit, niektórzy koledzy używają Xming.

— h3rrmiller

przychodzi na myśl tunelowanie ssh, ale jak kontrolować opóźnienie wprowadzone przez sieć? Opóźnienie wprowadzenia VNC mogłoby potencjalnie być znacznie niższe niż wprowadzone przez sieć.

— Karlson,

Oprócz VNC i przekierowywania ssh-X istnieje także Spice . Nie wiem, czy możesz go użyć, ponieważ jest on głównie opracowany dla maszyn wirtualnych.

— jofel

Dzięki. @ h3rrmiller Myślałam potrzebne xming do zrobienia zdalnego X z Putty. Jak się masz ssh -Xw Putty? Kliknąłem Enable X11 forwardingw Putty, ale to nie wydaje się wystarczające.

— Amelio Vazquez-Reina,

3

@ user27915816 tak, do przekazywania X11 z kitem potrzebujesz xminga działającego w tle.

— jofel

8

Myślę, że najnowszym stanem maksymalnej przepustowości jest NX , program do kompresji protokołu X11. Powinien również dobrze działać w odniesieniu do opóźnień. Spróbuj użyć klienta Windows NX i darmowego serwera NX w systemie Linux.

Jeśli to możliwe, użyj bezpośredniego połączenia TCP zamiast SSH. Oczywiście jest to wykonalne tylko w kontrolowanym środowisku bez obaw o bezpieczeństwo.

Myślę, że w większości konfiguracji maszyna wirtualna działająca lokalnie zapewni najlepsze opóźnienie. Co więcej, uruchom Emacsa i Eclipse pod Windows; zmusić ich do edycji plików zdalnych lub (dla jeszcze lepszych wyników) zmusić ich do edycji plików lokalnych, które następnie synchronizuje się z Unison lub poprzez system kontroli wersji.

— Gilles „SO- przestań być zły”
źródło

2

Pulpit zdalny systemu Windows działa dobrze - o ile uruchamiasz xrdp na Linuksie (i z mojego doświadczenia jest znacznie mniej irytujący i bardziej responsywny niż VNC).

xrdp uruchamia serwer X na Linux-ie, a następnie łączy go z RDP.

W rzeczywistości, chociaż zwykle mam Linuksa na obu końcach tego drutu, zwykle wolę rdesktop niż xrdp niż VNC, ilekroć zwykłe przekazywanie X11 okazuje się zbyt wolne. VNC to po prostu francuski skrót od „nie działa zbyt dobrze”.

— Stabledog
źródło

2

Zgadzam się, że Mobaxterm szybko przesyła x. Potem dowiaduję się, że używa ssh opartego na cygwin, ale wciąż jest szybszy niż mój cygwin / ssh. Po patrząc informacji debugowania, dowiem tajemnicę MobaXterm korzysta AES128 CTR zamiast bardziej powszechne AES256-CBC szyfr, użyj HMAC-SHA1 i włączyć kompresję domyślnie.

W cygwinie

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

powinien dać ci wydajność zbliżoną do mobaxterm. Jeśli nadal uważasz, że mobaxterm jest szybszy, możesz bezpośrednio użyć pliku _ssh.exe, który można znaleźć w katalogu głównym mobaxterm.

Niektóre blogi / odpowiedzi sugerowały szyfry, takie jak arcfour lub blowfish . Powinny być nieco lepsze niż aes128-ctr (dla starego procesora), ale są przestarzałe i niekoniecznie dostępne na wszystkich platformach. Możesz wyświetlić wszystkie obsługiwane szyfry i komputery Mac według

ssh -Q cipher
ssh -Q mac

Ten test porównawczy pokazuje, że aes128-gcm powinien zapewnić najlepszą wydajność na nowoczesnym procesorze.

Aktualizacja:

Niektórzy sugerują przeciw kompresji. Powiedziałbym, że załóżmy, że -C nadal pomaga, chyba że próba okaże się inna, nawet jeśli uważasz, że Twoja sieć jest idealna. Ponieważ ilość przesyłanych danych jest bardzo duża, a stopień kompresji imponujący, np

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

W rzeczywistości próbowałem przekierowania x zarówno z bezpośrednim tcp, jak i ssh z kompresją i odpowiednim szyfrem przez wewnętrzne połączenie LAN 100 Mb / s z opóźnieniem <1ms. Opcja ssh jest oczywiście szybsza.

— Haodong Du
źródło

1

Tak naprawdę byłem zszokowany odkryciem, że Mobaxterm jest super szybki.

Jestem programistą i używam IDE o nazwie Qt Creator. Qt Creator jest bardzo znany z tego, że jest bardzo, bardzo szybki, ale Putty + Xming działały zbyt wolno, że zrezygnowałem z używania go za pośrednictwem zdalnego serwera Xserver. W końcu Mobaxterm zaskoczył mnie swoją szybkością. Spróbuj.

— Fizyk kwantowy
źródło