Чому пересилання X11 настільки неефективне?

Щоразу, коли я віддалено запускаю великі графічні інтерфейси з переадресацією X11, навіть включаючи перемикач -C, досвід дуже не відповідає. Моє запитання полягає в тому, що це означає на рівні концепції / протоколу?

За допомогою мого підключення 25 Мбіт я можу без проблем передавати HD відео на свій комп'ютер. З іншого боку, безвідповідальність віддалено запущених графічних інтерфейсів з переадресацією X11 відбувається навіть через локальну мережу 100 Мбіт, де затримка повинна бути майже нульовою.

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

По-друге, пропускну здатність. Чому воно з'їдає стільки його? Що стосується форматів зображень та відео, то для різкого зменшення розміру використовується багато методів.

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

Що стосується відеозаписів, цілу масу інформації можна зберегти, надіславши різницю між кадрами, а не цілими кадрами.

Я знаю, що це дуже спрощено, але хіба X11 не використовує ці методи? Чи поводиться вона в растровому або недиференційованому принципі на якомусь рівні? А якщо ні, то чому він займає стільки пропускної здатності?

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

В основному X11 не надсилає екран на ваш комп’ютер, але він надсилає інструкції до дисплея, щоб X-сервер на вашому локальному комп'ютері міг заново створити екран у вашій локальній системі. І це потрібно робити при кожній зміні / оновленні дисплея.
Тож ваш комп’ютер отримує потік інструкцій на кшталт «намалюйте лінію в цьому кольорі від координат x, y до (xx, yy), намалюйте прямокутник W пікселів у ширину, H пікселів високий з лівим лівим кутом у (x, y) тощо. "
Місцевий клієнт насправді не знає, що потрібно оновлювати, а віддалена система має дуже мало інформації про те, що клієнту насправді потрібно, тому в основному сервер повинен надсилати багато зайвої інформації, яка клієнту може або не потрібна.
Це дуже ефективно, якщо відображуваний дисплей складається з обмеженої кількості простих графічних фігур і потрібна лише низька частота оновлення (ніяких анімацій та подібних). Це було ще в часи, коли X11 був вперше розроблений.

Але сучасні графічні інтерфейси мають багато очевидних цукерок, і багато чого з цього потрібно надіслати з віддаленої системи своєму клієнту у вигляді растрових / текстур / шрифтів, які займають досить багато пропускної здатності. І всілякі цукерки для очей включають анімаційні ефекти, що вимагають частого оновлення. А дисплеї також збільшуються, вдвічі ширше / вище - це в 4 рази більше пікселів.

Звичайно, з часом було вдосконалено протокол X11, щоб максимально оптимізувати це, але основна конструкція, по суті, просто не відповідає вимогам такого типу, якого люди на сьогодні очікують.

Інші протоколи (наприклад, RDP та VNC) більш розроблені для того, щоб віддалена система могла зробити важку роботу і дозволить цій системі вирішити, які оновлення надсилати клієнту (як стислі растрові карти) максимально ефективно. Часто це виявляється більш ефективним для сучасних графічних інтерфейсів.

Жоден метод не є ідеальним і може однаково добре впоратися з будь-якою ситуацією. Немає такого поняття, як єдиний протокол дисплея, який би міг добре працювати при кожному можливому випадку використання.
Тож у більшості випадків ви просто намагаєтеся використовувати всі протоколи, які підтримуються між локальним клієнтом та віддаленим сервером, і використовуєте той, який дає найкращі результати. І в деяких випадках вибору немає, і ви просто повинні робити все, що є в наявності.

Більшість протоколів дозволяють налаштувати деяку продуктивність, але багато з цих параметрів є лише серверними і не доступні середньому користувачеві. (І правильно їх налаштувати - це трохи приховане мистецтво. Багато системних адмінів не будуть з цим возитися.)

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

В основному є дві причини, щоб з'єднання X11 були повільними, і обидві, яких ви торкнулися у своєму запитанні: пропускна здатність та затримка. Щоб зрозуміти, чому додатки X11 працюють повільно по мережі, давайте обговоримо обидва ці моменти.

Пропускна здатність

За замовчуванням X11 не робить стиснення мережевих даних, які передаються між програмою та сервером відображення. Як ви вже згадували, ви можете використовувати опцію -C на SSH, щоб увімкнути компресію, і хоча це допомагає, вона не оптимізована для стиснення графічних даних. У порівнянні з такими форматами, як H.264, які можуть отримати коефіцієнт стиснення 100-1, стиснення -С пощастить досягти стиснення 2-1. Краще рішення - використовувати графічний або відеооптимізований кодек для відео X11, але ми повинні бути обережними, щоб не зробити його занадто втраченим, оскільки на робочих комп’ютерах, як правило, потрібно мати чіткіші зображення, ніж фільм, щоб користувач міг чітко читати текст і оформляти дрібні деталі.

Затримка

X11 має тенденцію до високої затримки, оскільки для більшості операцій потрібні багаторазові рейси між додатком та сервером дисплея. Якщо ви працюєте через локальну мережу, де пінг-параметр менший мілісекунди, ці багаторазові поїздки не помітні, але через Інтернет-з'єднання вони швидко накопичуються.

Рішення

Кілька років тому було створено пару проектів для вирішення проблем пропускної здатності та затримки, притаманних протоколу X11. lbx (низька пропускна здатність X) і dxpc (диференціальний компресор протоколу X). Я не думаю, що lbx ніколи не отримував великої тяги, але dxpc став базовою технологією для продукту під назвою NX . NX використовує як стиснення втрат для зменшення вимог до пропускної здатності, так і диференціальний алгоритм та кешування, щоб зменшити кількість передачі інформації назад і назад, що створює високу затримку. Я використовував NX досить часто і вважаю, що продуктивність майже така ж, як і локальні програми. Якщо ви відчуваєте себе до цього, ви можете спробувати NX і побачити, чи працює він для вас. Мінусом є те, що він вимагає встановлення програмного забезпечення на обох кінцях з'єднання, тоді як X11, як правило, вже встановлений.