Как ускорить X по SSH при медленном сетевом соединении?

32

Существуют ли какие-либо конкретные рекомендации по ускорению приложений X по ssh при медленном сетевом соединении? В этом конкретном случае я получаю доступ к серверу, расположенному на западном побережье, с ноутбука на восточном побережье и к тому же по не слишком быстрому соединению DSL.

Любые настройки для SSH? Любые советы в целом?

vivekian2
источник

Ответы:

15

Вероятно, вы увидите наиболее важные преимущества, используя сжатие, используя -Cопцию. Вы также можете включить его sshd_config, используя следующую строку:

Compression yes
Крис Даун
источник
1
Если время двусторонней связи велико, то сжатие мало помогает. Стандартный протокол X с множеством сообщений для пинг-понга не подходит для маршрутов с заметным RTT.
Линулин
Это просто природа протокола, с которым мы имеем дело. Спрашивающий заявил, что он не может изменить работающий сервер SSH, так что это лучший вариант на стороне клиента, при условии, что с сервером ничего нельзя сделать.
Крис Даун
6
На некоторых сайтах также сообщается, что используется простой и быстрый чипер, например, blowfish: ssh -X -C -c blowfish-cbc,arcfour$ hostname
math
Есть похожий вопрос, рекомендующий дополнительные опции: superuser.com/questions/400136/speeding-up-remote-x-sessions
математика,
(старый вопрос, но он помечен как «ссылка» в другом вопросе, который был закрыт как дубликат этого). Причиной, по которой запуск приложений X через соединение ssh (или фактически в любом удаленном месте) является сам протокол X , Я отклонил этот ответ, потому что точная настройка параметров ssh на практике не поможет. Вам нужно использовать какой-нибудь «инструмент сжатия протокола», чтобы сделать приложение пригодным для использования, лучший вариант X2GO или какой-либо другой инструмент на основе NX. См. Например, unix.stackexchange.com/a/187420/104833 .
Ариэль
15

Если у вас есть возможность, попробуйте и протестируйте NX (хотя это очень сложно), так как он будет работать намного быстрее, чем туннелирование X поверх ssh ...

скоро
источник
3
NX по умолчанию работает и через ssh-туннель. Так что вам не нужно беспокоиться об открытии других портов.
wm_eddie
NX на самом деле очень быстрый. Лучше, чем VNC, лучше, чем сжатие по X. Работает хорошо.
vivekian2
Я бы на самом деле отметил это правильный ответ для тех, кто может запустить NX на стороне сервера. Доступны не все функции пользовательского интерфейса (по крайней мере, в GNOME), но скорость того стоит.
vivekian2
Никогда не пробовал NX, но VNC - хорошая альтернатива SSH -X
baptx
Это должен быть принятый ответ, нет смысла пытаться ускорить настройку ssh (d). Лучшая альтернатива самому NX (который довольно болезнен в настройке) - это X2GO, также основанный на NX-библиотеках, но намного проще в работе.
Ариэль
8

Прошло довольно много времени с тех пор, как я попробовал это сделать, но DXPC (сжатие протокола дифференциального X) раньше заставлял X11 через коммутируемый PPP работать заметно быстрее. Возможно, опция сжатия SSH подойдет вам лучше, но это сжатие относится только к X11 и может работать быстрее.

Брюс Эдигер
источник
4

Возможно, стоит исследовать высокую производительность openssh. По соображениям безопасности openssh использует статические буферы во многих местах. Проект HPH-SSH повторно реализует его части, чтобы использовать динамические буферы. Также кажется, что они внедрили многопоточные шифры в последних ревизиях.

https://www.psc.edu/hpn-ssh

jmtd
источник
Требует ли это изменений на сервере ssh, работающем на стороне сервера? Возможно, это то, что я не могу контролировать.
vivekian2
1
Нет, это не так. Со страницы:> Мы создали патч, который устранит узкие места в OpenSSH и полностью совместим с другими серверами и клиентами. Кроме того, клиенты HPN смогут быстрее загружаться с серверов,
отличных
1

X2Go решит вашу проблему. Я получаю малиновый пи в Аргентине из Силиконовой долины. Есть небольшая задержка, но работать с ней так же удобно, как и с настольным компьютером.

VNC - ваш второй выбор.

Богатый
источник