Система удаленного доступа — это клиент, брокер, агенты на серверах. Все это нужно, чтобы десятки тысяч пользователей попали к нужным приложениям на нужных серверах с нужными политиками. Но когда соединение установлено, в дело включается протокол: будет ли картинка рваться при плохой связи, пробросится ли нужное устройство, будет ли соединение зашифровано по ГОСТ без костылей. Год назад мы в Orion soft решили, что работать в рамках чужих архитектурных решений дальше невозможно, и начали писать протокол с нуля.

Меня зовут Александр Донин, я технический менеджер платформы VDI и терминального доступа Termit. В этой статье я расскажу, как устроен наш протокол Pulsar и какие решения мы принимали в процессе его разработки, чтобы было понятно, почему российскому энтерпрайзу недостаточно допиливания Open Source и чем отличается протокол, с самого начала спроектированный под реальные сценарии использования.

Протокол как основа

По данным нашего опроса, только 16% компаний полностью перешли на отечественные решения для терминального доступа и VDI. Остальные продолжают работать на зарубежных Citrix, VMware Horizon, несмотря на то, что новые версии, обновления и поддержка для них в России недоступны.

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

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

Опенсорс-протоколы эти задачи закрывают частично: они не проектировались под корпоративные сценарии, которые возникли позже. Проприетарные зарубежные решения эту гибкость дают, а российские пока нет. Именно поэтому мы начали делать Pulsar.

Почему не форк

Когда встал вопрос про протокол, мы рассматривали оба пути — доработать готовое решение или писать с нуля. Наши конкуренты на рынке брокеров и VDI шли первым путем, и это понятный варант: открытые протоколы существуют давно и каждый решает свою задачу. VNC подключает к существующей сессии, SPICE — к виртуальной машине через гипервизор, X2Go реализует терминальный доступ в Linux и даже умеет в RemoteApp, но работает только с Linux. FreeRDP — реверс-инжиниринг RDP для работы в Linux, а реверс-инжиниринг по определению означает нестабильное и непредсказуемое поведение.

Мы когда-то приняли другое решение и написали Termit с нуля. С Pulsar то же самое. Рано или поздно легаси начинает диктовать архитектурные решения не потому что так правильно, а потому что иначе все сломается. Плюс в чужой код сложно встраивать свои функции без компромиссов. И чем дальше идешь по этому пути, тем дороже каждое следующее изменение, поэтому лучше потратить больше времени в начале, чтобы не тащить этот груз дальше. Нам же был нужен один протокол для всех систем — Linux, Windows, в перспективе macOS — который мы сами поддерживаем и развиваем.

Отдельная причина написать свое с нуля — транспортный уровень. SPICE и FreeRDP работают только поверх TCP, VNC поддерживает UDP лишь в некоторых коммерческих ветках. Мы хотели модульную систему с поддержкой и TCP, и UDP, чтобы выбирать транспорт под сценарий. Первым модулем выбрали UDP: он лучше переживает потери пакетов на нестабильных каналах, а это наш приоритет номер один. При этом контроль доставки в протоколе есть — как именно он устроен и как в целом организован транспортный уровень Pulsar, расскажем в следующей статье.

Как появился Pulsar

Наша компания называется в честь созвездия, и большая часть продуктовой линейки держится на космических метафорах: Orion, Nova, Termit — исключение, но и оно про природу. Пульсар — это нейтронная звезда, которая быстро вращается и посылает стабильные всплески излучения с точностью часового механизма. Мы увидели аналогию с протоколом: быстро, стабильно, с предсказуемым ритмом. Так и назвали.

Команду собирали под конкретные задачи, а не под роли: отдельный человек под звук, отдельный специалист под Windows, который в Linux не заходит и которому это не нужно. Транспортным уровнем занялся разработчик с алгоритмическим бэкграундом, который сейчас отвечает за многопоточность и асинхронную работу.

В процессе поиска людей выяснилось, что специалистов с опытом разработки протоколов удаленного доступа с нуля на рынке крайне мало, это узкая область, и большинство, кто в ней работал, работал с готовыми стеками, а не строил свои. Поэтому искали сильных C++-разработчиков и проверяли на собеседовании не знание терминов, а умение объяснить сложное просто. За год команда выросла с трех человек до полноценного отдела разработки.

Основные принципы

Главный приоритет первой версии — это устойчивость на слабых каналах. Модульность, многоканальность, приоритизация трафика, все это архитектурный фундамент для развития протокола. Но в первой версии стабильная работа при потерях пакетов и узких каналах была важнее всего остального.

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

Многоканальность — разделение потоков по типу данных. Сигнал мышки, картинка экрана, звук, управляющие команды — каждый идет в своем канале с собственным приоритетом. В большинстве Open Source протоколов все это идет в одном потоке: один тип данных забил канал и страдает все остальное, как машины в одной полосе. Как именно мы реализовали многоканальность на транспортном уровне, расскажем в следующей статье.

TLS выбрали как основу криптографии: в будущих версиях это позволит добавить поддержку ГОСТ-сертификатов без переделки архитектуры шифрования. Наложенные средства шифрования снижают эффективность любого протокола, они упаковывают его в еще один протокол, и все оптимизации трафика теряют смысл. Этого хотелось избежать с самого начала.

Что уже умеет первая версия

В определении приоритетов исходили из простого вопроса: что нужно максимальному числу пользователей прямо сейчас. Нужна стабильная работа на слабых и нестабильных каналах при большом числе одновременных сессий. Это характерно для банков, нефтегаза и энергетики: у них много пользователей в регионах, серверы сосредоточены в одном-двух дата-центрах, а соединение между филиалами идет через узкие каналы. Подключение через VPN в таких условиях — это норма, а не исключение. 

Работа с 3D-графикой — отдельная история. Это нишевый сценарий, условно 5% пользователей в компании. Для них сейчас есть интеграция с внешним протоколом, и это не часть Pulsar. Поддержка 3D-ускорителей появится в следующих версиях.

Linux получает первый приоритет по платформе. Это общий тренд: компании переходят на отечественные ОС, и потребность в качественном удаленном доступе к Linux-системам растет. Исторически здесь не было сильных решений — тот же Citrix, несмотря на заявленную кроссплатформенность, значительно богаче по возможностям на Windows. Первая версия Pulsar закрывает подключение к Linux с Linux и Windows-клиентов.

Где сейчас Pulsar и куда идем

Говорить, что Pulsar в ближайший год станет полноценной альтернативой HDX и Blast, было бы неправдой. Мы делаем первые шаги в эту сторону и понимаем, что дорога длинная, но именно туда и идем.

Ближайшая точка — Termit 2.6, конец третьего квартала 2026 года. Pulsar появится как опциональный протокол для подключения к Linux-системам: можно включить вместо X2Go и протестировать в реальной инфраструктуре. Часть возможностей X2Go пока не будет закрыта — например, гранулярные политики. Это осознанное решение: лучше дать протокол для тестирования раньше, чем ждать полного паритета по функциям.

В первой версии Pulsar будет: подключение к Linux в режиме полноценного рабочего стола и отдельных приложений (remote app), работа в сценариях VDI и терминального доступа, проброс клавиатуры, мыши, буфера обмена — текст и файлы, поддержка принтера, SSO через Kerberos. Плюс панель мониторинга сессии: потери пакетов, задержка, загрузка канала — все в одном месте.

В версии 2.7 Pulsar должен полностью заменить X2Go — с лучшим качеством на нестабильных каналах, меньшим потреблением полосы и расширенными возможностями управления сессией. Например, буфер обмена можно будет настроить в одну или обе стороны, добавится управление передачей файлов. X2Go останется как резервный вариант, но основным протоколом для Linux станет Pulsar.

Следующая веха — замена не только X2Go, но и RDP. Pulsar станет протоколом по умолчанию для Linux и Windows, в идеале и через веб-клиент. Это оптимистичный сценарий, сроки пока не называем.

Сейчас команда, которая обслуживает протокольный стек в Termit, держит в голове несколько разных протоколов одновременно. Когда Pulsar закроет все сценарии, этот зоопарк можно будет выкинуть. Параллельно протокол будет развиваться за пределами Termit — в составе системы виртуализации zVirt, чтобы обеспечить удаленный доступ к виртуальным машинам напрямую.

Что дальше

Следующая статья будет про транспортный уровень: как выбирали между TCP и UDP, какие решения приняли и что это дает архитектуре. Там есть что рассказать по инженерной части. И напоследок, если есть что-то, что хотели бы видеть в панели мониторинга — напишите в комментариях, учтем при разработке.