Почему пересылка X11 так неэффективна?


98

Всякий раз, когда я удаленно запускаю большие графические интерфейсы с переадресацией X11, даже с ключом -C, это очень не отвечает. Мой вопрос: что на уровне концепции / протокола вызывает это?

С моим 25-битным соединением я могу без проблем передавать потоковое видео высокой четкости на свой компьютер. С другой стороны, неотзывчивость удаленно запускаемых графических интерфейсов с переадресацией X11 возникает даже в 100-битной локальной сети, где задержка должна быть близка к нулю.

Я понимаю, что в отличие от потокового видео задержка будет в лучшем случае удваиваться (так как входные данные должны отправляться на удаленный компьютер, и только после этого приложение может отвечать), но внутренне существуют ли другие факторы, которые увеличивают задержку даже в дальнейшем?

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

Например, в случае .bmp vs .png изображение в большом черном квадрате будет меньше в представлении .png, поскольку информация хранится не для каждого отдельного пикселя, а, насколько я понимаю, с разбросом диапазона.

В случае видео можно сохранить всю информацию, отправив разницу между кадрами, а не целыми кадрами.

Я знаю, что это очень упрощено, но X11 не использует эти методы? На каком-то уровне он ведет себя как растровый или недифференцированный принцип? И если нет, то почему это занимает столько пропускной способности?


9
Общая информация: Xpra предлагает интересный подход.
Камиль Мачоровски

12
Кстати, использование «-C» замедлит ваше соединение, если ваша ссылка достаточно быстрая, потому что сжатие требует времени. «-C» может принести пользу 100 МБ, но, вероятно, нанесет ущерб 1 ГБ и, конечно, нанесет ущерб 10 ГБ. Это также тот случай, когда ssh повредит вашей пропускной способности, как и любое шифрование по быстрым ссылкам. Если у вас есть прямое соединение между компьютерами или безопасное внутреннее соединение, используйте прямое соединение X через TCP: 6000. Вы получите заметное улучшение скорости.
Астара

2
Похоже, вы пересылаете через SSH, который должен зашифровать / расшифровать все данные. Это собирается добавить накладные расходы / задержки. Могут помочь более быстрые процессоры, но это добавит определенную задержку, независимо от того, ЧТО вы делаете. X очень «болтливый», поэтому небольшое увеличение задержки = значительное снижение производительности. В прошлом я мог использовать X, туннелированный через SSH через 28.8 модем; он использовал lbxproxy (сейчас не рекомендуется), который кэшировал / сжимал много данных и уменьшал «болтливость» соединения. Использование -C может только увеличить задержку.
Meower68

Используйте что-то вроде ssh -Y -c blowfishминимизации накладных расходов при шифровании. Если у вас есть полный контроль над обоими сторонами, научите ssh использовать шифрование «none» для получения полной скорости передачи по соединению.
Торбьерн Равн Андерсен

Ответы:


116

Протокол X11 никогда не предназначался для графической обработки (с точки зрения растровых изображений / текстур) интенсивных операций. В те времена, когда X11 был впервые разработан, компьютерная графика была намного проще, чем сегодня.

По сути, X11 не отправляет экран на ваш компьютер, но отправляет инструкции по отображению, чтобы X-сервер вашего локального компьютера мог воссоздать экран в вашей локальной системе. И это нужно делать при каждом изменении / обновлении дисплея.
Таким образом, ваш компьютер получает поток инструкций, таких как «нарисовать линию этого цвета из координат x, y в (xx, yy), нарисовать прямоугольник шириной W пикселей, высотой H пикселей с верхним левым углом в точке (x, y) и т. Д. "
Локальный клиент на самом деле не знает, что нужно обновить, а в удаленной системе очень мало информации о том, что на самом деле нужно клиенту, поэтому в основном сервер должен отправлять много избыточной информации, которая может понадобиться или не потребоваться клиенту.
Это очень эффективно, если отображаемый экран состоит из ограниченного числа простых графических фигур и требуется только низкая частота обновления (без анимации и тому подобного). Что было в те времена, когда X11 был впервые разработан.

Но современные графические интерфейсы очень привлекательны, и большая часть этого должна быть отправлена ​​из удаленной системы вашему клиенту в виде растровых изображений / текстур / шрифтов, которые занимают довольно большую полосу пропускания. И все виды конфет включают в себя анимированные эффекты, требующие частых обновлений. И дисплеи тоже становятся все больше, в два раза шире / выше в 4 раза больше пикселей.

Конечно, со временем были внесены улучшения в протокол X11, чтобы максимально оптимизировать это, но базовый базовый дизайн, по сути, просто не совсем соответствует требованиям, которые ожидают люди с графическим интерфейсом в наше время.

Другие протоколы (например, RDP и VNC) в большей степени предназначены для того, чтобы удаленная система выполняла всю тяжелую работу и позволяла этой системе решать, какие обновления отправлять клиенту (в виде сжатых растровых изображений) настолько эффективно, насколько это возможно. Часто это оказывается более эффективным для современных графических интерфейсов.

Ни один из методов не идеален и может одинаково хорошо справляться с любой ситуацией. Не существует такой вещи, как единый протокол отображения, который может хорошо работать при любом возможном случае использования.
Поэтому в большинстве случаев вы просто пробуете все протоколы, которые поддерживаются между вашим локальным клиентом и удаленным сервером, и используете тот, который дает наилучшие результаты. А в некоторых случаях нет выбора, и вам просто нужно обойтись тем, что доступно.

Большинство протоколов допускают некоторую настройку производительности, но многие из этих настроек предназначены только на стороне сервера и недоступны для обычного пользователя. (И их правильная настройка - немного загадочное искусство. Многие системные администраторы не захотят с этим связываться.)

В большинстве случаев самый простой способ повысить производительность (иногда весьма радикально) - это перейти на более простую рабочую среду с меньшими затратами времени и отказаться от использования фоновых изображений.


15
+1 Поскольку упоминаются RDP и VNC, я должен также упомянуть x2go - решение для кэширования / пересылки X11, которое действительно ускоряет пересылку X11. Я использовал это с успехом в прошлом.
Рат

7
Что касается «настроек только на стороне сервера», то напомним, что X- сервер работает на компьютере, который подключен к физическому дисплею, а X- клиент - это программное обеспечение, используемое для выполнения какой-либо задачи (например, веб-браузер или текстовый процессор). ). Таким образом, настройки X-сервера будут доступны пользователю, подключающемуся к удаленной системе, для запуска графического приложения. Это, однако, существенно не умаляет ценность вашего ответа.
CVn

2
Технически протокол RFB, а не VNC.
OrangeDog

6
Я не прав или вы путаете клиента и сервера во втором абзаце? Клиент - это программа, запущенная удаленно, сервер - локальный компьютер.
Йонас Шефер

2
То, о чем вы рассказывали в третьем абзаце, было в значительной степени смягчено в 1990-х годах, когда на машинах с X-серверами стало достаточно памяти, и создание хранилища резервных копий стало практичным делом.
Blrfl

45

Существует в первую очередь две причины замедления соединений X11, которые вы затронули в своем вопросе: пропускная способность и задержка. Чтобы понять, почему приложения X11 работают медленно в сети, давайте обсудим оба из них.

Пропускная способность

По умолчанию X11 не выполняет никакого сжатия сетевых данных, передаваемых между приложением и сервером отображения. Как вы упомянули, вы можете использовать опцию -C в SSH, чтобы включить сжатие, и хотя это помогает, оно не оптимизировано для сжатия графических данных. По сравнению с такими форматами, как H.264, которые могут получить степень сжатия от 100 до 1, сжатию -C удастся достичь сжатия 2: 1. Лучшим решением является использование кодека, оптимизированного для графики или видео, для видео X11, но мы должны быть осторожны, чтобы не сделать его слишком потерянным, поскольку на настольных компьютерах, как правило, должны быть более четкие изображения, чем в фильме, чтобы пользователь по-прежнему мог четко читать текст и разглядеть мелкие детали.

Задержка

X11 имеет тенденцию к высокой задержке, потому что большинство операций требуют многократных циклов между приложением и сервером дисплея. При запуске через локальную сеть, где время пинга составляет менее миллисекунды, эти многочисленные обходы не заметны, но при подключении к Интернету они быстро складываются.

Решения

Несколько лет назад было разработано несколько проектов для решения проблем пропускной способности и задержек, присущих протоколу X11. lbx (низкая пропускная способность X) и dxpc (дифференциальный X протокол сжатия). Я не думаю, что lbx когда-либо пользовался большой популярностью, но dxpc стала базовой технологией, используемой для продукта под названием NX . NX использует сжатие с потерями для уменьшения требований к полосе пропускания, а также дифференциальный алгоритм и кэширование для уменьшения количества передачи информации вперед и назад, что создает высокую задержку. Я довольно часто использую NX и считаю, что производительность почти такая же, как у локальных приложений. Если вам это нравится, вы можете попробовать NX и посмотреть, работает ли он для вас. Недостатком является то, что требуется установка программного обеспечения на обоих концах соединения, тогда как X11, как правило, уже установлен.


3
Тема задержки должна быть связана с тем, что X11 будет TCP, а не UDP для большинства потоковых видео. Есть несколько других продуктов, которые помогут работать удаленно. Тони упомянул RDP и VNC. Oracle все еще продает Sun Global Desktop (SGD), который работает хорошо. У Citrix было что-то (XenApp?). Наш eval нашел SGD лучшим вариантом для наших нужд, но ранее использовал два продукта Citrix.
соня ласка

x2go работал очень хорошо, даже с «серверным» старым ноутбуком. до и работает в течение нескольких минут ... большой прирост производительности от Х11 FWD (непригодный для использования с моей конфигурацией)
конт

В случае задержки на машинах * ix сеансы X11 для локальных дисплеев обычно используют доменные сокеты Unix вместо TCP; Доменные сокеты Unix во много раз быстрее, чем TCP, даже для localhost stackoverflow.com/questions/14973942/… . Для приложений X11 с действительно патологически большим количеством циклов обмена может быть разница между нормальной и заметно медленной производительностью.
Ракслице
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.