Rdp windows 10 увеличить скорость

Обновлено: 04.07.2024

Дома OC это Win7
На работе OC это WinXP

А по теме минимальное количество цветов, убрать передачу звуков, на закладке дополнительно убрать всё окромя кеширования. И наступит счастье.

Становится лучше но мало заметно.
Не в этом скарее всего проблема.

Дома и на работе интернет раздается. Через ADSL модем в режиме роутера.

Добавлено:
Где то в нете читал. Что нужно какое MTU Проверять. Мол из за него косяки. Но я начинающий. И не сильно понимаю, что это такое. Пытаюсь разобраться.

да действительно - такие пинги хорошие для работы rdp. Это конечно если провайдер не занимается глупостями и не отправляет пинги через более скоростные каналы :)

1. Попробовать из другого места законнектиться - не из дома. Можно друга попросить.
2. пинги от меня ужасные

При том, что до твоих ближайших соседей все отлично :

ping -c 20 86.57.152.103
PING 86.57.152.103 (86.57.152.103) 56(84) bytes of data.
64 bytes from 86.57.152.103: icmp_seq=1 ttl=40 time=724 ms
64 bytes from 86.57.152.103: icmp_seq=2 ttl=40 time=717 ms
64 bytes from 86.57.152.103: icmp_seq=3 ttl=40 time=663 ms
64 bytes from 86.57.152.103: icmp_seq=4 ttl=40 time=762 ms
64 bytes from 86.57.152.103: icmp_seq=5 ttl=40 time=629 ms
64 bytes from 86.57.152.103: icmp_seq=6 ttl=40 time=849 ms
64 bytes from 86.57.152.103: icmp_seq=7 ttl=40 time=1056 ms
64 bytes from 86.57.152.103: icmp_seq=8 ttl=40 time=1229 ms
64 bytes from 86.57.152.103: icmp_seq=9 ttl=40 time=961 ms
64 bytes from 86.57.152.103: icmp_seq=10 ttl=40 time=1040 ms
64 bytes from 86.57.152.103: icmp_seq=11 ttl=40 time=1351 ms
64 bytes from 86.57.152.103: icmp_seq=12 ttl=40 time=1199 ms
64 bytes from 86.57.152.103: icmp_seq=13 ttl=40 time=672 ms
64 bytes from 86.57.152.103: icmp_seq=14 ttl=40 time=909 ms
64 bytes from 86.57.152.103: icmp_seq=15 ttl=40 time=986 ms
64 bytes from 86.57.152.103: icmp_seq=16 ttl=40 time=845 ms
64 bytes from 86.57.152.103: icmp_seq=17 ttl=40 time=369 ms
64 bytes from 86.57.152.103: icmp_seq=18 ttl=40 time=599 ms
64 bytes from 86.57.152.103: icmp_seq=19 ttl=40 time=729 ms
64 bytes from 86.57.152.103: icmp_seq=20 ttl=40 time=881 ms

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

Временные проблемы с новыми виртуальными машинами Microsoft Azure

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

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

Чтобы устранить эту проблему, установите следующие обновления на виртуальные машины:

Windows 10 и Windows Server 2016: 30 августа 2018 г. — KB4343884 (сборка ОС 14393.2457).
Windows Server 2012 R2: 30 августа 2018 г. — KB4343891 (ознакомительная версия ежемесячного накопительного пакета);

Проблемы с воспроизведением видео в Windows 10 версии 1709

Эта проблема возникает, когда пользователи подключаются к удаленным компьютерам под управлением Windows 10 версии 1709. Если эти пользователи воспроизводят видео с помощью кодека VMR9 (Video Mixing Renderer 9), в проигрывателе отображается только черное окно.

Это известная проблема в Windows 10 версии 1709. В Windows 10 версии 1703 такой проблемы нет.

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

Эта проблема возникает, когда у пользователя есть профиль с доступом только на чтение (и соответствующий куст реестра), например в сценарии киоска. Если такой пользователь подключается к удаленному компьютеру под управлением Windows 10 версии 1803, он не сможет совместно использовать рабочий стол.

Чтобы устранить эту проблему, примените обновление для Windows 10 за 24 июля 2018 г. — KB4340917 (сборка ОС 17134.191).

Проблемы с производительностью при одновременном использовании разных версий Windows 10 и отключении NLA

Эта проблема возникает при отключении NLA, когда клиентские компьютеры Удаленного рабочего стола под управлением Windows 10 подключаются к удаленным рабочим столам под управлением других версий Windows 10. При работе с клиентами удаленных рабочих столов на компьютерах под управлением Windows 10 до версии 1709 пользователи могут столкнуться с низкой производительностью, когда попытаются подключиться к удаленным рабочим столам под управлением Windows 10 версии после 1803.

Так происходит потому, что, если отключить NLA, клиентские компьютеры с более ранними версиями используют более медленный протокол при подключении к Windows 10 версии 1803 и выше.

Чтобы устранить эту проблему, примените обновление за 24 июля 2018 г. — KB4340917 (сборка ОС 17134.191).

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

Эта проблема возникает в Windows 8.0, Windows 8.1, Windows 10 RTM и Windows Server 2012 R2. Пользователь запускает несколько приложений на удаленном рабочем столе, а затем отключает сеанс. Периодически пользователь повторно подключается к удаленному рабочему столу для взаимодействия с приложениями, а затем снова отключается. В какой-то момент при повторном подключении пользователя к сеансу удаленного рабочего стола появляется черный экран. Для нормальной работы пользователю необходимо завершить сеанс из консоли удаленного компьютера или сервера RDSH и остановить приложения, выполняющиеся в сеансе.

Эта статья актуальна для 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.

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

Читайте также: