Кто-нибудь знает какой-либо способ ускорить пересылку X11 по SSH, кроме использования более быстрого шифрования и сжатия, без установки какого-либо программного обеспечения на сервер? В моем случае у меня нет разрешения на установку программного обеспечения на сервер. Это принадлежит моему университету. Однако я хотел бы, чтобы программы с графическим интерфейсом, которые запускаются на сервере и отображаются на моем домашнем компьютере, были действительно пригодными для использования.
3 ответа
7
Туннелирование X11 через ssh довольно дорого обходится, а протокол X не идеален для каналов с высоким RTT. Возможно, вам просто не хватит пропускной способности или слишком большой задержки, чтобы ее можно было использовать.
Вы, кажется, уже сузили варианты, которые у вас есть:
варианты, требующие установки программного обеспечения на обоих концах (либо оптимизатор протокола X, например x2go, FreeNX или другие, либо использование протокола, отличного от X по SSH, например VNC или удаленный рабочий стол)
используя сжатие (или нет, лучше, но попробуйте оба): опция -C
используя менее дорогой протокол шифрования, такой как BlowFish-CBC или arcfour (второй менее защищен): добавьте опцию -c blowfish-cbc
Единственное, что вы пропустили, это если ваша X-программа - Firefox, и в этом случае кажется, что установка network.http.pipelining и использование мультиплексирования ssh могут иметь значение.
2
Я использую ssh-hpn, серию патчей для официального SSH-кода для повышения производительности, в любое время, когда мне нужен высокопроизводительный SSH. Некоторые платформы, такие как FreeBSD, включают его «из коробки», на других вы можете установить его через менеджер пакетов или скомпилировать его из исходного кода и добавить патчи в себя.
Если вы работаете на популярной платформе, вы, вероятно, можете найти бинарный дистрибутив ssh-hpn (хотя по очевидным соображениям безопасности сборка из исходного кода всегда лучше с таким программным обеспечением).
Если вы действительно не заботитесь о безопасности, вы можете использовать X11 вместо netcat (он же nc) вместо ssh. Скорее всего, он уже установлен на вашем компьютере.
1
Идея № 1: выключить сжатие. Да, выкл. Возможно, ваша проблема не в пропускной способности, а в задержке. Сжатие в канале обычно приводит к очень плохой задержке для приложений с графическим интерфейсом. Если у вас хорошая пропускная способность, я бы посоветовал вам попробовать на первый взгляд выглядеть странно: везде выключать сжатие.
Идея № 2: Попробуйте использовать другую реализацию SSH. Тогда openssh немного печально известен своей скоростью. Вероятно, его частичная причина в том, что разработчики сосредоточены на безопасности, а скорость - для них второстепенная вещь. Причиной задержки, вероятно, является не медлительность алгоритмов шифрования, а неэффективная обработка одновременных событий передачи данных (во многих направлениях, как входящих, так и исходящих), а также вычисление / сжатие / шифрование в единой системе. потоковое, а не событийно-ориентированное программное обеспечение. (Например: типичная работа программного обеспечения: сначала он шифрует блок данных, затем отправляет его в сеть, наконец читает то, что отправила нам удаленная сторона, и расшифровывает его. Кажется, все в порядке, но он содержит ужасную задержку: поступившие блоки данных не будут прочитаны, пока фактическое сжатие блоков не будет готово ... Это должно быть реализовано многопоточным или, по крайней мере, асинхронным способом, и openssh очень, очень, очень плох в этом).
Идея № 3: Проверьте конфиг с обеих сторон. Сжатие может быть установлено как на сервере, так и в конфигурации клиента. Мне кажется нереальным, что, может быть, вы настроены только на одну из сторон. Проверьте, действительно убедитесь, что это действительно происходит с обеих сторон (хотя, вероятно, на отправляющей стороне это не очень важно, потому что ваши движения мыши и нажатия клавиш не используют слишком большую пропускную способность для этого. Возможно, асимметричное решение, также сжимающее операции с большими изображениями на стороне сервера -> клиента, в то время как отправка несжатых данных клиента -> сервера с малой задержкой обещает наилучший результат.