Ускорить RDP. Ограничиваем размер окна TCP.

Думаю, не ошибусь, если предположу, что с тормозами при работе с удаленным рабочим столом (RDP) сталкивались все, кто с RPD работал. Симптомов тормозов может много: медленно передает файлы через буфер обмена, долго печатает, медленно отрисовывается экран при прокрутке, особенно если просматривать тяжелые сайты, нагруженные графикой, pdf, состоящих из сканов и т.п. Соответсвенно, и решения как ускорить RDP тоже бывают разные. Ниже опишу одно из решений проблемы отрисовки экрана, когда при работе с удаленным RDP, через интернет, а не в пределах локальной сети, прокрутка документов, перемещение объектов рабочего стола, масштабирование в документах вызывает существенный дискомфорт — все дергается, нет плавности движений.

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

Когда вы работаете с удаленным RDP может быть намного важнее, чтобы при перемещениях мыши, при скролле графики (т.е. когда быстро и не потоком меняются передаваемые данные, кеширование тут не сильно поможет) клиент получал бы данные от сервера чаще, пусть и с меньшей максимальной средней скоростью. Так как обе стороны соединения (сервер и клиент) согласовывают в процессе работы допустимый размер окна для данных, если этот размер сильно ограничить (а то и вовсе запретить его изменение), то обе стороны быстро поймут, что размер окна маленький, данные накапливать нет смысла, и будут чаще обмениваться данными, засоряя эфир лишними техническими пакетами, но для пользователя это может привести к «ускорению» работы с интерфейсом — увеличению плавности и отзывчивости интерфейса.

На Windows сервере RDP:

1. проверьте, что сейчас настроено:

> netsh interface tcp show global

Запрос активного состояния.

Глобальные параметры TCP
——————————————————
Состояние масштабирования на стороне приема : enabled
Состояние разгрузки канала : automatic
Состояние NetDMA : enabled
Прямой доступ к кэшу (DCA) : disabled
Уровень автонастройки окна получения : normal
Поставщик надстройки контроля перегрузки : none
Мощность ECN : disabled
Отметки времени RFC 1323 : disabled
** Параметр autotuninglevel выше — это результат переопределения всех локальных
конфигураций и конфигураций политик по крайней мере на одном профиле эвристикой масштабирования окон.

Нас интересует «Уровень автонастройки окна получения» (autotuninglevel, см. чуть ниже). По-умолчанию, normal, т.е. грубо — «автонастройка».

Возможные варианты параметра autotuninglevel :

• disabled: фиксация значения окна приема по умолчанию.
• highlyrestricted: разрешение на увеличение окна приема относительно значения по умолчанию, но очень незначительное.
• restricted: разрешение на увеличение окна приема относительно значения по умолчанию, с ограничением увеличения при некоторых сценариях.
• normal: разрешение на увеличение окна приема в соответствии с требованиями большинства сценариев.
• experimental: разрешение на увеличение окна приема в соответствии с требованиями экстремальных сценариев.

В нашем случае можно проверить эффект от вариантов disabled и highlyrestricted.

> netsh interface tcp set global autotuninglevel=highlyrestricted

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

> netsh interface tcp set global autotuninglevel=disabled

или у вас есть иные причины проблем с RDP.

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

Также проверял эффект в локальной сети — на Windows 7 в локалке эффект привел к незначительному увеличению рывков, ускорять уже было мало что, но плавность стала хуже. Чуть-чуть. Возможно, это из-за того, что при удаленной работе через интернет RDP уже и так зарезано и мы его лишь тюнигуем, а в локальной сети проблем нет и я просто зарезал часть возможностей. Удачи в экспериментах, оставляйте отзывы о результатах или свои мнения.

Производительность RDP в Windows Server и способы ее повышения

Эта статья актуальна для Windows Server 2019 в качестве сервера и Windows 10 в качестве клиента RDP. В статье мы рассмотрим шаги, которые следует предпринять для достижения максимальной производительности терминальных сессий RDP в Windows Server.

1. Коротко об основном

В Windows 10 вместе с стандартным клиентом удаленного стола (MSTSC), появился новый клиент для осуществления удаленных подключений Remote Desktop (MSRDC) client, проинсталлировать который можно из магазина Microsoft Windows 10.

Отметим, что изначально MSRDC поддерживал удаленные подключения с Windows Virtual Desktop (VDI). На данный момент существуют клиенты для Windows Desktop, Android, iOS, macOS.

Можно сравнить два типа клиентов для удаленных подключений – MSTSC и MSRDC.

Тестирование проводилось на виртуальных машинах с Windows Server 2019 и Windows 10.

В качестве теста копировался файл с клиента на сервер. По итогу тестирования имеем такие результаты – копирование с помощью MSTSC:

Для сравнения – скриншоты процесса копирования файла с помощью MSRDC:

Как видим, файл копируется быстрее с помощью mstsc, но при этом mstsc создает значительно более высокую нагрузку на сеть и ЦП, занимая практически все доступные ресурсы. При этом использование нового клиента MSRDC выглядит более предпочтительным, т.к. при большом количестве одновременных подключений будет создавать более пологий график нагрузки на системные ресурсы, чем MSTSC.

С другой стороны, хочется отметить «сырость» нового клиента для удаленных подключений. К примеру, копирование файлов с сервера на клиент попросту не работает. При этом оба клиента используют протокол TCP для подключения к серверу.

2. Сжатие передачи данных при подключении к серверу

Для клиентов RDP можно настроить сжатие передачи данных при подключении к серверу.

Для этого на сервере необходимо открыть объект локально групповой политики и изменить значение:

Конфигурация компьютера → Административные шаблоны → компоненты Windows→ Службы удаленных рабочих столов → Удаленный рабочий стол узле сеансов → Среда удаленного сеанса → Настроить сжатие для данных RemoteFX.

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

Для эксперимента попробуем оптимизировать работу за счет оптимизации работы пропускной способности сети.

Меняем параметр и перезагружаем сервер:

Смотрим, что получилось для MSTSC:

Как видим – ничего не поменялось. Это потому, что данный механизм будет заметен только на большом количестве подключений. Тогда-то мы и увидим уменьшение потребления пропускной способности сети.

3. Отключение перенаправленных устройств

Настройка с помощью GPO находится в:

Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Службы удаленных рабочих столов → Удаленный узел сеансов рабочего стола → Перенаправление устройств и ресурсов.

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

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

Перенаправленные принтеры и устройства Plug & Play потребляют ресурсы процессора также при входе в сеанс RDP.

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

4. Параметры интерфейса клиента

• Отключить фоновый рисунок, это значительно снизит потребление пропускной способности сети.
• Кеш точечных рисунков необходимо всегда включать, т.к. в этом случае создается клиентский кэш растровых изображений, отображаемых в сеансе, что значительно снижает использование пропускной способности.
• Имеет смысл выключать отображение содержимого окон при перетаскивании, т.к. это снижает нагрузку на сеть за счет отображения только рамки окна вместо всего содержимого.
• Точно так же стоит отключать анимацию меню и окон, поскольку она увеличивает нагрузку на сетевую подсистему
• ClearType нужно включать для систем более ранних, чем Windows 7 и Windows 2008 R2
• Стили оформления – параметр, актуальный для систем Windows 7 и более ранних. Если параметр отключен, пропускная способность снижается за счет упрощения чертежей, использующих классическую тему.
• Серьезно влияет на загрузку ЦП и пропускной способности сети и разрешение экрана, с которым клиент подключается к серверу.
• Корпорация Microsoft рекомендует оставлять параметры подключения клиента в автоматическом режиме, но есть смысл попробовать выставить параметры вручную.

Например, если вы выставите на клиенте настройку «Подключаться со скоростью модем 56 Кбит/с – это отключит множество визуальных эффектов и значительно ускорит работу сервера в контексте подключения большого числа клиентов RDP.

5. Параметры конфигурации сервера RDP

1. Файл подкачки на сервере должен иметь достаточный размер. При нехватке виртуальной памяти в работе сервера могут возникать сбои.
2. Антивирус может значительно замедлить работу системы. Особенно серьёзно он может влиять на загрузку ЦП. Есть рекомендация исключать папки с временными файлами, особенно те, которые создаются системой.
3. Планировщик заданий может содержать большое количество заданий, ненужных на сервере RDS. Их есть смысл отключать.
4. На сервере RDS рекомендуется отключать все уведомления рабочего стола, поскольку они могут потреблять значительное количество системных ресурсов.

Вы можете использовать эти знания самостоятельно,

обратиться в нашу службу техподдержки (необходима авторизация)

Какие есть решения для повышения графической производительности RDP?

Чем больше гуглю, тем больше возникает вопросов по поводу использования GPU через RDP.

Суть: есть хороший, мощный сервер с двумя Xeon и встроенным GPU ATI ES1000 32MB. Стоит MS Windows 2008 R2, клиенты подключаются по RDP в LAN (в основном Windows 10, можно довести показатель до 100%).

Проблема: при работе с тяжелыми PDF да и просто Excel начинают тормоза, загрузка процессоров взлетает до 80%. Подозреваю что из-за обработки задач GPU на CPU.

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

Вопрос первый — если я установлю какую-нибудь GTX970 с 4гб в сервер, на производительность это не повлияет — верно?
Вопрос второй — если я сделаю выше написанное и включу RemoteFX, повлияет ли это на производительность?
Вопрос третий — насколько я все же понял, для адекватной работы RemoteFX нужно разворачивать машину на Hyper-V и использовать ее для RDP. Или я неправильно понял? В общем, ищу консультации или подскажите куда копать и какие технологии используются.

• Вопрос задан более трёх лет назад
• 4219 просмотров

Самая главная проблема RDP в старых Windows Server — это то, что RDP там работает по протоколу TCP, что означает примерно следующее: когда пользователь смотрит картинку или прокручивает её взад-перед, (PDF как раз попадает под описание) либо просто достаточно активно пользуется удаленной сессией и это влечет за собой постоянное обновление экрана, сервер отправляет клиенту данные по протоколу TCP, смысл которого не просто пульнуться пакетом в получателя, а проверить, что тот его принял и готов к дальнейшему общению. А теперь представьте, сколько таких пакетов летит в клиент при работе с графикой, и пока на клиенте не отрисуется каждое сделанное им изменение в удаленной сессии, все последующие к нему не поступят.
Попробуйте аналогичные действия проделать в терминальной сессии на Win Srv 2012 или R2, так RDP работает по протоколу UDP, которому, мягко говоря, плевать все ли получил клиент. Это даже позволяет смотреть видео ч-з RDP.

Что касается остальных вопросов

Вопрос первый — если я установлю какую-нибудь GTX970 с 4гб в сервер, на производительность это не повлияет — верно?

Вопрос второй — если я сделаю выше написанное и включу RemoteFX.

Медленно работают RemoteAPP, проблемы с меню в Windows 10 1803

После установки последнего обновления Windows 10 1803 April Update, у пользователей стали некорректно работать RemoteApp приложения, опубликованные на RDS серверах с Windows Server 2012 R2/ Server 2016 (на всех серверах установлены актуальные обновления безопасности). RemoteApp приложения стали работать заметно медленнее, любое действие, которое вызывается щелчком мыши выполняется (отрисовывается?) в 2-3 раза дольше. Особенно медленно отображаются в RemoteApp меню, вызываемые по щелчку правой кнопкой мыши (пункты меню мерцают, приходится нажимать на них по несколько раз, а иногда совсем не появляются).

Окно remoteapp при свертывании/ развертывании отрисовывается некорректно, в сессии залипают клавиши (у меня залипала CTRL), не всегда отображаются выпадающие элементы в меню.

Клиенты Windows 7 и более старых билдов Windows 10 (1703, 1607) при этом работают с remoteapp нормально. В обычном подключении к рабочему столу сервера через RDP все приложения на RDS сервере и меню отображаются нормально.

Таким образом, наши пользователи помимо ошибки CredSSP encryption oracle remediation в мае столкнулись еще и с плохой производительностью RemoteApp в Windows 10 1803. Жаркий получился месяц :).

Для временного решения проблемы можно попробовать в редакторе локальной GPO (gpedit.msc) на RDS серверах изменить значение политики Use advanced RemoteFX graphics for RemoteApp (Использовать дополнительную графику для удаленного приложения RemoteApp) на Disabled (раздел Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment, в русской редакции Windows путь такой: Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удалённых рабочих столов -> Среда удаленных сеансов).

В том случае, если в качестве remoteapp опубликованы графические программы (в частности семейства CAD), то без Remote FX они работать не будут.

Для радиакльного исправления проблемы, вы можете о ткатить текущий билд Windows к предыдущей версии (Recovery Options -> Get Started -> Go back to the previous version of Windows 10).

Однако есть и обходное решение , которое заключается в замене версии клиента RDP на более старую. Т.к. проблемы с производительностью Remoteapp встречались еще в Windows 10 1709, лучше всего использовать библиотеки RDP из 1607 или 1703.
Дело в том, что после апгрейда до Windows 10 1803 в системе устанавливается новая версия клиента RDP, которая на данный момент работает некорректно с опубликованными через RemoteApp приложениями. В April Update 2018 были обновлены файлы mstsc.exe и mstscax.dll .
Убедитесь, что у вас установлена именно версия Windows 10 1803 (OS Build 17133.1) или 1709. Выполните команду

Если заменить данные файлы в каталоге C:\Windows\System32 на версии файлов из предыдущего билда Windows 10 (1703 или 1607), проблема с производительностью RemoteApp исчезает.

Как заменить файлы клиента RDP в Windows 10:

• Закройте все RDP подключения и запущенные RemoteApp (лучше даже перезагрузить компьютер).
• Скачайте архив с версиями файлов mstsc.exe и mstscax.dll из Windows 10 1607 (ссылка на скачивание с Я.Диска mstsc-w10-1607.zip ).
• Скопируйте оригинальные файлы mstsc.exe и mstscax.dll из каталога C:\windows\system32\ в каталог C:\Backup с помощью команд:
  md c:\backup\
  copy C:\windows\system32\mstsc.exe c:\backup
  copy C:\windows\system32\mstscax.dll c:\backup

• Затем нужно назначить свою учетную запись владельцем файлов mstsc.exe и mstscax.dll в каталоге C:\windows\system32\, отключите наследование и предоставьте себе права на изменение файлов:

takeown /F C:\windows\system32\mstsc.exe

takeown /F C:\windows\system32\mstscax.dll

icacls C:\windows\system32\mstsc.exe /inheritance:d

icacls C:\windows\system32\mstscax.dll /inheritance:d

icacls C:\windows\system32\mstsc.exe /grant root:F

icacls C:\windows\system32\mstscax.dll /grant root:F

• Замените файлы в каталоге C:\windows\system32\ файлами из скачанного архива.
• Восстановим оригинальные разрешения на замененых файлах. Включим наследования NTFS разрешений и установим владельцем файлов «NT Service\TrustedInstaller» командами:
  icacls C:\windows\system32\mstsc.exe /inheritance:e
  icacls C:\windows\system32\mstscax.dll /inheritance:e
  icacls C:\windows\system32\mstsc.exe /setowner «NT Service\TrustedInstaller» /T /C
  icacls C:\windows\system32\mstscax.dll /setowner «NT Service\TrustedInstaller» /T /C
• Осталось перерегистрировать библиотеку:
  regsvr32 C:\Windows\System32\mstscax.dll

Совет . Либо можно выполнить замену, запустив командную строку от имени системы .

Теперь в ваших RemotApp должна восстановиться нормальная производительность,