Перевод

Предисловие переводчика

По жизни и по работе (сначала в Wyse, потом в Dell, а теперь в Getmobit) я занимаюсь уже давным‑давно тонкими клиентами, VDI, терминальными серверами и всем, что с этими «темами» связано. В этой ситуации свойства разных протоколов удаленного доступа откладываются в голове крепче «Устава внутренней службы». Однако, жизнь меняется и «Уставы» постоянно нужно обновлять, особенно в ситуации, когда нам всем приходится сталкивать с «заново изобретенными» ОС, приложениями, VDI, ВКС и так далее. Просматривая инет в поисках новостей по протоколам, я наткнулся на цикл статей Артура Оглоза, сравнивающих текущие версии протоколов с неожиданной (для меня во всяком случае) стороны — с архитектурной.

Думаю, многие читали «сборники» типа «VDI smack down», где фактически сравнивались матрицы фич протоколов (типа есть\нет H.264\multimedia redirection\Zoom optimization…). Это несомненно было полезно при выборе того или иного решения, но не давало представления о реальной жизни, скажем, присутствующей в матрицах фич разных протоколов функции оптимизации одной и той же ВКС.

С другой стороны, холиварные статьи типа «Blast vs PCoIP» раскрывали внутреннюю кухню протоколов, но в основном были ориентированы на негативные стороны конкурента, что в общем‑то путало и пугало всех подряд и не позволяло видеть объективную картину.

Чем меня привлекли именно эти статьи, так это ясной прослеживаемостью принятых архитектурных решений на качество user experience и потолок возможностей, обусловленный архитектурой. И для каждого, кто тесно связан с темой VDI, эти статьи прозрачно намекают на абсолютную необходимость внедрения технологий сегодняшнего дня, а не только воспроизведением идей последних 15–20 лет. Ну, и раскрытием «коварных намерений гиперскейлеров» в разработке ПО😊

Собственно, в Getmobit мы со всем этим сталкиваемся каждый день и по полной, так как работаем в реальных условиях на стороне конечного пользователя. Поэтому, вспоминая про гору, которая не хочет куда‑то идти, закрываем пробелы российского техстека именно в русле положительных моментов статей: и в части оптимизации ВКС для VDI, и нашего видения App Protection, и экосистемы конечных устройств с прозрачной оценкой DEX. Было приятно это осознать, и по ходу статьи я поделюсь дополнительными комментариями с учётом наших наработок.

Надеюсь, эта статья будет полезной не только собственно пользователям VDI, но и коллегам, пишущим действительно свои (Слава Богу, такие уже есть!) протоколы (а не очередной форк freeRDP или VNC) и «пилящим» RuNetScaler’ы 😊

Так как итоговый объём с картинками, таблицами и графиками получился внушительный, решил разбить материал на несколько частей (Часть 2 — результаты и выводы сравнения).

На несколько частей по on‑prem реализациям протоколов. А будет еще и о DaaS протоколах: там сегодня сильно другая картина. И тоже несколько частей

Часть 1

Краткий обзор

Это — не сравнительная таблица фич от вендоров. Это — своего рода инженерно‑криминалистический анализ стеков протоколов удаленного доступа VDI, как они есть в продуктивных ON_PREM (не DaaS!) развертываниях во втором квартале 2026 года. Методология проста: игнорировать маркетинг, игнорировать обещания из дорожных карт, анализировать сетевой кадр, алгоритм механизма контроля перегрузки (congestion control — CC), конвейер кодеков и реальное поведение в неблагоприятных сетевых условиях.

Вывод однозначен: Citrix HDX/EDT лидирует с таким отрывом, который нельзя назвать просто незначительным. Разрыв, особенно после внедрения технологии HDX Graphics Superresolution Upscaling в CVAD 2603, носит скорее архитектурный, чем косметический характер. Omnissa Horizon занимает второе место с надежным, но все более стагнирующим протоколом. Microsoft RDP остается тем, чем всегда был: протоколом локальной сети с косметическими исправлениями для глобальной сети. Parallels RAS — это RDP в сжимающей обертке и новым логотипом.

Область применения: весь анализ применяется исключительно к on‑prem развертываниям. DaaS, облачные брокеры, Azure Virtual Desktop и шлюзы SaaS исключены из анализа.

Почему это сравнение важно в 2026 году

Рынок EUC (End User Computing) переживает период нестабильности. Приобретение компанией Broadcom и последующее выделение подразделения EUC компании VMware в отдельную компанию Omnissa (первый квартал 2024 года) вызвало серьезные опасения по поводу инвестиций в разработку и непрерывности планов развития. Стратегический поворот Microsoft в сторону Azure Virtual Desktop фактически привел к сокращению финансирования инноваций в протоколах RDS для on‑prem сред. Parallels RAS продолжает ориентироваться на малый и средний бизнес с продуктом, архитектурно неспособным конкурировать в корпоративных средах. Citrix тем временем выпускает значимые функции на уровне протоколов: CVAD 2407 представил поддержку SlimCore для нового клиента Microsoft Teams, CVAD 2603 выпустил HDX Graphics Superresolution Upscaling — первый в отрасли механизм масштабирования на стороне клиента с использованием ИИ, интегрированный на уровне протокола удаленного доступа. Это — не просто функции, которые можно отметить галочками, это — архитектурные усовершенствования со значимым влиянием на пропускную способность и качество.

Протокол, идеально работающий в локальной сети 10 Гбит/с — это не протокол VDI. Это — всего лишь игрушка для удалённого рабочего стола. Настоящая проверка — это время отклика 150 мс при потере пакетов в 5%. Именно здесь архитектура протокола раскрывает свою истинную природу..

1. Архитектура транспортного уровня

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

1.1 Citrix EDT — Золотой стандарт

Инспекция DTLS и SSL: стандартные средства инспекции SSL осуществлять ее не могут. Некоторые предприятия считают это ограничением Citrix. На самом деле всё наоборот. В собственной документации Citrix прямо указано, что трафик HDX должен быть исключен из расшифровки и инспекции пакетов, и Citrix выпустила Secure HDX, функцию шифрования прикладного уровня, предназначенную для предотвращения инспекции любым сетевым элементом на пути следования HDX трафика.

EDT (Enlightened Data Transport) Работает поверх DTLS 1.2/1.3 по UDP. Это — не UDP‑оболочка вокруг семантики TCP. Это полная переработка механизма надежной доставки с собственными порядковыми номерами, подтверждениями и, что особенно важно, собственным алгоритмом контроля перегрузки (congestion control). Модель механизма контроля перегрузки (CC) основана на задержке, а не на потерях. Это — наиболее важное архитектурное различие во всем этом обзоре:

Контроль перегрузки (CC) на основе потерь (TCP, BEAT): обнаружение перегрузки ПОСЛЕ потери пакетов → уменьшение временного окна → ожидание подтверждения → медленное восстановление. При 5% потерь (PLR) эффективная пропускная способность падает до ~30% от теоретической.
Контроль перегрузки (CC) на основе задержки (EDT): Обнаружение перегрузки с помощью анализа изменений RTT еще ДО того, как пакеты будут потеряны → проактивное ограничение скорости → уменьшение размера окна → ожидание подтверждения → медленное восстановление. При 5% PLR EDT сохраняет ~75–85% эффективной пропускной способности в интерактивных сессиях.

EDT также реализует выборочное NACK (отрицательное подтверждение): получатель определяет конкретные отсутствующие порядковые номера, и отправитель повторно передает только эти кадры. Полного сброса окна не происходит. Это — тот же механизм, который делает QUIC (Quick UDP Internet Connections — прим.переводчика) более эффективным для передачи мультимедиа, чем TCP.

Adaptive transport — бесшовное переключение TCP/UDP

Adaptive transport поддерживает два одновременных пути с самого начала сессии: UDP‑канал зондирования (EDT) и резервный TCP‑канал (ICA поверх CGP). Решение о переключении принимается на основе метрики произведения RTT×PLR, собираемой каждые две секунды. Переключение на резервный канал прозрачно на уровне сессии: CGP (Common Gateway Protocol) поддерживает состояние сессии независимо от транспортного уровня.

В нормальных условиях переключение TCP→EDT или EDT→TCP завершается менее чем за одну секунду.

Режим устойчивости к потерям EDT — адаптация передачи данных по каждому каналу.

Технология EDT развивалась благодаря добавлению режима устойчивости к потерям (EDT Lossy), доступного начиная с CVAD 2308 для аудио и распространенного на графические каналы в последующих версиях. Механизм архитектурно точно определен: когда задержка и потеря пакетов в рамках сессии превышают настраиваемые пороговые значения, заданные виртуальные каналы выборочно переключаются с надежного режима EDT (DTLS с повторной передачей) на режим EDT Lossy (ненадежная доставка DTLS), в то время как каналы управления и клавиатуры/мыши остаются в режиме надежной передачи. Это исключает задержки повторной передачи на каналах аудио и видео в реальном времени без ущерба для целостности управления сессией, это — более тонкая адаптация, чем простое переключение всей сессии между режимами передачи. Режим устойчивости к потерям для аудио включен по умолчанию начиная с CVAD 2308. Начиная с CVAD 2603, собственный QUIC или HTTP/3 не являются частью on‑prem стека EDT.

1.2 Omnissa Horizon BEAT — Solid, But Frozen in Time

Уточнение по портам и транспорту: для прямых соединений UDP 22 443 используется в качестве транспортного протокола BEAT по умолчанию. Для внешнего доступа через Unified Access Gateway (UAG) Horizon давно поддерживает TCP+TLS на порту 443, что удобно для межсетевых экранов и позволяет проходить через большинство корпоративных периметров. Однако использование TLS на порту 443 заставляет Blast вернуться к транспортному протоколу TCP, что возвращает механизм контроля перегрузки к поведению, основанному на потерях. Ограничение производительности на этом пути является архитектурным для самого BEAT, а не зависит от выбора порта.

BEAT (Blast Extreme Adaptive Transport) использует UDP‑порт 22 443 с резервным TCP‑портом 8443 — структурно корректный подход. BEAT обладает б’ольшими возможностями, чем это часто принято считать. Его контроль перегрузки основан на алгоритме оценки пропускной способности, подобном BBR (Bottleneck Bandwidth and Round‑trip propagation time — прим. переводчика), который анализирует как пропускную способность узкого места, так и RTT, поэтому он реагирует на задержку и джиттер, а не только на потерю пакетов. EDT по‑прежнему обычно считается более агрессивной моделью, основанной на задержке, при больших потерях, но характеризовать BEAT как просто CC, “основанный на потерях”, технически некорректно. Разработка явно возобновилась после выделения Omnissa в самостоятельную компанию. Horizon 2412 добавил автоматическую политику защиты от кейлоггеров и перенаправление контента браузера Linux, а Horizon 2512 представил Blast “VVC Raw Channels” — подлинное изменение на уровне протокола, которое переносит большой объем входного, экранного и аудиосигнала на выделенные сокетные соединения. BEAT — это не заброшенный транспорт, как предполагалось в 2023 году; Он уступает Citrix EDT по уровню агрессивности, а не по тому, ведется ли над ним активная работа.

1.3 Microsoft RDP — протокол локальной сети, работающий в режиме глобальной сети.

Уточнение области применения: Данная оценка охватывает Microsoft Remote Desktop Services (RDS) на Windows Server, единственное решение Microsoft, полностью работающее on‑prem без зависимости от облака Azure. AVD на Azure Local (GA) и AVD Hybrid на серверах с поддержкой Arc (публичная предварительная версия) исключены, поскольку требуют активного подключения к облаку Azure для слоя управления. Это — гибридные архитектуры, не полностью on‑prem, и они войдут в статью по анализу облачных решений/ DaaS. Для организаций со строгими требованиями к изоляции RDS на Windows Server представляется единственным вариантом Microsoft.

Протокол RDP‑UDP был представлен в RDP 8.0 с двумя режимами: надежным (семантика TCP поверх UDP) и режимом с потерями (для аудио/видео). Архитектурная реализация этого протокола не подходит для корпоративных WAN:

Отсутствует механизм контроля перегрузки на основе задержки — ограничение скорости осуществляется на основе анализа подтверждений (ACK), а не на обнаружении изменений в канале.
Отсутствие выборочного подтверждения NACK — запросы на повторную передачу обрабатываются с высокой степенью детализации, что приводит к ненужному расходованию полосы пропускания.
Отсутствует механизм переключения TCP/UDP налету. Сессии начинаются на одном транспортном протоколе и остаются на нем при уровне потерь более 3%, ухудшение качества сессий происходит нелинейно — каскадные повторные передачи создают спираль нарастающей задержки.
Отсутствие QUIC в локальной версии RDS — это осознанное решение Microsoft. Инвестиции в QUIC сосредоточены в Azure Virtual Desktop. Разработка новых протоколов для локальной версии RDS, по сути, прекращена. Это не мнение — это видно из Release Notes Windows Server 2022 и 2025.

1.4 Parallels RAS — RDP под маской

Почему Parallels включен в этот список: вроде речь о крупных корпоративных средах, а оценка‑то «для ниши SMB», но это отражает реальность. Он включен в это сравнение, потому что является одним из немногих действительно on‑prem вариантов VDI наряду с Citrix CVAD, Omnissa Horizon и Microsoft RDS. Исключение его из списка оставило бы пробел в on‑prem сегменте. Анализ рассматривает его таким, какой он есть, а не таким, каким он не является.

Parallels RAS не имеет собственного протокола удаленного доступа. Он использует проприетарный стек сжатия и туннелирования (XTCP) поверх RDP. Архитектура решения следующая:

Дифференциальный битовый кэш Parallels и слой сжатия XTCP

Стек протоколов RDP (TCP‑основной с дополнительным режимом UDP в RAS 19+)

Туннель SSL шлюза Parallels Secure Gateway (порт 443)

Честный вывод из оценки: Parallels не может получить оценку ниже RDP ни в одной категории, где он просто наследует поведение RDP, потому что он является расширением RDP. Вот, где Parallels действительно добавляет ценность, это — управление QoS пакетами XTCP (значительно лучше, чем FIFO очередь каналов в RDP), дифференциальный кэш (превосходит собственный битовый кэш RDP), скорость активной разработки on‑prem решения (в отличие от Microsoft, которая прекратила инвестировать в on‑prem RDS) и некоторые улучшения перенаправления USB в свежих версиях. Где RDP выигрывает: повсеместное распространение тонких клиентов (RDP является нативным для каждой ОС Windows и большинства аппаратных тонких клиентов; Parallels требует установки специального клиента). Итог: Parallels получает 57/170 баллов против 51/170 у RDP.

Разница в шесть пунктов вполне заслужена. Но оба продукта имеют одинаковый потолок кодеков: нет H.265, нет AV1, нет масштабирования с помощью ИИ, нет механизма контроля перегрузки на основе задержки … потому что Parallels не может выскочить за возможности конвейера кодеков RDP.

Матрица производительности в зависимости от состояния сети

Таблица 1: Качественная оценка жизнеспособности сеансов в различных условиях глобальной сети

ценарий	Citrix HDX	Omnissa Blast	RDP	Parallels
LAN, < 1ms RTT, 0% PLR	Отлично	Отлично	Отлично	Отлично
WAN, 50ms RTT, 0% PLR	Отлично	Хорошо	Средне	Хорошо
WAN, 150ms RTT, 0% PLR	Очень Хорошо	Средне	Плохо	Средне
WAN, 80ms RTT, 3% PLR	Хорошо	Средне	Плохо	Средне
WAN, 100ms RTT, 5% PLR	Средне	Плохо	Непригодно	Плохо
WAN, 150ms RTT, >8% PLR	Деградация	Непригодно	Непригодно	Непригодно

Скрытый текст

Примечание переводчика: указанные данные полностью подтверждаются в достаточно простом лабораторном эксперименте — между устройством пользователя (тонким клиентом или ПК с VDI клиентом) и VDI фермой ставится netEm или аналог и далее эмулируются проблемы на каналах связи. По результатам эксперимента, можно сделать дополнительные выводы и наблюдения, которыми мы с удовольствием делимся

2. Графика, кодеки и масштабирование с помощью ИИ

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

2.1 Citrix Thinwire — многокодековый стандарт с масштабированием под управлением ИИ, многокодековый рендеринг каждого кадра

Thinwire (и Thinwire Plus/Progressive) реализует классификацию содержимого экрана в реальном времени на уровне VDA. Каждый кадр анализируется классификатором, который перед кодированием разделяет дисплей на следующие типы областей:

Текстовые/элементы пользовательского интерфейса: классифицируются как статические/с низкой интенсивностью движения → Lossless или YUV 4:4:4, сохраняющие субпиксельное отображение ClearType.
Векторная графика / статический пользовательский интерфейс: кодек MDRLE (собственный кодек Citrix с высоким коэффициентом сжатия и без потерь, представленный в VDA 7.17), цветовая гамма 4:4:4.
Области видеоряда: H.264 или H.265, цветовая субдискретизация 4:2:0 — максимальная эффективность сжатия.
Статические фоны: JPEG или без обновления (только кодирование изменений)

Такая архитектура с использованием нескольких кодеков для одного кадра не встречается больше нигде в этом сравнении. Omnissa, Microsoft и Parallels выбирают один кодек для всего кадра. Citrix менее чем за секунду принимает такое решение для каждого региона каждого кадра.

Отрисовка без потерь

Прогрессивная отрисовка сначала отправляет загрубленное изображение с потерями (мгновенная визуальная обратная связь, низкая нагрузка на канал), за которым следуют последовательные более детальные слои, которые приводят к качеству без потерь. Пользователи мгновенно ощущают отзывчивость; качество улучшается в фоновом режиме. Это архитектурно аналогично прогрессивной развертке JPEG2000, реализованной для каждого типа области экрана.

Технология масштабирования изображения HDX Graphics Superresolution Upscaling — CVAD 2603 (продуктивная версия)

Это — наиболее значительное усовершенствование на уровне протокола в сфере on‑prem VDI за последние два года. Технология HDX Graphics Superresolution Upscaling, внедренная в продуктив в CVAD 2603, представляет собой встроенный компонент конвейера протокола удаленного доступа, использующий искусственный интеллект для масштабирования изображения на стороне клиента.

Механизм:

На стороне сервера \ VDA: Thinwire в рамках сессии идентифицирует видео и области с высокой интенсивностью движения (тот же конвейер классификации, который используется для выборочного кодирования H.264/AV1). Для этих конкретных областей VDA применяет дополнительное сжатие и кодирует их с уменьшенным эффективным разрешением.
На стороне клиента: приложение Workspace App 2507+ использует поддерживаемый графический процессор конечной точки (конкретная платформа машинного обучения не описана; Citrix ссылается на «совместимый графический процессор конечной точки») для масштабирования областей видео с пониженным разрешением до исходного разрешения сессии.
Активация: В CVAD 2603 функция HDX Graphics Superresolution Upscaling по умолчанию работает в автоматическом режиме: Thinwire отслеживает доступную пропускную способность в режиме реального времени и активирует HDX Graphics Superresolution Upscaling только тогда, когда пропускная способность падает ниже порогового значения. При улучшении сетевых условий функция отключается и возвращается к передаче изображения в полном разрешении.
Область применения: HDX Graphics Superresolution Upscaling применяется исключительно к видео/областям с высокой интенсивностью движения — не к статическому тексту, не к элементам пользовательского интерфейса и не к векторной графике. Обработка этих областей по‑прежнему осуществляется существующим конвейером кодирования без потерь/селективного кодирования Thinwire. Это архитектурно корректно: масштабирование статического текста ухудшает читаемость.
Влияние на пропускную способность: снижение битрейта на 30–50% для видеофрагментов при сопоставимом воспринимаемом качестве. Общее снижение пропускной способности сессии зависит от доли видеоконтента в рабочей нагрузке сессии.

Практическое значение для сред с ограниченной пропускной способностью огромно: сеанс, для которого ранее требовалось 8 Мбит/с для передачи 4K‑видео, теперь может поддерживаться на сопоставимом уровне качества при скорости 4–5 Мбит/с. В сетях WAN, где ограничивающим фактором является пропускная способность, а не задержка, это качественное изменение, а не постепенное улучшение.

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

Статус H.265/HEVC и AV1

Аппаратное кодирование H.265/HEVC поддерживается в Citrix HDX начиная с VDA 7.16 (примерно с 2018 года). Это — не новое дополнение, это — зрелая, готовая к использованию функция, требующая кодирования NVENC или AMD VCE на стороне графического процессора и аппаратного декодирования HEVC на клиентском устройстве. Когда обе стороны поддерживают это, то при согласовании кодеков сеанса автоматически выбирается H.265 вместо H.264.

Поддержка AV1 была представлена в качестве предварительной версии в CVAD 2305 для графических процессоров NVIDIA Ada Lovelace и расширена для графических процессоров Intel Arc в CVAD 2308. Автоматический выбор кодека — когда сессия согласовывает наилучший доступный кодек из AV1 > H.265 > H.264 — включен по умолчанию начиная с Workspace App 2311. Таким образом AV1 доступен в продуктивной среде уже два года на оборудовании, которое его поддерживает (NVIDIA Ada Lovelace / RTX 4000+, Intel Arc / Flex Series). Workspace App 2311+ поддерживает декодирование AV1 в Windows. Для AV1 требуется кодирование на стороне графического процессора; фолбэк на кодирование на ЦП не предусмотрен.

YUV 4:4:4 и Chroma Fidelity

Доступна нативная цветовая гамма 4:4:4 благодаря политике HDX (“Разрешить визуальное сжатие без потерь” + «Использовать видеокодек: для всего экрана»). Сохраняется субпиксельная отрисовка текста ClearType без артефактов цветовой гаммы, это критически важно для САПР, настольных издательских систем и финансовых торговых приложений с плотным отображением числовых данных.

2.2 Omnissa Blast — Эффективные кодеки, отсутствие интеллекта

Blast Extreme поддерживает H.264, H.265/HEVC, AV1 и фирменный кодек Blast .

Поддержка AV1 подтверждена в текущей документации Omnissa Horizon для всех последних релизов.

Функция разгрузки ЦП с помощью NVIDIA vGPU хорошо интегрирована, это — преимущество, обусловленное многолетним опытом Horizon в экосистеме VMware/vSphere.

Чего не хватает Blast:

Нет много‑кодекового рендеринга одного кадра. Выбор кодека осуществляется для каждой сессии и каждого кадра, а не для каждого региона. Когда кадр содержит как статический текст, так и видео окно, Blast применяет один кодек ко всему кадру. Это — скорее ограничение архитектуры, а не ограничение возможностей настройки.
Нет возможности Superrsolution Upscaling с использованием ИИ.
Нет прогрессивной модели Build‑to‑Lossless. Доступен YUV 4:4:4, но с менее детальным управлением, чем в рамках политик Citrix.

2.3 Microsoft RDP — AVC444 как аппроксимация режима без потерь

Подход Microsoft к передаче YUV 4:4:4 основан на режиме AVC444: одновременно передаются два потока H.264 — стандартный поток 4:2:0 и дельта‑поток 4:4:4. Принимающий клиент объединяет их для улучшения цветопередачи. Это технически грамотно, но архитектурно затратно: требуется двойное декодирование на стороне клиента, и даже это не обеспечивает качества, соответствующего исходному формату 4:4:4.

Отсутствуют:

Поддержка H.265
Поддержка AV1
Масштабирование ИИ
Анализ содержимого экрана, выходящий за рамки «движение vs статическое изображения»

Технология RemoteFX, обеспечивавшая ускорение кодирования с помощью графического процессора, была удалена из RDSH в Windows Server 2019+ из‑за уязвимостей безопасности (CVE-2020-0655 и др.), и замены нет. В Windows Server 2022 и 2025 ускорение кодирования с помощью графического процессора для сессий RDSH недоступно через собственные компоненты RDS.

Уточнение о DDA

Windows Server 2022 и 2025 поддерживают DDA (Discrete Device Assignment) — механизм Hyper‑V, который отдает физический (помнится, что и vGPU тоже — прим. переводчика) графический процессор исключительно одной виртуальной машине. Его часто называют современной заменой RemoteFX. Однако это представление вводит в заблуждение с архитектурной точки зрения. DDA — это соотношение 1:1: один физический графический процессор назначается одной виртуальной машине. Это принципиально несовместимо с многосессионной моделью RDSH, где десятки пользовательских сессий используют один экземпляр хостовой ОС. DDA подходит для однопользовательских VDI‑рабочих столов (одна виртуальная машина, один пользователь), но требует внешнего брокера для управления распределением графических процессоров для каждой виртуальной машины и ничего не добавляет к возможностям кодирования сессий RDSH. Собственный стек кодеков RDS в RDSH не может использовать выделенные DDA ресурсы графического процессора для совместного кодирования H.264/H.265 в рамках параллельных сессий. Вывод очевиден: ускоренное графическим процессором многопользовательское кодирование в RDSH по‑прежнему недоступно через собственные компоненты RDS на Windows Server 2022 и 2025.

2.4 Parallels RAS — Сжатие без кодека

Parallels дополняет возможности кодека RDP дифференциальным кэшем растровых изображений на стороне клиента и сжатием обновлений дисплея на основе ZLIB. Это снижает сетевую нагрузку за счет предотвращения повторной передачи неизмененных областей экрана и функционально аналогично собственному кэшу растровых изображений RDP, но с лучшими коэффициентами сжатия. Это — не кодек. Он не обеспечивает возможности масштабирования H.265, AV1, 4:4:4 или ИИ. Максимальный уровень — это предел возможностей кодека RDP.

Примечание переводчика: почему важно учитывать то, какой кодек используется для передачи видеопотока? Потому что это напрямую влияет на минимальные аппаратные требования, предъявляемые к устройству, с которого работает пользователь. Так, если нам необходимо получить 4К с кодеком H.265 или AV1, то без аппаратного декодирования уже не обойтись, а такую возможность, например, предоставляют процессоры Intel поколения Kaby Lake (2016), а ещё лучше — Ice Lake (2019), чтобы получить 4:4:4.

3. Оптимизация унифицированных коммуникаций

Примечание переводчика: работа (точнее, её отсутствие) российских ВКС в VDI давно уже стала чем‑то, что многие администраторы воспринимают как должное («ну да, оно не работает», прозвучало недавно почти единогласно со сцены на конференции IT Elements). Но, давайте будем честны, это «должное» не только бесит конечных пользователей, но и ломает весь сайзинг, который только вчера давал приемлемые результаты, а через сломанный сайзинг ломает и экономику всей инфраструктуры рабочих мест.

Скрытый текст

Примечание переводчика:Мы провели моделирование отсутствия влияния оптимизации ВКС в VDI и получили интересные результаты:

3.1 Citrix HDX — Teams SlimCore и архитектура разгрузки ВМ

Основная принцип архитектуры оптимизации HDX ВКС заключается в перенаправлении медиаконтента на конечную точку.

Стек обработки мультимедиа вызова (кодирование/декодирование аудио, кодирование /декодирование видео, обработка WebRTC) никогда не затрагивает VDA в сети:

На стороне VDA: клиент Teams, работающий в среде VDA, обнаруживает среду HDX VDI и активирует DLL‑библиотеку‑перехватчик HDX, которая перехватывает медиа стэк WebRTC и перенаправляет её в виртуальный канал CTXMTOP.
Транспорт ICA: по каналу ICA к VDA передаются только метаданные сигнализации, присутствия, чата и демонстрации экрана. Передача медиафайлов осуществляется локально от начала до конца.
На стороне конечной точки: Citrix Workspace App предоставляет локальный медиа‑движок, который принимает перенаправленные медиа потоки и обрабатывает их локально, напрямую подключаясь к другим участникам и серверной инфраструктуре Teams.

Переход на SlimCore стал определяющей задачей в сфере унифицированных коммуникаций в 2025–2026 годах. Microsoft заменила архитектуру клиента Teams на основе Electron на SlimCore — новый медиа движок, который значительно меняет интерфейс плагинов. Citrix включила поддержку SlimCore в рабочую среду в CVAD 2407 и доработала её в CVAD 2503 и 2511.

Важная деталь реализации: библиотеки SlimCore должны быть развернуты на конечном устройстве (а не на VDA). Workspace App 2407+ предоставляет их в составе установочного пакета. Поддержка отправки видео в режиме SlimCore в Linux Workspace App была неполной в CVAD 2503 и исправлена в последующих выпусках. Поддержка тонких клиентов ARM зависит от статуса сертификации OEM‑производителя, который различается в зависимости от устройства.

3.2 Omnissa Horizon — Запоздалый паритет по функциональным возможностям

Архитектура оптимизации мультимедиа Teams в Horizon концептуально идентична Citrix: подключение Horizon Agent, виртуальный канал, локальный медиа движок на клиенте. Техническая реализация надежна. С т з конкуренции вопрос заключается во времени: полная поддержка SlimCore для New Teams появилась в Horizon примерно через два квартала после выпуска оптимизатора Citrix в продуктив. Сертификационная база для тонких клиентов оптимизированного клиента ВКС Horizon уже, чем у Citrix, и после выделения компании из VMware меньше OEM‑партнеров активно поддерживают сертификацию под брендом Omnissa. Это — не архитектурные недостатки, а пробелы в организационной реализации, имеющие значимое влияние на развертывания в on‑prem среде.

3.3 Microsoft RDS — Вендор оптимизирует свой продукт хуже, чем конкуренты.

Это — не преувеличение: Microsoft Teams, работающий на Microsoft RDSH с собственной оптимизацией ВКС от Microsoft, показывает худшие результаты на одном и том же «железе» по сравнению с Teams, работающими на Citrix CVAD или Omnissa Horizon. Основная причина заключается в том, что инвестиции Microsoft в on‑prem RDS подчинены плану развития Azure Virtual Desktop. Классические Teams на RDSH работали на стороне сервера с полным стеком Electron — каждый видеозвонок потреблял ресурсы ЦП/ГП RDSH для обработки мультимедиа. Служба переадресации WebRTC обеспечивает частичную разгрузку для новых версий Teams, но поддержка тонких клиентов OEM‑производителей, охват сертификации и полнота функционала остаются позади как Citrix’а, так и Horizon’а.

3.4 Parallels RAS — делегирование оптимизации ВКС

Parallels RAS использует службу переадресации WebRTC от Microsoft для оптимизации Teams, т е тот же механизм, что и в базовом RDS. Здесь нет собственного медиа движка, нет инвестиций в SlimCore, выходящих за рамки того, что предоставляет служба переадресации от Microsoft, и нет интеграции плагинов Zoom VDI на уровне протокола. Когда служба переадресации работает, Teams «оптимизирован». Когда она не работает, медиаконтент передается через сессию RDP, потребляя ресурсы сервера.

4. Виртуальные каналы и управление полосой пропускания

4.1 Citrix — Приоритизация как ДНК протокола

ICA реализует четыре класса приоритета трафика с жестко заданным управлением очередями:

Класс 0 — данные реального времени: управление клавиатурой, мышью, звуком. Никогда не уступает свое место.
Класс 1 — Высокая интерактивность: Обновление экрана, операции с интенсивным использованием пользовательского интерфейса.
Класс 2 — Обычные объемные данные: печать, передача данных из буфера обмена, перенаправление файлов.
Класс 3 — Фон: перенаправление USB, потоковая передача аудио, асинхронные операции.

Функционал приоритизации реализован с помощью отправки отдельных окон для каждого класса в рамках кадрирования EDT/ICA, а не только как тегирование DSCP. Когда канал перегружен большим объемом печати (класс 2), трафик клавиатуры и мыши (класс 0) не ставится в очередь за ним. Сеанс остается интерактивным во время пакетной передачи данных. Это — не параметр конфигурации, но структурное поведение протокола. Дополнительные функции управления полосой пропускания: виртуальные каналы HDX QoS (формирование трафика для каждого сеанса, обеспечиваемое NetScaler) и LZW сжатие ICA для «объемных» каналов, применяемое выборочно для каждого класса виртуального канала.

4.2 Omnissa Blast — Приоритизация на основе DSCP

Blast использует маркировку пакетов DSCP для классов трафика: ускоренная пересылка (EF, DSCP 46) для управления/аудио, AF41 (DSCP 34) для видео, Best Effort для пакетных \” объемных” данных. Это корректно и совместимо с корпоративной инфраструктурой QoS, но основано на принудительном применении на сетевом уровне. В самом протоколе нет аналога управления окном отправки для каждого класса, как в ICA. Приоритизация перекладывается вовне — на сетевую инфраструктуру, а не делается внутри протокола.

4.3 Microsoft RDP — очередь FIFO без приоритизации

Это — одно из наиболее существенных архитектурных ограничений RDP. Виртуальные каналы в RDP представляют собой статический список, обрабатываемый в одном TCP‑потоке с семантикой FIFO. Приоритетность трафика между каналами отсутствует. Вставка в одном TCP‑потоке 100 МБ данных из буфера обмена блокирует ввод с клавиатуры. Эта «ошибка» документирована ещё со времён Windows 2000. В Windows Server 2025 она до сих пор не исправлена.

После обнаружения уязвимостей CVE перенаправление USB (RemoteFX USB): удалено по умолчанию в Windows Server 2019. Для повторного включения требуется переопределение в групповой политике, поддержка со стороны производителя отсутствует. Отсутствует в Windows Server 2025 RDSH.

4.4 Parallels — XTCP: Реальная ценность и унаследованный потолок

Parallels XTCP выходит за рамки простой конвейерной обработки TCP: он разделяет пакетный трафик (передача файлов, задания печати) на отдельные потоки с более низким приоритетом, что частично повторяет различие между классами 2 и 3 в ICA. Это — действительно улучшение по сравнению с плоской очередью FIFO в RDP и оправдывает большее количество приоритетов виртуальных каналов (5 против 2 в RDP). Дифференциальный битовый кэш также значительно превосходит собственный кэш RDP по коэффициенту сжатия и устойчивости сессии.

Ограничения RDP остаются прежними. Никакая оптимизация XTCP не внедряет H.265, AV1, контроль перегрузки на основе задержки или масштабирование с помощью ИИ, для этого требуются изменения на уровне протокола, которые не могут добавить никакие наложения поверх самого RDP. Коррекция оценки (57/170 против 51/170 у RDP) отражает реальность: Parallels лучше, чем то, на чём он построен. Это — правильный результат. Это также — точное описание его архитектурных ограничений.

4.5 Передача звука: адаптивный и структурный сбой синхронизации губ

В современных системах VDI качество звука не является второстепенным фактором. Гибридные модели работы (офис, удаленка, мобильный — прим.переводчика) сотрудников означают, что качество звука является основным показателем пользовательского опыта, а архитектура аудио на уровне протоколов выявляет тот же фундаментальный пробел, что и транспортный уровень.

Citrix — Аудио через EDT

Citrix направляет аудиопоток через тот же виртуальный канал EDT, что и поток изображения, используя кодек Opus с адаптивным управлением битрейтом (настраиваемый 16–128 кбит/с). Ключевое архитектурное свойство: поскольку аудиопоток использует механизм контроля перегрузки на основе задержки EDT, то протокол применяет одинаковые корректировки на основе состояния сети как к аудио, так и к визуальным данным. При увеличении RTT EDT автоматически уменьшает битрейт Opus и корректирует параметры сэмплирования еще до потери пакетов. Временные шкалы аудио и видео синхронизируются на уровне кадрирования EDT, обеспечивая согласованность звука и изображения даже в неблагоприятных условиях WAN. Подавление эха и шума выполняется на стороне клиента (движок AEC в Citrix Workspace App), что позволяет избежать затрат ресурсов ЦП VDA.

Microsoft RDP — структурный прокол в синхронизации аудио‑видео

RDP‑UDP реализует специальный режим с потерями для аудио, корректно распознавая, что аудио лучше переносит случайные потери пакетов, чем задержку повторной передачи TCP. Однако аудио‑ и видеопотоки воспроизводятся по независимым UDP‑каналам без общего механизма синхронизации. На WAN‑соединениях с переменным джиттером между двумя потоками воспроизведение аудио и видео расходится. Результатом является хорошо известная рассинхронизация губ и звука в RDP на каналах с временем отклика более 80 мс при любом изменении порядка пакетов. В 2026 году в профессиональной и финансовой организациях, где удаленные презентации, звонки на торговых площадках и записи для контроля качества обслуживания являются обычным делом, это является дисквалифицирующей характеристикой, а не незначительным неудобством.

Omnissa Blast — игра на основе Opus, и хорошо интегрированная.

Blast использует Opus для передачи звука с приемлемым качеством по протоколу UDP. Синхронизация звука с видеопотоком осуществляется адекватно в стандартных условиях WAN. В типичных условиях корпоративной сети реализация надежна и не демонстрирует проблем с синхронизацией губ, характерных для RDP.

Parallels RAS — Наследуемое ограничение

Parallels наследует аудио архитектуру RDP, включая проблему синхронизации губ при независимых друг от друга потоках аудио и видео. Слой сжатия XTCP не вводит механизмы синхронизации аудио и видео. При использовании каналов с высокой задержкой пользователи Parallels сталкиваются с той же рассинхронизацией звука‑видео, что и в обычных сеансах RDP.

4.6 Тонкие клиенты и экосистема ОС: Налог за разнообразие платформ

В 2026 году стратегия использования корпоративных конечных устройств все больше отдает предпочтение тонким клиентам на базе Linux — IGEL OS, HP ThinPro, Stratodesk. NoTouch и устройства на базе ARM — для снижения стоимости приобретения, уменьшения поверхности атаки и увеличения срока службы оборудования. Жизнеспособность этой стратегии определяется качеством реализации клиентского программного обеспечения протоколов удаленного доступа для Linux.

Citrix Linux Workspace App — почти полный паритет с Windows

Citrix Workspace App для Linux имеет примерно 95% функционала от клиента для Windows. Это включает в себя полную передачу EDT с адаптивным переключением, аппаратное декодирование H.264/H.265 на поддерживаемых графических процессорах, масштабирование графики HDX Graphics Superresolution Upscaling на поддерживаемых графических процессорах, оптимизацию мультимедиа Teams и защиту приложений (в поддерживаемых дистрибутивах). Клиент для Linux — это первоклассная реализация, а не порт, поддерживаемый в качестве второстепенной задачи. IGEL OS, HP ThinPro и Stratodesk поставляют сертифицированные сборки Citrix Workspace App в качестве основных компонентов своих платформ.

Microsoft RDP на Linux — ограничения FreeRDP

Фактическим стандартом RDP‑клиента в Linux является FreeRDP — реализация с открытым исходным кодом, которая соответствует спецификации RDP с задержкой в характеристиках. FreeRDP постоянно отстает от проприетарных расширений протокола Microsoft: поддержка AVC444 появилась значительно позже, чем в Windows, поддержка Teams WebRTC Redirector в Linux FreeRDP частичная, а некоторые расширения конвейера GFX вообще не реализованы. Для корпоративных развертываний, требующих согласованного поведения протокола на конечных точках Windows и Linux, этот разрыв имеет существенное значение. Microsoft не поставляет собственный RDP‑клиент для Linux; FreeRDP — это насколько возможно близкая реализация, поддерживаемая сообществом.

Поддержка Parallels RAS на платформах, отличных от Windows.

Parallels RAS предоставляет HTML5 и нативные клиенты для Linux, но слой оптимизации XTCP, который обеспечивает существенные улучшения по сравнению с обычным RDP, в основном эффективен в нативном клиенте Windows. На тонких клиентах Linux, использующих клиент Parallels HTML5 или ограниченные нативные сборки, дифференциальное кэширование XTCP и разделение QoS в пакетном режиме дают меньший эффект. Практическое следствие: при развертывании Parallels RAS, в котором конечные точки переводятся на тонкие клиенты Linux, качество сеансов будет хуже, приближаясь к поведению обычного RDP, что приведет к потере преимуществ сжатия и приоритизации, которые оправдывали выбор самого VDI.

Omnissa Horizon Linux Client

Omnissa предоставляет нативный клиент Horizon для Linux, который адекватно охватывает основной набор функций Blast Extreme, включая поддержку декодирования H.264/H.265 и оптимизацию мультимедиа для Teams. Функциональный паритет с Windows хуже, чем у Citrix — примерно 80–85% — с пробелами в основном в расширенных функциях виртуальных каналов и охвате ОЕМ сертификации тонких клиентов, которая сократилась после выделения Omnissa, поскольку программы сертификации требуют активных инвестиций от поставщиков.

5. Безопасность конвейера рендеринга

Безопасность протокола удаленного доступа не ограничивается шифрованием на транспортном уровне. В современных корпоративных и регулируемых средах — финансовых услугах, здравоохранении, юриспруденции, государственном управлении — сам конвейер рендеринга представляет собой поверхность атаки. Злоумышленник, имеющий доступ к конечной точке (или внутренняя угроза на разделяемом или BYOD‑устройстве), может получить доступ к содержимому сессии посредством захвата экрана, с помощь key‑logging или анализа памяти графического буфера. Эта модель угроз невидима для безопасности транспортного уровня (шифрование TLS/DTLS защищает данные при передаче; оно не защищает отображаемые пиксели на клиентском устройстве).

5.1 Citrix App Protection — Изоляция рендеринга на уровне протокола

Защита приложений — это реализация компанией Citrix системы безопасности конвейера рендеринга. Она работает на уровне Citrix Workspace App и перехватывает вывод изображения до того, как он достигнет графической подсистемы операционной системы, доступной для сторонних инструментов захвата экрана.

Основные архитектурные особенности:

Защита от захвата экрана: функция App Protection внедряет защищенный контекст рендеринга, который предотвращает захват содержимого сессии API‑интерфейсами создания снимков экрана на уровне ОС ( PrintScreen, BitBlt, захват экрана DirectX). Механизм работает на уровне WDDM (Windows Display Driver Model), перехватывая вызовы захвата до того, как они достигнут буфера кадров.
Защита от кейлоггеров : ввод с клавиатуры в контексте защищенной сессии направляется через изолированный канал, который обходит стандартные API перехвата клавиатуры Win32 ( SetWindowsHookEx ). Это позволяет обойти большинство коммерческих и распространенных кейлоггеров, которые полагаются на внедрение перехватчика в масштабах всей системы.
Защита на уровне отдельных приложений: что особенно важно, защита приложений может применяться на уровне отдельных опубликованных приложений, а не только ко всем сессиям VDA. Организация может защитить торговое приложение или систему управления персоналом в рамках общего VDA, оставив стандартные продуктивные приложения незащищенными, сохраняя удобство использования и обеспечивая максимальную безопасность там, где риск наиболее высок. Эта гранулярность является архитектурным свойством того, как Citrix формирует изолированные контексты рендеринга для каждого опубликованного ресурса.
Водяные знаки сессии : CVAD 2203+ включает настраиваемые водяные знаки сессии (имя пользователя, метка времени, IP‑адрес), которые отображаются непосредственно в потоке данных на уровне VDA — невидимые для пользователя во время обычной работы, но сохраняющиеся на любом сделанном снимке экрана. Это обеспечивает криминалистическую ответственность за утечку данных через захват камеры (угроза, которую защита приложений технически не может заблокировать).

5.2 Omnissa Horizon — Базовая блокировка скриншотов

Horizon обеспечивает блокировку снимков экрана через конвейер отображения Blast: при включении этой функции окно сессии возвращает черные кадры в API захвата экрана. Это управление на уровне сессии, а не на уровне приложения. Аналога Citrix для защиты на уровне отдельных опубликованных приложений не существует.

Функция защиты от перехвата нажатий клавиш не является встроенной функцией Horizon; она зависит от инструментов DLP на конечных устройствах.

В последних версиях Horizon доступна функция добавления водяных знаков к сессиям с базовыми возможностями наложения текста, которая, однако, менее гибко настраивается, чем реализация в Citrix.

5.3 Microsoft RDP / Parallels RAS — Структурный пробел

Ни Microsoft RDS, ни Parallels RAS не предоставляют встроенных функций безопасности конвейера рендеринга в своих локальных реализациях. RDP передает отрендеренный буфер кадров клиенту через стандартный графический стек Windows, где он доступен любому процессу с соответствующими привилегиями на клиентском устройстве. Отсутствует перехват API Win32, изоляция рендеринга и механизм защиты от перехвата нажатий клавиш на уровне протокола.

Вывод: организации, развертывающие для критичных рабочих нагрузок RDP или Parallels RAS на неуправляемых конечных точках (BYOD, устройства подрядчиков, домашние рабочие станции), не имеют защиты на уровне протокола от захвата экрана или перехвата нажатий клавиш на стороне клиента. Это невозможно решить только с помощью политики конечных точек в сценариях BYOD, когда организация не контролирует операционную систему конечной точки.

6. Архитектура для Double Hop и сохранение сессии

В регулируемых отраслях — финансовых услугах, страховании, здравоохранении — при развертывании корпоративных VDI‑систем обычно используются многослойные архитектуры сессий. В финансовых учреждениях типичная схема выглядит следующим образом: клиентская конечная точка → шлюз NetScaler → изолированный виртуальный рабочий стол (VDA) → опубликованное приложение (XenApp/RDSH).

Эта дву‑хоповая топология обеспечивает сегментацию сети, изоляцию привилегий и границы аудита. Поведение стека протоколов в этой топологии выявляет более глубокие архитектурные свойства, чем в одно‑хоповых тестах.

6.1 Citrix CGP — Сохранение сеансов между хопами

CGP (Common Gateway Protocol) — это протокол сеансового уровня, расположенный над транспортным протоколом ICA/EDT. Его основная функция — обеспечение надежности сеанса: CGP поддерживает состояние сеанса независимо от базового TCP/UDP‑соединения, обеспечивая бесперебойное переподключение после прерывания сети без потери сеанса. В дву‑хоповой топологии CGP работает на обоих этапах независимо. Архитектурное преимущество дву‑хоповой топологии:

Мэппинг приоритетов EDT: Когда сеанс ICA от внешнего узла ( Client → NetScaler → VDA ) содержит внутренний узел ( VDA→Application Silo), внутренний поток EDT инкапсулируется во внешний виртуальный канал EDT. Классификация приоритета (класс 0 — клавиатура/мышь, класс 3 — фоновый трафик) сохраняется от начала до конца. Ввод с клавиатуры, исходящий от клиента, сохраняет приоритет класса 0 на обоих транспортных узлах.
Устойчивость к прерываниям соединения: если внешнее сетевое соединение обрывается на срок до 180 секунд (настраивается), CGP поддерживает состояния обеих сессий. Пользователь переподключается, и сессия рабочего стола, и сессия внутреннего приложения возобновляются без проблем. Внутренняя сессия RDSH к опубликованному приложению не знает о прерывании внешнего транспортного соединения.
Тунеллирование через один и тот же порт: Вся топология с двумя хопами может проходить через межсетевой экран по одному порту (443 TCP/UDP), при этом NetScaler выполняет проверку протокола и завершение EDT. Это имеет важное значение для организаций со строгими процессами управления изменениями в межсетевом экране.

6.2 RDP Double‑Hop — Накопление сбоев

Вне зависимости от масштаба проекта, RDP‑в-RDP представляет собой архитектурную катастрофу. Виды отказов носят структурный и некомпенсируемый характер:

Объединение очередей FIFO: Внешняя сессия RDS содержит внутренний клиент RDP. Обе сессии поддерживают независимые потоки TCP с очередями каналов FIFO. Пакетная передача данных во внутренней сессии (вставка в буфер обмена, задание печати) заполняет внутренний поток RDP, который затем становится пакетным потоком данных с точки зрения внешней сессии RDP, заполняя внешнюю очередь FIFO. Интерактивный ввод с клавиатуры и мыши ожидает за двумя слоями недифференцированных пакетных данных.
Нелинейное усиление задержки: в топологии с двумя переходами задержка в идеальных условиях является аддитивной: RTT_outer + RTT inner. При использовании механизма предотвращения перегрузки TCP она становится супераддитивной при любой потере пакетов: предотвращение перегрузки на внешнем сеансе снижает пропускную способность для всех данных, включая внутренний поток RDP, что затем запускает предотвращение перегрузки на внутреннем сеансе. 2% PLR на внешнем канале может привести к тому, что обе сессии одновременно войдут в циклы предотвращения перегрузки.
Отсутствие сохранения сессии : RDP не имеет аналога надежности сессии CGP. Сбой в сети на внешнем канале, длящийся более нескольких секунд, приводит к завершению внешней сессии. Внутренняя сессия приложения в RDSH также завершается (или отключается, в зависимости от политики тайм‑аута сессии RDSH). Пользователю необходимо повторно пройти аутентификацию на обоих уровнях.

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

6.3 Omnissa Horizon Double‑Hop

Horizon поддерживает сценарии с двумя хопами через соединение Horizon‑to‑Horizon (запуск сессии Horizon из рабочего стола Horizon). Транспорт BEAT работает на каждом переходе независимо. Контроль перегрузки на основе потерь пакетов работает аналогично RDP при потере пакетов, хотя транспорт на основе UDP позволяет избежать наиболее серьезных проблем, связанных с очередью FIFO. Сохранение сессии на каждом переходе зависит от политики тайм‑аута сессии Horizon Connection Server, при этом отсутствует эквивалентное Citrix CGP сохранение состояния сессии. На практике сценарий с двумя переходами в Horizon работает значительно лучше, чем сценарий с двумя переходами в RDP, но ему не хватает надежности сквозной передачи сессий и сохранения приоритета виртуальных каналов, как у Citrix.

Сравнение протоколов удаленного доступа VDI Q2 2026 (On‑prem / Не для облака)