Ускорить 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-подключения

Добрый день.
Настроено подключение к удаленной машине, но работает очень медленно. Различные артефакты на экране, долгое сворачивание\разворачивание приложения и другие «лаги».

В win7, например, можно было настроить colordepth, который ускорял отображение информации.

Существуют ли какие-нибудь «твики» для таких подключений в Win10Home?

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

Улучшение рейтинга производительности Windows 7
Здравствуйте. Насчет Windows Experience Index (system component rating). Какие есть действенные.

Улучшение производительности путем замены комплектующих
Доброго времени суток, собрал не давно для себя Пк по быстрее чем был до этого, сумма была не.

Улучшение производительности. AMD + Intel HD Graphics
Здравствуйте! У меня есть следующий ноутбук -> HP — 15-ac022ur (ENERGY STAR). Но есть с ним одна.

нет потерь пакетов? запустите команду пинг на ппару минут с кодом

ping 192.168.1.1 -t 1024 -l

где 192.168.1.1 ip компьютера к которому подключаетесь.

Решение

v1le, речь идет об RDP-подключении в локальной сети, или через интернет?

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

Оптимизация скорости RDP – достаточно обширная тема, поэтому я разделю её на части. В этой будут те способы, которые будут уменьшать нагрузку на протокол до сжатия и до оптимизации сетевого уровня.
Цветность (битовая глубина)

В RDP 7.0 и выше доступны варианты 32,16 и 8 бит. Если речь идёт о работе, то для неё будет достаточно 16 бит. Это ощутимо снизит нагрузку на канал, притом иногда больше, чем в 2 раза, что удивительно, но факт. 8 бит, конечно, тоже можно, но уж больно страшно оно будет выглядеть. 16 бит же вполне приемлемы.
Примечание: В Windows Server 2008 R2 подключения с 8 битами уже не доступны.
Включите на сервере параметр Limit Maximum Color Depth, либо сделайте аналогичное действие в настройках RDP client.
Отключите ClearType

Когда у Вас выключен ClearType, протокол RDP передаёт не картинку, а команды по отрисовке символов. Когда включен – рендерит картинку со стороны сервера, сжимает и пересылает клиенту. Это с гарантией в разы менее эффективно, поэтому отключение ClearType значительно ускорит процесс работы и уменьшит время отклика. Сами удивитесь, насколько.
Это можно сделать как на уровне настроек клиента, так и на стороне сервера (параметр Do not allow font smoothing в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host).
Уберите wallpaper

Параметр Enforce removal of RD Wallpaper в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host резко улучшит ситуацию с перерисовкой экрана терминальной сессии. Пользователи без котиков на десктопе выживают нормально, проверено.
Включаем и настраиваем кэширование изображений

Если на клиенте есть достаточно оперативной памяти, то имеет смысл включить и настроить кэширование битмапов. Это позволит выиграть до 20-50% полосы пропускания. Для установки надо будет зайти в ключ
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\
и создать там параметры BitmapPersistCacheSize и BitmapCacheSize, оба типа DWORD 32.
Параметр BitmapPersistCacheSize обозначает размер в килобайтах дискового кэша. Значение по умолчанию – 10. Имеет смысл увеличить этот параметр хотя бы до 1000.
Параметр BitmapCacheSize обозначает размер в килобайтах кэша в RAM. Значение по умолчанию – 1500. Имеет смысл увеличить этот параметр хотя бы до 5000. Это будет всего 5 мегабайт на клиентскую сессию, при современных масштабах оперативной памяти это несущественно, и даже если приведёт к выигрышу 10% производительности, уже себя окупит. Кстати, этот же параметр можно поправить и в .rdp-файле; если сохранить своё RDP-подключение, а после открыть файл блокнотом, то среди параметров можно добавить что-то вида bitmapcachesize:i:5000, где 5000 – это 5МБ кэша.
Отключаем Desktop Composition

Desktop Composition привносит всякие “красивости” типа Aero и его друзей и ощутимо кушает полосу пропускания. Для работы это не нужно и вредно. Параметр Allow desktop composition for RDP Sessions в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host необходимо выставить в параметр Disabled.
Оптимизируем параметры Desktop Window Manager

Параметры, находящиеся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Desktop Window Manager, будут управлять “красивым” отображением плавно выезжающих меню и подобного. Их три – Do not allow window animations, Do not allow desktop compositions и Do not allow Flip3D invocation. Все их надо переключить в режим Enabled, т.е. по сути – отключить все эти функции.
Отключаем редирект неиспользуемых устройств

Если у Вас не планируется подключение определённых классов устройств (например, COM и LPT-портов), или аудио, имеет смысл отключить возможность их перенаправления со стороны сервера. Чтобы клиенты с дефолтными настройками RDP Client не тратили время подключения на согласование неиспользуемого функционала. Это делается там же, где и остальные настройки сервера, в Properties у RDP-Tcp, вкладка Client Settings (там же, где мы делали настройки с глубиной цвета), раздел Redirection.
Настраиваем общую логику оптимизации визуальных данных RDP

Параметр, называющийся Optimize visual experience for RDP sessions, находящийся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, будет управлять тем, как RDP будет воспринимает визуальные данные – как мультимедийные или как текстовые. Это, грубо говоря, “подсказка” алгоритму сжатия, как грамотнее себя вести. Соответственно, для работы надо будет выставить этот параметр в Text, а если хочется много красивых flash-баннеров, HTML5 и просматривать видеоклипы – лучше вариант Rich Multimedia.

Сжатие в RDP прошло долгий путь развития. По RDP 5.2 включительно была подсистема сжатия (“компрессор”), имеющий внутреннее название “Version 1” – самый простой и лёгкий вариант с точки зрения загрузки процессора клиента, но самый плохой с точки зрения нагрузки сети трафиком. В RDP 6.0 сделали “Version 2”, который был незначительно, но улучшен по параметру эффективности сжатия. Нам интересен “Version 3”, который работает только при подключении к серверам Windows Server 2008 и старше. Он сжимает лучше всех, а затраты процессорного времени с учётом мощностей современных компьютеров несуществены.
Выигрыш при включении V3 может, судя по тестам, достигать 60% и, в общем-то, и без тестов ощутимо заметен на глаз.
Как включить оптимальное сжатие в RDP

Это – клиентская настройка. Откройте в нужном объекте групповой политики Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, выберите там параметр Set compression algoritm for RDP data, включите его и выберите значение Optimize to use less network bandwidth.
Примечание: У многих возникает вопрос, зачем в списке есть параметр “отключить сжатие”. Это нужно в случае, когда Ваши RDP-сессии сжимает внешнее устройство, оптимизирующее WAN-подключения, что-то вида Cisco WAAS. В других случаях, конечно, отключать сжатие смысла нет.
Настройка сжатия звукового потока

RDP 7.0 приносит отличную возможность регулировать качество сжатия входящего звукового потока (т.е. звука, который идёт с сервера на клиента). Это достаточно полезно – например, если идёт работа на терминальном сервере, то кроме всяких служебных звуков вида “пришло сообщение в ICQ” другие особо как не планируются. Нет смысла передавать с сервера несжатый звук CD-качества, если для работы это не нужно. Соответственно, нужно настроить уровень сжатия звукового потока.
Данный параметр будет называться Limit audio playback quality и находиться в разделе Device and Resource Redirection в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host. Вариантов будет три:
High – звук будет идти без сжатия. Вообще. То есть, он будет подпадать под общее сжатие протокола RDP, но специфическое сжатие звука (с потерей качества) производиться не будет.
Medium – сжатие будет адаптироваться под канал так, чтобы не увеличивать задержку при передаче данных.
Dynamic – сжатие будет динамически адаптироваться под канал так, чтобы задержка не превышала 150ms.
Выберите подходящий. Как понятно, для офисной работы лучше выбрать Dynamic.

Низкая производительность или проблемы с приложениями во время подключения к удаленному рабочему столу Poor performance or application problems during remote desktop connection

В этой статье рассматривается несколько распространенных проблем, с которыми пользователи могут столкнуться при использовании возможностей удаленного рабочего стола. This article addresses several common issues that users can experience when they use remote desktop functionality.

Временные проблемы с новыми виртуальными машинами Microsoft Azure Intermittent problems with new Microsoft Azure virtual machines

Эта проблема затрагивает виртуальные машины, которые были недавно подготовлены. This issue affects virtual machines that have been recently provisioned. Когда пользователь подключается к виртуальной машине, сеанс удаленного рабочего стола некорректно загружает некоторые параметры пользователя. After the user connects to the virtual machine, the remote desktop session does not load all the user’s settings correctly.

Чтобы устранить эту проблему, отключитесь от виртуальной машины, подождите хотя бы 20 минут и подключитесь еще раз. To work around this issue, disconnect from the virtual machine, wait for at least 20 minutes, and then connect again.

Чтобы устранить эту проблему, установите следующие обновления на виртуальные машины: To resolve this issue, apply the following updates to the virtual machines, as appropriate:

Проблемы с воспроизведением видео в Windows 10 версии 1709 Video playback issues on Windows 10 version 1709

Эта проблема возникает, когда пользователи подключаются к удаленным компьютерам под управлением Windows 10 версии 1709. This issue occurs when users connect to remote computers that are running Windows 10, version 1709. Если эти пользователи воспроизводят видео с помощью кодека VMR9 (Video Mixing Renderer 9), в проигрывателе отображается только черное окно. When these users play video using the VMR9 (Video Mixing Renderer 9) codec, the player shows only a black window.

Это известная проблема в Windows 10 версии 1709. This is a known issue in Windows 10, version 1709. В Windows 10 версии 1703 такой проблемы нет. The issue doesn’t occur in Windows 10, version 1703.

Проблемы с совместным доступом к рабочему столу в Windows 10 Desktop sharing issues on Windows 10

Эта проблема возникает, когда у пользователя есть профиль с доступом только на чтение (и соответствующий куст реестра), например в сценарии киоска. This issue occurs when the user has a read-only user profile (and associated registry hive), such as in a kiosk scenario. Если такой пользователь подключается к удаленному компьютеру под управлением Windows 10 версии 1803, он не сможет совместно использовать рабочий стол. When such a user connects to a remote computer that is running Windows 10, version 1803, they can’t share their desktop.

Чтобы устранить эту проблему, примените обновление для Windows 10 за 24 июля 2018 г. — KB4340917 (сборка ОС 17134.191). To fix this issue, apply the Windows 10 update 4340917, July 24, 2018—KB4340917 (OS Build 17134.191).

Проблемы с производительностью при одновременном использовании разных версий Windows 10 и отключении NLA Performance issues when mixing versions of Windows 10 if NLA is disabled

Эта проблема возникает при отключении NLA, когда клиентские компьютеры Удаленного рабочего стола под управлением Windows 10 подключаются к удаленным рабочим столам под управлением других версий Windows 10. This issue occurs when Remote Desktop client computers running Windows 10 connect to remote desktops that run different versions of Windows 10 while NLA is disabled. При работе с клиентами удаленных рабочих столов на компьютерах под управлением Windows 10 до версии 1709 пользователи могут столкнуться с низкой производительностью, когда попытаются подключиться к удаленным рабочим столам под управлением Windows 10 версии после 1803. Users of Remote Desktop clients on computers running Windows 10, version 1709 or earlier experience poor performance when they connect to remote desktops running Windows 10, version 1803 or later.

Так происходит потому, что, если отключить NLA, клиентские компьютеры с более ранними версиями используют более медленный протокол при подключении к Windows 10 версии 1803 и выше. This occurs because, when NLA is disabled, the older client computers use a slower protocol when they connect to Windows 10, version 1803 or a later version.

Чтобы устранить эту проблему, примените обновление за 24 июля 2018 г. — KB4340917 (сборка ОС 17134.191). To resolve this issue, apply KB 4340917, July 24, 2018—KB4340917 (OS Build 17134.191).

Ошибка, из-за которой появляется черный экран Black screen issue

Эта проблема возникает в Windows 8.0, Windows 8.1, Windows 10 RTM и Windows Server 2012 R2. This issue occurs in Windows 8.0, Windows 8.1, Windows 10 RTM, and Windows Server 2012 R2. Пользователь запускает несколько приложений на удаленном рабочем столе, а затем отключает сеанс. A user launches multiple applications in a remote desktop, then disconnects from the session. Периодически пользователь повторно подключается к удаленному рабочему столу для взаимодействия с приложениями, а затем снова отключается. Periodically, the user reconnects to the remote desktop to interact with the applications, and then disconnects again. В какой-то момент при повторном подключении пользователя к сеансу удаленного рабочего стола появляется черный экран. At some point, when the user reconnects, the remote desktop session only shows a black screen. Для нормальной работы пользователю необходимо завершить сеанс из консоли удаленного компьютера или сервера RDSH и остановить приложения, выполняющиеся в сеансе. To get the session to display properly again, the user then has to end their session from either the remote computer’s console or the RDSH server console and stop their session’s applications.

Чтобы устранить эту проблему, установите следующие обновления: To resolve this issue, apply the following updates as appropriate: