Contents
Удаленный рабочий стол
Копирование действий производимых на локальной машине на удаленную или на виртуальную удаленную.
Для удаленного доступа используются различные протоколы обмена графической информацией между удаленным устройством, которое имитирует экран, и локальной машиной. Характеристики протоколов:
- Сжатие
- Настройки сжатия
- Дополнительные возможности, такие как безопасность соединения
- соответствие определенным станадртом (открытость или закрытость стандарта).
Предшественники этих программ обеспечивали перехват управления терминалом, виртуальные терминалы, ssh -X.
Современные opensource-протоколы:
- VNC(rfb)
- RDP — более-менее открыли
- NX
VNC
Самый интересный обычно VNC. Изначально разработан Olivetti&Oracle, которую купила AT&T, но потом AT&T не потянула. После чего проект стал свободным. Проект можно рассматривать как пример крупного успеха open source. Модульная структура позволяет подключать различные модули сжатия.
RDP
описание протокола открыли, но действительно открытым он так и не стал. Mcrosoft вынудила это сделать европейская комиссия.
NX
NoMachine NX пошли другим путем, по принципу «если у нас есть иксы, зачем еще что то нужно». Сервер у них вроде бы только под Linux. Хорошо тем, что зная структуру примитивов X, мы можем их хорошо сжимать, поэтому nx позволяет вести быструю передачу даже по слабым линиям. Поддерживается шифрование протокола. Можно получить не просто удаленную сессию, но и хорошо защищенную удаленную сессию.
Сравнение скорости работы
- В локальной сети работает хорошо практически все.
- Если скорость порядка Mbit/s, то RDP дает картинку так себе. VNC только tight. nx работает.
- nx ом можно увидеть на сайте Etersoft — посмотреть, как работает 1С под Linux.
- nx позволяет запустить сеанс KDE 3 по модемному соединению.
- RDP кэширует начертание текстовых глифов на локальной стороне.
VNC бывают разные
UltraVNC: коммерческая разработка. В маке встроена.
Есть VNC-клиент на Java для телефонов.
RealVNC — продолжение разработки AT&T.
Никита Ющенко: Все перечисленные проекты VNC обладают одним единственным недостатком: они мертвы. Есть один живой, называется TigerVNC.
По RDP можно подключиться к VNC-серверу, даже из стандартного клиента Windows.
Применение в обучении
italc. позволяет управлять классом машин по сети, позволяет транслировать действия учителя, просмотр и контроль действий учеников, работает под Linux и под Windows, поддерживает защищенные соединения.
teachercp, совершенно не развивающийся проект. В отличие от italc, который транслирует на каждый рабочий стол свою сессию, teachercp мультикастит учительскую сессию. Требует настройки сети для поддержки multicast.
pyvnc2swf, основное назначение — если вам нужно записать ролик с какими то действиями. Покажет в том числе движение курсора.
Удалённый доступ для целей постоянной работы
Далее основной рассказчик — Никита Ющенко
Все задачи удаленного доступа делятся на 2 категории
- Залезть на удаленный сервер и там что-то поправить
- Постоянно работать удалённо
Требования в этих двух случаях разные. Во втором случае нужно создать иллюзию локальной работы. Пользование локальными устройствами, просмотр видео, запуск 3D-приложений. Это перечисленными продуктами не предоставляется. ЛВК занимается второй задачей.
Лет 10 назад все радовались ssh -X. Запускали на сервере xdm, к нему подключались несколько пользователей, все были счастливы. Но такая организация имеет несколько недостатков.
- для X-протокола фатален разрыв соединения. Существуют единицы
X-клиентов, способных обработать такую ситуацию. Это значит, что пользователь заняв терминал не может его освободить, не может переключаться. Возникает проблема того, что не хватает терминалов. И вообще длинно живущие сеансы не есть очень хорошо.
- X-протокол плохо работает удаленно. Там есть, например, window properties — произвольные данные, вешающиеся на окно, которые все современные тулкиты
активно используют. Если посмотрим на поток графической информации, то у нас есть в две стороны симметричные потоки, которые можно буферизовать. Но в X-протоколе помимо них есть запросы, требующие немедленного ответа, из-за которых X-протокол плохо работает удаленно.
- X-протокол по умолчанию никак не жмет графику. Есть расширение протокола xshm (X shared memory), когда графика по протоколу не передаётся вовсе. Поскольку обычно приложения запускаются локально, то все они ориентированы на этот факт, и как только приложение запускается удалённо, всё начинает резко тормозить. Чтобы нормально работать с графикой в X, надо хотя бы 100 Mbit/s.
Современные решения основаны на разведении двух протоколов — терминального и X-протокола.
RFB
Решается вопрос round trip'ов. Все запросы, требующие немедленного ответа, обрабатываются локально. RFB, однако, реализован очень просто и основан на передаче графики. Передается содержимое изменившихся прямоугольников. VNC позволяет по-разному кодировать эти прямоугольники:
- RAW — без сжатия
- RFE
- Tight — JPEG
Есть еще псевдокодировки. Например, copy: если какой-то прямоугольник переместился, то его не надо заново посылать, информация уже есть. Но их используют много для чего. Через псевдопрямоугольники передают изменение размера экранов, copy-paste. Расширения VNC как раз основаны на псевдопрямоугольники.
nx
С самого начала пытались оптимизировать X протокол для работы по сети. Первой попыткой было расширение LBX, ныне покойное. Было какое-то сжатие, были попытки уменьшить размеры полей, но результатов не было. В дальнейшем появился проект, вставлявший прокси между х-клиентом и х-сервером и тоже были попытки как то сжать. Плохо получалось из-за архитектурных ограничений х-протокола.
Х-протокол на самом деле хороший протокол, прожил больше 25 лет, но не для удаленных соединений.
nx было попыткой выжать из X-протокола всё, что возможно. Что они только не делали: сбор статистики, агрессивное кэширование. Трафик отличался в 10—50 раз, но тормозило нещадно, как раз из-за round trip'ов, тех самых запросов. В итоге все равно надо было делать сервер сеанса. Теперь у них есть nx agent который является X-сервером и обслуживающий локальные приложения. А с удаленным клиентом он уже соединяется по nx-протоколу. Родилось из xnest.
Сейчас nx сессия это nx agent, который по nx-протоколу соединяется с клиентом, на котором есть что типа еще одного xnest'a. Реализация nx agent доступна по GPL. Но из документации доступны только общие соображения, а там несколько мегабайт замысловатого исходного кода.
Там есть еще вторая половина. Сеансы надо создавать, аутентифицировать, и т. д. Всем этим занимает протокол поверх ssh, и это именно та часть, которую реализует FreeNX, которую реализует новое средство от гугл — Neatx. Сеансы nx можно запустить без этого, но много действий пришлось делать руками, и иногда он работал странно.
Архитектура когда есть сервер сеанса имеет модульность. Казалось бы, сервер сеанса мог бы раздавать по разным протоколам то, что оно получает — по RDP, по VNC.
X.org это эталонная реализация X-протокола. Там есть машинозависимая (DDX компоненты) и машинонезависимая часть. Xnest это DDX-компонент, VNC — тоже.
Существует ПО, которое по протоколу VNC дает доступ к внешнему X-серверу (x11vnc). Но на физическом уровне это не слишком эффективно.
Пытались скрестить nx и RFB. До конца довести не смогли. Да, внутри эталонной реализации реализации есть DDX компоненты, но nx на это плевали. Студент 2 года пытался раскопать там это, но так ему не удалось, работа повисла. Если кто хочет продолжить, информация доступна.
3D
Передача 3D. VirtualGL спонсировался Sun, для обеспечения 3D на sunray. Извлечь из GPU растр и передать на клиент. 2 транспорта для передачи растра. Первый — когда терминал работает по удаленному X-протоклу. Внедряется агент, который по TCP все передает. Другой вариант транспорта для клиентов, работающих по VNC. В этом случае созданный на GPU растр внедряется прямо в X-сервер, а потом передают VNC. Но VNC с передачей растра справляется плохо. Сделали TurboVNC с сжатием JPEG, ускоренным специальной аппаратной реализацией. Кроме того, всякое хитрое сжатие, с кнопкой «послать единовременно нормально». Сейчас Sun это более не спонсирует, но какое-то сообщество худо-бедно живое есть.
Сообщество VNC
Надо сказать про сообщество VNC. После взрыва активности в начале 2000-х организовались организации, продающие решения, а релизы прекратились. TightVNC стали активно продвигать в Red Hat, и так появился TigerVNC. У TightVNC и RealVNC команды придерживаются мнения «пользователей устраивает то, что есть» и протолкнуть патчи практически невозможно. TigerVNC это форк Tight'а. Там есть поддержка протокола TurboVNC поэтому они анонсируют поддержку KDE 4, композитинга, и т. п.
Проблема с клавиатурой. X keysуms. Если на клиенте и сервере отличаются кодировки, то ничего не работает.
Ещё про 3D
Чтобы закончить с 3D. VMGL. Они сообразили простую вещь. Если работает виртуальная машина на физическом сервере, а пользователь сидид за экраном, то GPU доступен всем. Проброс запросов к GPU с виртуальной машины на хост. Дает запускать дум в виртуалке.
3D сейчас проникает повсюду. Года через 3, возможно, нельзя уже будет браузер без 3D запустить. Встает вопрос о сущестовании тонких клиентов вообще, если проброс не получится.
Citrix есть, жив.
Проброс локальных устройств
Тема проброса локальных устройств. В RDP это отлично сделано, даже звук. NX звук тоже умеет.
Коммерческие продукты на VNC делают что-то для проброса локальных устройств.
TigerVNC образовалась вокруг людей из Red Hat и нескольких частных людей.
Передача видео
Еще одна вещь, был интересный проект — внедрение видео потока в VNC. Правда после защиты диплома студент это бросил.
- Еще к вопросу про «отдам в хорошие руки»: есть сборка nx agent под новые иксы.
AIGLX, compositing
Что такое direct rendering? Механизм прямого доступа к 3D-ускорителю. Потом хитрой схемой это совмещается с изображением на экране. AIGLX это когда команды даются х-серверу, а х-сервер к себе допускает зд драйвера. Потенциально он допускает работу с удаленным х-сервером.
VirtualGL работает просто как все гениальное. У OpenGL разделен рендер в буфер и показ буфера. VirtualGL вклинивается в этот момент и забирает готовый к показу буфер с видеокарты. Но он ничего не делает, чтобы оптимизировать передачу растра.
Компоизитнг это плохая для удаленной передачи вещь. Каждый кадр window manager выкачивает к себе. Запустите glxgears под KDE 4 и под dwm, производительность будет отличаться раз в 5.
И при этом KDE 4 нельзя запустить без композитинга.
Что такое композитинг? Классическая оконная система работает так — содержимое окна нигде не хранится, по необходимости перерисовывается. Композитинг — система хранит все содержимое всех топ-окон и на основе этой информации генерирует сцену. Для этого пришлось писать расширение X-протокола, позволяющее подписаться на сообщения об обновлении от другого окна. Композитинг перерисовывает практически все на каждый кадр.
В существующих реализациях композитинг делается клиентом, а на сервере это можно было бы все круто оптимизировать. Но ничего такого в работе вроде нет.
Есть еще проблема, юридическая: VNC распространяется под лицензией GPL, а у X.Org лицензия BSD. Поэтому их нельзя собирать в одном дереве.