Page URL:

http://www.syselegance.com/ru/technologies/research/rdp8_remotefx_for_wan.php

Copyright:

© 2003-2024 SysElegance Ltd. All rights reserved.

RDP 8 (RemoteFX) для WAN.

Обзор интеллектуальной и адаптивной передачи данных в Windows 8 и Windows Server 2012

В протоколе RDP 8 (RemoteFX) введены значительные улучшения в области передачи данных. Ниже перечислены ключевые задачи, стоявшие во время улучшения:

• Обеспечение скорости и гибкости работы пользователя в удаленном сеансе в любых WAN и беспроводных сетей.
• Важность использования стандартных протоколов безопасности, а не реализации пользовательской схемы безопасности передачи данных.
• Обеспечение максимально возможных улучшений для использования большинства пользовательских конфигураций в WAN. RDP 8 (RemoteFX) не является единственным потоком трафика в сети. Также стоит задача обеспечить баланс трафика RDP 8 (RemoteFX) с другими конкурирующими сетевыми потоками (например, просмотром веб-страниц).
• Использование оптимальных значений "по умолчанию", которые не требуют вмешательства пользователя, предоставляя при этом необходимые администраторам элементы управления для настройки.

Ключевыми особенностями RDP 8 (RemoteFX) для WAN являются:

• Автоматическое определение качества сети для адаптации к начальным и меняющимся условиям
• UDP оптимизация для сетей с потерей пакетов и возможность предоставления лучших условий доставки мультимедийного контента
• FEC для уменьшения потерь, без ретрансляции
• Возврат к протоколу TCP, когда UDP недоступен
• Встроенная поддержка UDP для соединения RDP 8 (RemoteFX) через шлюз удаленных рабочих столов
• Промышленный стандарт безопасности и протоколы контроля перегрузок.

Далее, мы более подробно опишем эти улучшения.

Цель - WAN сети

Традиционное определение WAN (глобальные сети) предполагает высокую латентность сети, которая может быть ограничена пропускной способностью (по сравнению с LAN).

Тем не менее, на практике существует широкий спектр сетевых конфигураций, которые могут квалифицироваться как WAN. Примерами таких сетей являются: Американская национальная сеть (например, 60 мс RTT, 5 Мбит мощности, 1% потерь), межконтинентальные связи (например, 250 мс RTT, 3 Mbps мощности, 1% потерь) и филиальные соединения (например, 100 мс время отклика, 256 Kbps мощности, 0,5% потерь). Наряду с этими традиционными WAN сетями, существуют также сложные мобильные и беспроводные сети (например, 3G/4G связь с 200 мс RTT, 1 Мбит мощности, 5% потерь), при использовании которых возникают проблемы с работой удаленных рабочих столов из-за высокой потери пакетов и джиттера задержки сигнала при помехах.

При проектировании методов пересылки пакетов RDP 8 (RemoteFX) для WAN, вместо того чтобы сосредоточиться на оптимизации для конкретного типа сети, мы сосредоточились на решении проблем, вызванных каждым из фундаментальных факторов, влияющих на задержки, потерю пакетов и пропускную способность. Мы также рассмотрели другие важные факторы, такие как изменение задержки (так называемый "джиттер") и модели потери пакетов (одиночной или постоянной, с зависанием и без него).

В следующих разделах мы обсудим влияние этих фундаментальных факторов на производительность WAN и соответствующие улучшения RDP 8 (RemoteFX).

Автоматическое определение скорости подключения к сети

Цель эффективной передачи данных – использование полного ресурса пропускной способности сети, при минимальных задержках. По отдельности эти цели легко достижимы, и при этом их трудно совместить. Передача данных в более высоком объеме, чем позволяет сеть ведет к необходимости в более высокой пропускной способности, что в свою очередь приводит к формированию "очередей" в различных точках сети. Эти очереди увеличивают задержку, что крайне вредно для реагирования любые интерактивных приложений реального времени, таких как Remote Desktop.

Основная же цель – снижение задержек и отправка минимального количества данных. Тем не менее, это приведет к сокращению качества контента из-за ограниченности полосы пропускания для таких потоков, как графика и мультимедиа. Для узкой сети (C) и задержками в обе стороны (RTT), в идеале необходимо всегда держать пересылку ближе к C * (RTT) байт, но не более. Задача состоит в определении задержки и пропускной способности сети, которая используется для соединения RDP 8 (RemoteFX).

Многие из Вас могут быть знакомы с возможностью пользовательского выбора скорости соединения Remote Desktop Connection (показано на следующем рисунке). При выборе этих вариантов мы смогли улучшить пропускную способность RDP 8 (RemoteFX) (и, следовательно, работы) путем изменения оценки наполнения сети, упомянутом ранее.

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

Для RDP 8 (RemoteFX) в релизах Windows Server 2012 и Windows 8 добавлена возможность автоматического определения скорости для решения проблемы плотности наполнения. Эта функция встроена по умолчанию в Remote Desktop Connection и позволяет избавить пользователей от необходимости догадываться о скорости их соединения. Во время установления соединения и выполнения пересылки потока данных, эта функция используется для расчета мощности сети и задержек связи. Эти факторы затем используются для определения количества данных, необходимых для поддержания плотности соединения, минимизируя задержки. Кроме того, способность обнаружения условий сети открывают новые возможности RDP 8 (RemoteFX), которые позволяют адаптироваться к меняющимся сетевым условиям (например, RDP 8 (RemoteFX) Media Streaming на основе информации о сетевых условиях может принять решение, какой битрейт использовать для передачи видео).

На рисунке ниже показано улучшение пропускной способности сети с помощью RDP 8 (RemoteFX) автоматического определения скорости подключения к сети. Мы не показываем здесь конфигурации LAN, так как большинство протоколов ведут себя в локальной сети хорошо. Данные на графике показывают, что в процентном отношении, значительно улучшили пропускную способность TCP по сравнению с Windows Server 2008 R2. Тем не менее, существует теоретический предел пропускной способности TCP при более высоких потерях и задержках. Мы обсудим эти ограничения и возможности, связанные с RDP 8 (RemoteFX) в следующем разделе.

UDP для обработки потерь пакетов

Даже если протокол решает проблему наполнения сети, то потеря пакетов может внести хаос в производительность работы. Ниже приведены две причины, почему же потеря пакетов это плохо.

Блокировка начала строки.

TCP протокол обеспечивает надежность и порядок доставки данных, и при этом потерянные пакеты должны быть повторно переданы отправителем. Ретранслируемые пакеты часто застревают в TCP очередях и не могут быть доставлены. Этот срыв называют "блокировкой начала строки" и это особенно вредно для реагирования на WAN, потому время простоя, по крайней мере, в 1,5 раза больше сетей RTT.

Потеря пропускной способности.

Любой мало-мальски хороший сетевой прокол нуждается в управлении перегрузкой, которая позволяла бы отправителям уменьшать скорость передачи при перегрузке. Отсутствие такого контроля может привести к коллапсу, кода возникнут большие потери пакетов, задержки и маленькая пропускная способность. TCP использует управление перегрузкой на основе потерь [NewReno или другие варианты алгоритма Additive Increase Multiplicative Decrease (AIMD)], когда каждая потеря пакетов предположительно происходит от перегрузки сети. Таким образом, происходит сброс (за счет сокращения скользящего окна наполовину) на каждую потерю пакетов. Этот подход работает исключительно хорошо в глобальной сети Интернет. Однако это может привести к серьезной потере пропускной способности в сетях, где у нас есть потери, не связанные с затором (например, Wi-Fi, 3G/4G и наиболее высокая латентность сети). Убыток от снижения пропускной способности TCP является более выраженным при больших задержках.

На следующем рисунке показан этот эффект. Максимальная теоретическая пропускная способность TCP для 50 Мбит с учетом нескольких различных уровней потерь и задержек (рассчитывается по формуле Mathis). Как показано, комбинируя потери и задержки можно добиться снижения реальной пропускной способности до 270 Kbps, даже несмотря на доступность 50 Мбит! Пока мы используем TCP, мы связаны правилами порядка доставки и управления перегрузкой, агрессивно реагирующими на каждую потерю.

RDP 8 (RemoteFX) вместе с протоколом UDP снимают эти ограничения и все эти факторы берутся под контроль. Протокол UDP может обеспечить надежные и лучшие условия доставки данных в зависимости от потребностей их отправителей. Например, пользователи аудио и видеопотоков менее озабочены восстановлением от потери пакетов и больше заинтересованы в подавлении джиттера. Для таких потоков данных UDP может обеспечить лучшую эффективность без необходимости повторной передачи. Для тех, кому надежность поставки более важна, UDP в RDP 8 (RemoteFX) включает в себя важные технологии повышения надежности, некоторые из которых указанны ниже.

Прямая коррекция ошибок.

UDP в RDP 8 (RemoteFX) использует Forward Error Correction (FEC), чтобы восстановится при потери пакетов данных. В тех случаях, когда такие пакеты могут быть восстановлены, пересылке не нужно ждать, чтобы данные были повторно отправлены, что позволяет совершить немедленную доставку данных, и предотвращает "Блокировку начала строки". Это улучшение приводит к общему повышению оперативности реагирования.

О потере пропускной способности. Протокол без строгого контроля перегрузки очень вреден для производительности сети и может повлиять на все сетевые потоки даже за пределами удаленного взаимодействия. Таким образом, протокол UDP в RDP 8 (RemoteFX) реализует промышленный стандарт управления перегрузкой, и при этом включены следующие преимущества:

• Компенсация пропускной способности при потерях не связанных с их зависанием (например, потеря пакетов от источника помех, WiFi)
• Улучшенное ускорение восстановления после потери сети
• Баланс трафика RDP 8 (RemoteFX) и других конкурирующих трафиков в сети

Поскольку прямая коррекция ошибок требует некоторой избыточности в передаваемых данных, мы бы не хотели, чтобы данные затраты возникали в самый неудобный момент. Таким образом, UDP добавлен в дополнение к текущим возможностям TCP и используется для передачи интерактивных данных (таких, как графика, аудио, видео и сенсорные команды). В то время как остальные возможности до сих пор использовались для первоначального подключения и неинтерактивного трафика.

На следующем рисунке показаны улучшения, которые мы можем достичь в общей пропускной способности по сравнению с TCP. Это очень небольшая часть матрицы измерения производительности используется для оценки RDP 8 (RemoteFX) и передачи данных по протоколу UDP.

Пропускная способность - всего лишь часть оптимизированной передачи данных в WAN. Очередь задержки имеет не менее важную роль. На следующем рисунке показано, как UDP в RDP 8 (RemoteFX) в состоянии удерживать задержки в хорошем диапазоне (около или меньше 100 мс) даже в экстремальных условиях WAN.

На следующем рисунке показан визуальный обзор типов повышения производительности и их ожидаемое воздействие.

Безопасность протокола UDP в RDP 8 (RemoteFX)

Как уже говорилось выше, протокол UDP в RDP 8 (RemoteFX) обеспечивает значительное повышение производительности в различных WAN конфигурациях. Удалось добиться прироста производительности без ущерба безопасности.

Когда UDP используется для надежной передачи данных, он защищен с помощью протокола Secure Sockets Layer (SSL), который похож на TCP протокол. Однако SSL не может быть использован для максимальных объемов передачи данных, где некоторые данные могут быть потеряны. Вместо того, чтобы изобретать собственный механизм безопасности UDP, что потребовало бы много времени и сил, мы объединились с группой безопасности Windows для использования Datagram Transport Layer Security (DTLS), который является предлагаемым стандартом, определенным как IETF RFC 6347.

Подключение протокола UDP в RDP 8 (RemoteFX)

Протокол UDP может не всегда быть доступным в связи с отсутствием поддержки в некоторых сетевых конфигурациях. Мы предприняли шаги, чтобы протокол UDP был доступен в большинстве зависящих от нас сетевых конфигурациях. Наиболее значительные из этих шагов - встроенная поддержка UDP в RD (TS) Gateway (а не через TCP, как некоторые VPN). Для безопасности и удобства управления, только один порт (3391) открыт на RD (TS) Gateway для соединения UDP (по аналогии с TCP). Кроме того, только один порт (3389) для UDP открыт на терминальном сервере (по аналогии с TCP).

Дополнительно, подключение с использованием протокола UDP показывает индикатор качества связи в клиентах подключения к удаленному рабочему столу (версии 8.0 или Metro).

Настройка RDP 8 (RemoteFX) для WAN

Мы предоставили необходимые параметры групповых политик, которые позволяют администратору контролировать новые параметры RDP 8 (RemoteFX) для WAN. Эти параметры политик находятся в разделе Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленного рабочего стола -> Узел сеансов удаленных рабочего стола -> Подключения.

Один из этих параметров политики позволяет администратору настроить использование протоколов UDP и TCP.

Другой параметр политики позволяет администратору настроить автоматическое определение скорости подключения к сети для RDP 8 (RemoteFX).

Заключение

Таким образом, протокол RDP 8 (RemoteFX) включает в себя методы передачи, которые являются адаптивными к изменениям состояния сети и потери пакетов. Хотя протокол UDP обеспечивает лучшую производительность в беспроводных сетях и сетях с высокой латентностью WAN, мы понимаем, что UDP-соединения не всегда могут быть установлены во многих реальных сетевых конфигурациях.

Таким образом, многие другие улучшения протокола RDP 8 (RemoteFX) для WAN, такие как автоматическое определение скорости подключения к сети также были включены в транспортный протокол TCP, динамически переключаясь на TCP там, где протокол UDP не доступен. Передача UDP включает промышленные стандарты шифрования и безопасности и также изначально поддерживается через шлюз удаленных рабочих столов.

Протокол RDP 8 (RemoteFX), в сочетании с адаптивной графикой и другими улучшениями, обеспечивает оптимальное взаимодействие пользователя с любыми существующими сетями.

В статье использовались материалы из блога команды разработчиков Microsoft Remote Desktop Services.