Привет, Хабр! Меня зовут Артём, и я менеджер продукта РЕД ВРМ. Чуть ранее я размещал статью, в которой рассказал о разработке РЕД ВРМ, планах развития и технических особенностях продукта. В сегодняшнем материале я, как и обещал, расскажу о протоколе RED DIRECT и раскрою новые фичи, которые появятся в ближайшем релизе.
Для начала хотелось бы рассказать о том, как связан протокол RED DIRECT с VDI и Терминальным доступом.
О роли протокола удаленного доступа в системах VDI
Обычно инфраструктура виртуальных рабочих мест строится из таких компонентов, как:
Брокер — приложение, позволяющее автоматизировать и масштабировать создание рабочих мест, управлять и централизовать доступ
Клиентское приложение — пользовательское приложение, с помощью которого сотрудники получают свои виртуальные рабочие столы
Агентское приложение — серверная часть, которая устанавливается на конечном рабочем столе и отвечает за виртуализацию и предоставление рабочего стола конечному пользователю
Протокол входит в состав как клиентского приложения, так и агентского, поскольку имеет клиент-серверную архитектуру. Он отвечает за пользовательский опыт работы с виртуальными рабочими местами: насколько качественное будет изображение, какая периферия будет подключена и многое, многое другое.
Более того, возможности протокола становятся фактором выбора конкретного VDI-решения. Из самого наглядного — если у организации есть требование к использованию смарт-карт, а все документы подписываются через ЭЦП, то без проброса смарт-карт через протокол решение будет бесполезно в глазах пользователя.
Смотрим на опыт коллег по цеху
Перед тем, как браться за создание протокола, мы основательно изучили рынок. Если посмотреть в сторону западных решений, то у любого из них есть собственный протокол. Как правило, у каждого вендора поддерживается и развивается только он, причем каждый протокол обладает своими особенностями (Citrix — ICA(HDX), VMware Horizon — Blast, Microsoft — RDP).
На российском рынке существует достаточно много решений, которые основаны как на собственных протоколах в составе VDI, так и на стороннем решении вендора. Встречаются и адаптации open-source продуктов.
Взвесив все за и против, мы остановились на оптимальном варианте. Выбрали решение, на базе которого будем вести всю разработку и которое сможем в конечном итоге полностью переписать (исходные проекты xfreerdp и xrdp, совместимые с виндовым протоколом RDP), и начали делать сразу всё: и свой собственный протокол, и свою систему управления (брокер).
Сложности разработки протокола и решения, заложенные в RED DIRECT
Буфер обмена и как его со всеми подружить
Казалось бы, буфер обмена ― достаточно простая вещь. Но не в Linux! Ведь в Linux нет единой стандартизации не то, что для различных дистрибутивов, но и для разных графических оболочек. Для буфера обмена существует стандарт передачи текста, а для всего остального такой стандарт отсутствует. В связи с этим некоторые программы могут работать по-разному и выдавать ошибки. Значит, наш буфер обмена нужно со всеми этим программами как-то «подружить».
Как решили проблему:
Провели исследование различных файловых менеджеров и многих базовых приложений. Изучили, каким образом они передают данные, а затем тестировали и внедряли их механики в RED DIRECT.
Также оптимизировали скорость передачи файлов, чтобы даже самый тяжеловесный документ копировался разумное количество времени. Для оптимизации использовали виртуальную файловую систему Fuse.
Подключение принтеров
Основная проблема заключалась в том, что многие производители пишут программу и отдельный драйвер для работы со своими устройствами. Соответственно, сложно применить в рамках протокола один и тот же подход к технике от различных производителей.
Как решили проблему:
Существует общий стандарт работы с принтерами ― CUPS, который многие производители стараются поддерживать. Мы добавили в протокол поддержку CUPS, а над совместимостью тех принтеров, которые в целом не адаптированы под Linux, планомерно работаем отдельно.
RemoteApp. Ломаем и чиним окна приложений
В протоколе RDP (под Windows) RemoteApp реализован достаточно специфическим образом. Вы не запускаете непосредственно отдельную программу ― создается подключение к компьютеру, на котором запущен RemoteApp. Но вместо всего монитора видно только окошко запущенного приложения. То есть получается, что у вас «вырезается» по сторонам всё лишнее, а показывается только окно запущенной программы.
У этой фичи есть свои неоднозначные моменты. Например, когда вы перемещаете документ Word по монитору, то же самое происходит и на машине, с которой транслируется приложение. Одно неверное движение вбок ― и за рабочую область могут «уехать» какие-нибудь части интерфейса. Например, контекстное меню вылезет правее транслируемой зоны. Аналогичные проблемы могут возникнуть из-за разного разрешения экрана. Также в операционной системе Windows есть свои стили элементов и анимации, которые могут нагружать канал и создавать ��еочевидное поведение для отображения.
Как решили проблему:
Большая часть проблем с отображением убирается за счёт их целенаправленного поиска и устранения вручную. Мы буквально моделировали все возможные ситуации и пытались «сломать» отображение мыслимыми и немыслимыми способами. А затем закладывали в наш протокол меры, не допускающие такие сценарии. Некоторые вещи пришлось «перерисовывать» в полуручном режиме.
Итак, в апреле 2025 года мы выпустили самый первый публичный релиз РЕД ВРМ. В первой итерации мы:
Реализовали поддержку рабочих мест на базе ОС Windows и РЕД ОС как на клиентской части, так и в части агентского приложения.
Достигли возможности кроссплатформенного подключения.
Реализовали текстовый и файловый буфер обмена (во всех вариациях подключений).
Реализовали проброс смарт-карт на виртуальные рабочий стол на базе ОС Windows.
Но этого функционала достаточно только для MVP, а не для покрытия всех сценариев использования
Итак, это был наш первый выпуск протокола. Мы получили очень много обратной связи и «хочу», сформировали новое ТЗ и готовимся к глобальному обновлению.
Как и обещал, приоткрываю завесу тайны и делюсь подробностями обновления, которое увидит свет в 1 квартале 2026 года. Более того, все эти фичи можно протестировать уже сейчас в закрытой бете Терминальной редакции:
Многосессионный режим на виртуальных рабочих местах (терминальные сервера и фермы). Это позволит создавать множество сессий на одном сервере.
Поддержка Windows RemoteApp. Теперь пользователи, у которых стоит РЕД ОС, могут получить приложения доступные только на Windows в виде отдельного окна.
Поддержка нескольких мониторов, теперь можно получить виртуальный рабочих стол сразу на несколько мониторов.
Поддержка принтеров. Пользователи смогут использовать свои локальные принтеры при работе с удаленными рабочими столами и приложениями.
Проброс аудио и микрофона во всех подключениях, а также проброс камер для подключений Windows - > Windows. Это позволяет проводить ВКС на удаленных рабочих местах.
Теперь пользователи могут пробрасывать локальные папки, диски, а также флешки как файловое пространство на виртуальные рабочие места и работать со своими документами.
Расширен функционал проброса смарт-карт. Теперь можно работать со смарт-картами на виртуальных рабочих столах под управлением РЕД ОС.
За год мы постарались проработать все возможные сценарии пользовательского опыта при работе с VDI-системами, переработали большое количество кодовой базы и двигаемся к полностью независимой системе, в которой есть комплексное решение для любых задач в рамках VDI и терминального доступа.
