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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

Существует в первую очередь две причины замедления соединений 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, как правило, уже установлен.