Какие темы раскрыты на мероприятии:

Сегодняшнее мероприятие ведет Руслан Белов, директор по продукту Space VDI. Он сказал, что протоколы доступа - интересная и сложная тема. И начал с того, что стал рассказывать про протокол GLINT, про проблемы протоколов и для чего нужен такой протокол. Чуть-чуть коснулся мировой истории протоколов.

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

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

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

И самый главный вопрос, зачем нужен какой-то протокол, зачем что-то придумывать, когда на рынке уже есть протокол RDP, им все пользуются, он удовлетворяет потребности рынка и очень хорошо оптимизируется самой компанией Microsoft. Это как раз одна из первых проблем этого протокола, это именно проприетарный протокол компании Microsoft, но тут же у него есть плюс, что он задает стандарты, он имеет на это право, он у нас один из первых, который появился в мире удаленного доступа, тем самым он может нам задавать правила, как мы можем строить наш протокол. Конечно, у каждого протокола есть свои особенности. И по поводу минуса RDB, он именно организован под экосистему Microsoft. Если у нас используются терминальные серверы, RDS и так далее, то RDP – это лучшее решение в этом плане, потому что они как бы нативно позволяют предоставить отдаленный доступ к данным решениям.

Но если мы уже переходим на текущий рынок, текущее положение операционной системы в нашей стране, то есть это уже операционные системы, основные на Linux ядрах, то есть Astra Linux, RedOS, то тут уже решение RDP затрудняет дальнейшее развитие и адаптацию под данные операционные системы.

Тем самым у нас появляются различные решения, как Open RDP, SPICE, VNC, которые предоставляют открытую пакетную базу, и мы можем использовать данные наработки и адаптировать их под свою экосистему. Из таких протоколов, которые я хотел обозначить в среде VDI, это соответственно протокол RDP, протокол BLAST и ECA, то есть протокол Citrix. Здесь на слайде он не показан, но он тоже очень популярен и часто используется. Преимущества данных протоколов здесь обозначено, то есть это большая поддержка и периферии, и вариантов шифрования. У BLAST есть своя проприетарная технология с балансировкой, но что и RDP, он предназначен именно под свою инфраструктуру, то есть под Windows, а BLAST предназначен именно для корректной работе в среди VMware. Всё это не позволяет ее взять и применить к VDI в наших решениях.

И поэтому первым, что было использовано, это протокол SPICE, VNC, такие как FreeRDP и xRDP. Они могут позволить предоставить удаленный доступ, но у них есть большие недостатки. В некоторых пакетах, нет поддержки звуков, нет, например, проброса некоторых устройств и кроме того они плохо адаптируются для плохих каналов, что является главной особенностью для решения VDI. То есть, когда мы строим сеть, рассчитываем ресурсы для каждого пользователя, мы должны четко понимать что нам необходима максимальная ширина канала, чтобы, соответственно, распределить ее по пользователям и быть уверенными, что, к примеру, в режиме нагруженной сессии, когда у нас сотни пользователей и в этот же момент они подключены к какой-нибудь ВКС, то есть идет и трансляция видео, аудио, задействованные устройства периферии, что наш канал выдерживает и мы попадаем под необходимые параметры.

Что касается протокола GLINT, то он имеет самые широкие настройки под профиль использования. То есть если мы зайдем в настройки самого протокола Glint, мы можем увидеть большое количество параметров, которые мы можем подстроить под определенные сценарии. В ближайшее время мы планируем выпустить упрощенный вариант этих настроек, то есть как в каких-нибудь приложениях есть выбор низкого качества, среднего качества, высокого качества, либо адаптация под ширину канала. Мы планируем реализовать такой вариант, чтобы администраторам, которые настраивают уже на клиентах эти настройки, было проще понимать, как настроить под конкретный сценарий использования. И дополнительно к этому также одна из основных возможностей - это централизованный доступ к настройкам протокола из самого диспетчера. В этом также плюс именно проприетарного протокола, потому что он наш, мы можем его адаптировать под системы VDI, мы можем управлять и настройками не напрямую из клиентской части. Основной, соответственно, это вход в доменную учетную запись, то есть без этого никак. И если брать решения, основанные на Open Source, то там в некоторых случаях данной возможности нет. Либо нужно дописывать, либо прикручивать какие-то дополнительные библиотеки.

Лимитирование задаваемой полосы пропускания, то есть это то, что мы можем указать под конкретную ширину канала и выше нее пользователи не займут канал. Доступность в режимах защищенной программной среды Astra Linux, здесь имеется в виду, что мы для решений Space диспетчер и Space клиент… (Space диспетчер — это брокер, который управляет подключениями пользователей, основывается на операционной системе Astra Linux, под который мы строим наш VDI). Поддерживаются другие операционные системы. С клиентской части это широкий спектр этих операционных систем. На серверной части мы представляем возможность именно двух ОС - RedOS и Astrа Linux. Здесь пока эти две операционные системы потому что они сейчас самые востребованные на отечественном рынке. И с Astra Linux мы проводим оценку совместимости в режиме защищенной программы среды.

Выбор протокола безопасности, управление качеством дискретизации звука. И также это основное, это гибкость в адаптации под конкретные решения. Второе основное качество проприетарного протокола, что мы можем менять кодовую базу. Тем самым уже заказчик может повлиять на развитие протокола и предложить какие-то решения, которые необходимы для его инфраструктуры. И последнее – это передача сигнала управления от пользовательских устройств на сервер для любых ресурсоемких программ и приложений. Здесь важное качество протокола GLINT в том, что он, даже если будет очень низкая пропускная способность канала, продолжит свое взаимодействие с удаленной сессией, не оборвется и будет поставлять нам сигналы в клиентскую часть. У нас даже будут поставляться кадры в 4 пикселя, мы ничего не будем видеть, но стабильность самого протокола продолжится, то есть осуществится самоподключение. И когда у нас сеть восстановится, соответственно, протокол займет ту ширину канала, которая ему необходима и продолжит свое взаимодействие. Это же еще одно преимущество над open source решениями.

Наш протокол использует пакеты freeRDP. Этим мы решили заняться еще в начале установления нашего протокола. Взяли этот протокол именно из тех оснований, что он очень хорошо подходит под Linux и его очень легко кастомизировать. От самого freeRDP мало что осталось, то есть мы переписали как клиентскую, так и серверную часть, но когда появляются какие-то новые решения от freeRDP, мы пытаемся их посмотреть, переписать код именно под свои решения.

Поэтому тут вы не найдете сам GLINT где-нибудь на внешних репозиториях, он у нас находится там, и в этом также его преимущество, где его никто не сможет из него как-нибудь сделать его варианты, которые нарушат безопасность. Возможности комфортной работы VDI, но это как я уже говорил, что аутсорсное решение freeRDP не позволяет комфортно работать в VDI, потому что оно занимает всю ширину канала, при низких пропускных способностях канала он начинает разваливаться и даже отключаться. У нас в какой-то момент может не быть сессии GLINT, а у нас при этом все будет поддерживаться. Здесь у нас все замечательно, и это обусловлено тем, что мы разбили протокол на модули, которые позволяют оптимизировать данный протокол в конкретной части. То есть это bitrate, framerate, звук и различные варианты работы с другими виртуальными каналами. То есть это и буфер обмена, и подключение устройств, и остальные варианты.

По поводу измерений. Здесь можно смотреть на график измерения протокола GLINT (см слайд выше). Проводился он при измерениях скорости потока в 30 мегабит в секунду. Здесь мы можем увидеть, что GLINT показывает среднее значение при каждом сценарии. То есть здесь у нас сценарий - это работа с 3D-моделированием, работа с просмотром YouTube во весь экран, в одну-вторую экрана, веб-серфинг, презентация, работа с таблицами и работа в текстовом редакторе. Сам протокол, если посмотреть по поводу RDP, он пытается занять максимальную ширину канала, поэтому мы видим здесь, что он упирается и в 30 мегабит в секунду в случае с средними значениями, и в пиковых значениях он может занимать и большую ширину канала. Даже если его ограничить, то он при первом подключении возьмет необходимое количество кадров и будет распределять уже нагрузку дальше. Bluetooth, соответственно имеет меньшую полосу пропускания  канала, в этом случае он не занимает его весь и пытается держать средние значения, то есть примерно как и протокол BLAST, если посмотреть по этому графику.

Перейдем теперь к периферии. Возможность GLINT в периферии обширные, это и подключение к проводной клавиатуре и мыши, работа с USB-устройствами, такими как флеш-накопители или же проброс каталогов.

Работа SmartCAD и токенов на данный момент реализована именно под токены ruToken. В текущем релизе идет расширение данной возможности и об этом мы говорим уже в нашем маршрутной карте. Работа USB-гарнитуры и воспроизведения звука, работа наушников, соответственно, гарнитура 3,5 мм. Работа USB-камеры с сжатиями, работа встроенных камер и работа с двумя мониторами для решения, когда необходимо, соответственно, передать картину на два монитора.