Как увеличить скорость удаленного рабочего стола

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

Думаю, не ошибусь, если предположу, что с тормозами при работе с удаленным рабочим столом (RDP) сталкивались все, кто с RPD работал. Симптомов тормозов может много: медленно передает файлы через буфер обмена, долго печатает, медленно отрисовывается экран при прокрутке, особенно если просматривать тяжелые сайты, нагруженные графикой, pdf, состоящих из сканов и т.п. Соответственно, и решения как ускорить RDP тоже бывают разные (см. также "Что такое 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 уже и так зарезано и мы его лишь тюнигуем, а в локальной сети проблем нет и я просто зарезал часть возможностей. Удачи в экспериментах, оставляйте отзывы о результатах или свои мнения.

Авторизуйтесь для добавления комментариев!

Почтовый сервер Шифрование Squid 3proxy VPN Mikrotik Настройка сервера Виртуальные машины kvm Защита почты Резервное копирование Групповые политики SELinux WDS IPFW OpenVPN firewalld systemd Mobile libvirt Samba WiFi Iptables NAT Lightsquid Remote desktop Postfix Dovecot Удаление данных Софт Безопасность Настройка прокси Winbox User agent Хостинг Передача данных Онлайн сервисы Privacy LetsEncrypt VPN сервер RRDTool sendmail Rsync Linux SSH Система Windows Синхронизация Облако fail2ban FreeBSD

Производительность 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 рекомендуется отключать все уведомления рабочего стола, поскольку они могут потреблять значительное количество системных ресурсов.

Поделиться:

analitik_samara

Как вы уже знаете, у меня есть данная свыше особенность встречать проблемы там, где у других они не возникают. Классика жанра – установить очередную широко известную, а часто и дорого продаваемую программу и, только начав её освоение, тут же обнаружить косяки разработчиков, о которых они и не догадывались. А поскольку косяки эти мешают пользованию, приходится сообщать о них авторам с просьбой устранить или хотя бы помочь разобраться в причинах возникновения. Примеров мог бы привести огромное количество, но на это нет ни времени, ни желания, да и вряд ли кому-то будет интересно с ними знакомиться – просто поверьте на слово.

Так получилось и на этот раз. После замены вышедшей из строя материнской платы на сервере установил на него с нуля Windows Server 2012 R2, настроил подключение к нему пользователей в режиме удалённого рабочего стола, перенёс нагрузку с временного сервера (мастерство за три года работы админом отточил до такой степени, что замену сервера выполнил через удалённый доступ к сети предприятия, не выходя из дома), и только приготовился почивать на лаврах, принимая благодарности от пользователей за то, что наконец-то снова всё стало летать, как до прехода на временный сервер на базе обычного офисного компа, как вдруг.

Вместо благодарностей на меня обрушился шквал негодования тем, что на новом (отремонтированном старом) сервере всё жутко тормозит. Стал разбираться с пристрастием — и действительно, творится что-то мистическое. Загрузка памяти 50%, загрузка процессора, пропускной способности дисков и сети — процентов по 10%, однако интерфейс операционной системы (и особенно 1С Предприятия 7.7, ради которого всё и затевалось) через удалённый доступ отрисовывается настолько медленно, что аж подбешивает.

Привлёк для решения проблемы ведущего специалиста из компании SysElegance — разработчика альтернативного Майкрософтовскому сервера терминалов. Тот сначала, конечно же, грешил на антивирус, TeamViewer и прочие резидентные программы, в изобилии запускающиеся при входе на сервер каждого пользователя, но вскоре (при моём активном аргументировании, что на временном сервере установлено точно такое же ПО, но он не тормозит) пришёл к выводу, что проблема всё же в сетевом оборудовании. Посоветовал перезагрузить коммутатор, поменять кабели, подключить сервер к сети через другую сетевую карту, через промежуточный хаб другого производителя, соединить, наконец, клиента с сервером напрямую. Я всё это сделал – результат нулевой, отрисовка интерфейса по-прежнему медленная, в то время как архивы с сервера копируются по сети на гигабитной скорости без каких-либо претензий. Удалил с сервера на всякий случай пару программ, которые теоретически могли бы замедлять работу сети — эффекта, как и ожидал, не получил.

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

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