Битва протоколов. Сравнение SPICE, RDP и TERA

А нужно ли биться?..

Немного вводных
Привет! Сегодня пройдемся по сравнительным характеристикам протоколов удаленного доступа, которыми пользовались миллионы людей в период пандемии, но не придавали этому значения с точки зрения нагрузки на каналы связи.

Многим компаниям сейчас приходится выбирать альтернативные VDI-решения взамен ушедшим. Коллеги рассматривают не просто работающие в моменте продукты, а решения с заделом на будущее.

Вперед всегда заглядывать немного страшно, но невероятно интересно. В 2022 году команда Termidesk почувствовала готовность вложиться в подобное узкоспециализированное решение — собственный протокол удаленного доступа, о котором и пойдет речь в этой статье. Она продолжает текущий цикл материалов о Termidesk.

В предыдущих сериях:

• VDI / DaaS / Termidesk;

• Создаем VR офис с Termidesk и Oculus;

• Termidesk 6 лет спустя: куда движется российский VDI;

• Разработка через Termidesk: утопия или рабочая реальность разработчика.

Успешные кейсы внедрения иностранных VDI-продуктов были связаны не только с аспектами безопасности, которые предлагает технология, но и с разработками самих компаний, которые приобретали наработки по протоколам удаленного доступа и вкладывались в их развитие.

Яркими представителями подобных протоколов являются:

• Blast Extreme от компании VMware;

• HDX (ICA) от компании Citrix.

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

Во многом именно поэтому подавляющее количество отечественных решений, которые реализуют функционал VDI или терминального доступа, основываются на иных протоколах:

• SPICE;

• RDP;

• X2GO.

Немного остановимся на каждом из них.

Справка по протоколу SPICE — Simple Protocol for Independent Computing Environment.
В 2008 году Red Hat поглотила израильскую компанию Qumranet, которая разрабатывала гипервизор KVM (Kernel Virtual Machine) и протокол SPICE с 2005 года.
Далее в 2009 Red Hat объявила об открытии исходного кода протокола SPICE, тем самым сделав его доступным для совершенствования энтузиастами во всем мире.
Однако уже в 2021 Red Hat объявляет о прекращении поддержки протокола SPICE.

Одно из ключевых отличий протокола: подключение по SPICE осуществляется непосредственно к гипервизору, а не к операционной системе.
Дополнительная информация доступна на сайте проекта.

Справка по протоколу RDP — Remote Desktop Protocol
RDP становится известным широкой общественности за 10 лет до появления SPICE — ориентировочно в 1998 году, после приобретения компанией Microsoft наработок PictureTel.

Все это время Microsoft активно развивает проприетарный протокол RDP, официальная версия которого на момент написания статьи — 10. Актуальная версия протокола (безусловно, отлично задокументированная) описана в различных сценариях использования и обладает поддержкой высокоэффективного кодирования видеоизображений при помощи кодека H.264/AVC 444.

Несмотря на закрытость протокола, сообщество Open Source-разработчиков осуществляет открытые реализации как клиентов, так и серверов RDP. Например, freerdp и xrdp.
Обратная сторона этой медали проявляется в регулярном появлении 0-day уязвимостей протокола.

Справка по протоколу X2GO — Remote Desktop Protocol
X2GO разработан на базе протокола NX, но не является совместимым с другими реализациями данного протокола, который начиная с 4-ой версии стал проприетарным. Первые наработки по X2GO отмечены в репозитории проекта в 2014 году.
К основной особенности его реализации можно отнести функционирование на основе обязательного взаимодействия с SSH-сервером, что потребует явного открытия всех требуемых портов на межсетевых экранах компаний, использующих подобные протоколы.

Подробная информация с полным списком используемых сетевых портов подключения доступна на сайте. 

SSH — безопасный протокол для удаленного управления операционными системами при помощи командной строки, однако, учитывая его возможности, будет не лишним помнить про особый интерес злоумышленников в эксплуатации его 0-day уязвимостей.

Как видим, есть за что побороться. И следующий шаг в сфере протоколов — наш прорыв в мире отечественного VDI. Это протокол TERA собственной разработки.

2. TERA выходит в свет

Почему появился TERA

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

Экспериментальная версия протокола впервые вошла в поставку Termidesk в версии 5.0.

Например, когда мы реализовывали функционал для управления активными сессиями пользователей при подключении по SPICE, нам понадобилось разработать отдельный компонент — агент узла виртуализации. Он централизованно предоставляет подобную возможность на уровне гипервизора. Подобные агенты имеют особенности реализации для различных платформ виртуализации, не смотря на то, что гипервизор используется идентичный — KVM.

Возможности SPICE в части управления полосой пропускания, использования видеокодеков и алгоритмов сжатия были также «прибиты» к гипервизору и вычислительным нодам виртуализации. Это мешало как гранулярно подходить к вопросам оптимизации передаваемого трафика в отдельных каналах, которые используются в SPICE, так и реализовывать ограничения, связанные с требуемыми политиками информационной безопасности.

Процесс внедрения решения Termidesk осложняют несколько условий: многообразие платформ виртуализации, используемые гостевые ОС и предъявляемые требования к решению.

С выходом TERA видится, что все подобные особенности внедрения могут сильно упроститься до трех принципиальных действий:
• установки модуля виртуального апплаенса (впервые появился в версии 4.3);
• установки агентов VDI, включая сервер для подключения по протоколу TERA в гостевую ОС;
• интеграции Termidesk с инфраструктурой заказчика (обновленная программа курса уже доступна в авторизованных учебных центрах).

Так что особенного в протоколе TERA? Если описывать одним предложением, это выглядело бы так: мы взяли преимущества SPICE при доставке мультимедийного контента на клиентские устройства пользователей и унифицировали реализацию программных решений за счет используемого сервера подключений в гостевой ОС аналогично с тем, как это представлено в RDP.

А теперь предлагаю взглянуть, как просто выглядит переход на TERA. 

В 4-минутном видео мы можем наблюдать подключение к ВРМ пользователя по SPICE, установку TERA в гостевую ОС Astra Linux и заблокированную возможность подключения при помощи графического драйвера QXL. Подобный черный экран будет отображаться во время подключения из платформы виртуализации к консолям ВРМ и переподключения к ВРМ по протоколу SPICE. Вместо этого после установки TERA в гостевую ОС подключение происходит с использованием драйвера виртуальной карты.

Дополнительно отмечу, что все параметры протокола выделены в отдельный файл конфигурации, который доступен в гостевой ОС с установленным сервером TERA по адресу /usr/share/X11/xorg.conf.d/30-spiceqxl.xorg.conf

3. Набираем обороты

Сравним протоколы по занимаемой полосе пропускания
Прежде чем предоставить сравнительные значения, стоит описать структуру тестового стенда, сценарии тестирования и инструментарий, с помощью которого мы фиксировали результаты.

Тестовый полигон использовался на основе существующего демо-стенда в составе:
• 3 ВРМ под Astra Linux 1.7.5 (базовый режим работы СЗИ) c 2 vCPU и 2 Gb ОЗУ;
• 2 ВРМ под Windows 10 c 4 vCPU и 4 Gb ОЗУ.

Между различными ВРМ проводились контрольные замеры по разным протоколам в соответствии со сценариями тестирования.
Структурная схема тестового стенда и вариации тестирования по различным протоколам приведены ниже для наглядности.

6 сценариев тестирования и расчет пропускной способности
Приведенные сценарии воспроизводились для конфигурации с одним монитором в разрешении Full HD (1920x1080 пикселей):

1. Простаивание: нет активного обновления экрана, пользователь приостановил работу.
2. Офисный сценарий — текстовый редактор: пользователь активно набирает текст, работает с изображениями и использует операции для форматирования документов.
3. Офисный сценарий — табличный редактор: пользователь создает и наполняет таблицы, форматирует данные и строит на их основе диаграммы.
4. Просмотр веб-страниц: пользователь активно работает с веб-сайтами, содержащими как текст, так и анимации.
5. Просмотр изображений: пользователь в полноэкранном режиме просматривает слайд-шоу из 12 изображений.
6. Просмотр видео: пользователь смотрит видео в полноэкранном режиме.

Алгоритм тестирования состоял в подключении с ПК в ВРМ-(X) тестового стенда по протоколу SPICE. Далее из ВРМ-(X) осуществлялось подключение по тестируемым протоколам в ВРМ-(Y) и запускалось ПО для измерения объема получаемого ВРМ-(X) и передаваемого с ВРМ-(Y) сетевого трафика.

Так как вариативность ОС в точках подключения состояла из Windows и Linux, то для идентичности измерений пропускной способности мы выбрали ПО Wireshark (www.wireshark.org), которое доступно для использования на всех тестируемых системах.

На протяжении каждого эксперимента Wireshark захватывал трафик на сетевом интерфейсе клиентского устройства ВРМ-(X). После выполнения сценария тестирования контрольное значение средней полосы пропускания отображалось в статистике файла захвата: «Статистика» → «Свойства файла захвата».

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

Все полученные значения полосы пропускания далее указываются в килобитах в секунду (kbps). Для сравнения со значениями в других источниках, указанными в килобайтах в секунду (kBps), их достаточно поделить на 8 (1 kbps = 0.125 kBps). Также полученные значения для простоты восприятия округлены в пределах 2%.

Результаты говорят нам, что уже на старте TERA способен конкурировать с протоколами, которые развивались больше десяти лет. И это только начало! Уже в новом релизе протокола (релиз Termidesk 5.1 запланирован на ноябрь 2024 г.) появится новый функционал и еще больше возможностей для оптимизации полосы пропускания.

4. Пробуем TERA в действии

Создавая TERA, мы ставили перед собою несколько задач:
• представить решение, которое будет сочетать в себе лучшие качества открытых и проприетарных протоколов;
• с самого начала заложить в основу TERA элементы информационной безопасности;
• сделать максимально унифицированное решение, чтобы пользователю было комфортно работать в течение всей сессии, а администратор имел широкие возможности для конфигурации протокола.

Уже сейчас подключение по TERA к Astra Linux 1.7 может опробовать в экспериментальном режиме каждый желающий. Вот подробный гайд.

При этом после инсталляции подключиться к ОС с установленным TERA сервером будет можно будет при помощи termidesk-viewer (доступен на https://repos.termidesk.ru) и указания параметров подключения spice://ip.addr:port.
Чтобы вернуть возможность подключиться к тестовой машине по SPICE, достаточно будет удалить пакет драйвера виртуальной видеокарты tera-xf86-video-qxl.

По техническим аспектам настройки можно обратиться в наш чат. Там мы разберем ваш вопрос и поможем.