Почему RDP тормозит при быстром канале? — разбираем ввод, отрисовку и сеть по отдельности

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

Разобраться в этом расхождении помогает простая мысль: способность передать много данных и быстрый отклик на действие — разные вещи. К тому же экран, который возвращается в качестве ответа, формируется на компьютере-хосте, а показывается на машине перед вами. Это не работа, которую выполняет только канал связи.¹

Проследим на одном и том же удалённом экране, что меняется при переходе от набора текста к прокрутке и затем к поиску в бизнес-приложении. Разделы 1–4 объясняют механизм, а начиная с раздела 5 идёт практическая часть — как всё это исследовать.

1. Более быстрый канал не всегда сокращает ожидание ответа

Предположим, вы вводите один символ в «Блокнот» на удалённой машине. Вы видите экран прямо перед собой, но сама программа работает на компьютере-хосте. Ваше действие отправляется туда, информация об изменившемся экране возвращается обратно, и символ появляется.

Так какую же часть этого кругового обхода отражают «500 Мбит/с» из спидтеста?

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

Для пояснения предположим, что действие доходит до хоста за 50 миллисекунд, а информация об изменившемся экране возвращается за 50 миллисекунд. Тогда только на сеть уходит 100 миллисекунд, то есть 0,1 секунды. Время обработки на компьютерах по обе стороны здесь пока не учитываем.

flowchart TB
    accTitle: Пример времени передачи по сети до возврата результата одного символа
    accDescr: Пример, в котором для пояснения принято по 50 миллисекунд в каждую сторону. Время обработки на обоих концах не учитывается, и это не число пакетов на одну клавишу.
    A["Ввод одного символа на своей машине"] -->|"Туда: 50 миллисекунд"| B["Хост принимает ввод"]
    B --> C["Отправка экрана с применённым вводом"]
    C -->|"Обратно: 50 миллисекунд"| D["Результат приходит на вашу машину"]

Рис. 1: Если путь туда занимает 50 миллисекунд, а обратно ещё 50, только сеть даёт 0,1 секунды. Это не измеренные значения.

Это время прохода по сети туда и обратно называется временем кругового обхода (round-trip time, RTT). Даже если перейти на канал с большей пропускной способностью, ожидание ответа из рисунка 1 останется, пока время кругового обхода не изменится.¹

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

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 7, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. При прокрутке растёт объём работы по отправке экрана

Когда вы добавляете один символ в «Блокноте», визуально меняется лишь небольшая часть экрана. Но если прокрутить страницу с фотографиями, широкая область изображения меняется кадр за кадром.

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

flowchart TB
    accTitle: Как меняется работа с экраном при наборе текста и прокрутке
    accDescr: Небольшое изменение символа и непрерывное обновление широкой области различаются по характеру работы по созданию и отправке экрана.
    A["Добавить один символ в «Блокноте»"] --> B["Меняется небольшая область"]
    C["Прокрутить экран с множеством фотографий"] --> D["Широкая область меняется непрерывно"]
    B --> E["Сжатие и передача в соответствии с изменением"]
    D --> E

Рис. 2: Даже на одном соединении объём работы при добавлении одного символа и при непрерывном движении широкой области различается.

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

Только теперь становится понятно, зачем понижать разрешение и сравнивать. Это не «магическое заклинание» для ускорения RDP, а эксперимент: вернётся ли отзывчивость, если уменьшить работу по формированию и отправке экрана. Как именно это попробовать, подробно описано в разделе 5.

Если набор текста идёт нормально, а тяжёлой остаётся только прокрутка, возможно, на том же канале обрабатывается гораздо больше обновлений экрана. А что если у канала ещё есть запас, но экран не успевает?

3. Даже при свободном канале компьютер, формирующий экран, может заставлять вас ждать

Экран обрабатывается и перед отправкой, и после получения

Когда вы прокручиваете страницу с фотографиями, компьютер-хост обновляет изображение и преобразует и сжимает информацию об экране в форму, которую проще отправить. Это кодирование. Компьютер перед вами возвращает пришедшую информацию в форму, пригодную для показа. Эту сторону называют декодированием.¹

flowchart TB
    accTitle: Обработка экрана происходит по обе стороны канала
    accDescr: Сжатие на хосте, передача по сети, а также декодирование и показ на вашей машине — это отдельные этапы, и если хотя бы один из них не успевает, обновления экрана запаздывают.
    A["Хост формирует и сжимает экран"] --> B["Канал передаёт информацию об экране"]
    B --> C["Локальная машина возвращает её в отображаемую форму"]
    C --> D["Показ на локальном экране"]

Рис. 3: Сжать на хосте, передать по каналу, вернуть к показу на локальной машине. Каждый этап выполняется в своём месте.

Предположим, например, что сжатие экрана на хосте занимает время. Даже при свободном канале вы ждёте, пока информация для отправки будет готова. И наоборот: даже если информация уже пришла, обновление экрана запаздывает, когда локальный компьютер не успевает с декодированием и показом.³

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

Если зависает только одно приложение, возможно, вы ждёте его ответа

Рассмотрим случай, когда на том же удалённом экране нажатие кнопки поиска в бизнес-приложении замораживает его на несколько секунд. При этом в открытом рядом окне «Блокнота» можно нормально печатать.

В такой ситуации хочется понять, чего именно ждёт бизнес-приложение. Возможно, приложение на хосте запрашивает поиск в отдельной базе данных, и ответ приходит медленно. Чтение файла из общей папки даёт такое же ожидание.⁴

flowchart TB
    accTitle: За пределами RDP есть и другие собеседники
    accDescr: Показан случай, когда помимо трафика между локальным клиентом и хостом приложение на хосте ждёт ответа от бизнес-сервера.
    A["Локальный клиент"] -->|"RDP"| B["Бизнес-приложение на хосте"]
    B -->|"Запрос поиска или файла"| C["БД и общие папки"]
    C -->|"Ответ, которого ждёт приложение"| B

Рис. 4: Бизнес-приложение за пределами RDP-соединения может, в свою очередь, ждать ответа от ещё одного сервера.

Кроме того, если код, отвечающий за экран и ввод приложения, берётся за длительную задачу, он не успевает обработать следующий ввод или обновление экрана. Например, UI-поток WPF, занятый долгое время, даёт именно такую задержку отклика. Наблюдая только за общей загрузкой процессора, легко пропустить ожидание в коде, который работает с экраном.⁵

То, что вы ждёте на экране RDP, ещё не значит, что вас задерживает сам RDP. Разница «Блокнот работает, а зависает только поиск» — это подсказка, которую можно заметить ещё до изменения сетевых настроек.

4. Промежуточный итог: скорость канала — лишь часть отзывчивости

Вернёмся к исходному вопросу: почему при быстром канале всё тормозит?

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

Большая цифра из спидтеста сама по себе не говорит, в порядке ли все эти три составляющие. Более того, сервер спидтеста и хост RDP, находящийся за VPN или шлюзом, достигаются по разным маршрутам. Свою роль играют и исходящее направление на хосте, который отправляет экран, и перегрузка на пути.¹⁴

Комфорт работы с RDP определяется не только тем, сколько данных можно передать, но и тем, как быстро становится виден результат действия. На этом объяснение механизма заканчивается. Когда вы действительно начнёте разбираться с торможением, выберите в разделах ниже сравнение, подходящее к вашему симптому.

5. Практика: сначала сравниваем одно и то же действие, меняя по одному условию

В примерах предполагается клиент «Подключение к удалённому рабочему столу» Windows и хост на Windows 11 или Windows Server. Примеры команд рассчитаны на Windows PowerShell 5.1. На рабочем компьютере выполняйте сравнения только в пределах, разрешённых администратором, и сохраняйте работу перед изменением настроек и повторным подключением.

Три случая выше — отправная точка для выбора сравнения. Таблица не выносит приговор причине, а служит началом обследования.

Если экран входа появляется долго или всё останавливается уже на аутентификации, начинайте с записей об установлении соединения и аутентификации. Точка входа для такого разбирательства отличается от ввода и прокрутки после подключения, о которых речь здесь.

Задерживается ли так же другое приложение?

Наберите примерно одинаковый объём текста в проблемном приложении и в «Блокноте». Сравнение внутри одного удалённого сеанса сначала позволяет увидеть разницу между приложениями, не меняя хост или канал. В «Диспетчере задач» посмотрите процессор, память и диск нужного приложения на хосте, а на своей машине — нагрузку клиента RDP.⁴

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

flowchart TB
    accTitle: Ограничиваем число условий, которые меняем за один раз
    accDescr: Схема, в которой сначала фиксируют действие, воспроизводящее проблему, в исходном состоянии, затем меняют только одно условие и сравнивают, а после проверяют и результат возврата.
    A["То же действие с исходными настройками"] --> B["Меняем только одно условие"]
    B --> C["Повторяем то же действие"]
    C --> D["Возвращаем и проверяем снова"]
    D --> E["Записываем условие, которое дало улучшение"]

Рис. 5: Повторите одно и то же действие в исходном состоянии, после изменения и после возврата и запишите, какое условие дало разницу.

Полезно и сравнение с работой за физическим экраном хоста. Однако учтите, что сеанс и условия отрисовки при локальной работе и в RDP могут различаться. Уравняйте пользователя, данные и состояние приложения и не сводите причину к каналу только потому, что «за физическим экраном всё быстро».

Если прокрутка тяжёлая, понижаем разрешение на удалённой стороне

Сначала измените что-то одно — число мониторов или разрешение — и прокрутите ту же страницу. В Windows с mstsc можно сравнивать через настройки экрана перед подключением или задавая ширину и высоту. Убедитесь, что рабочий стол хоста действительно изменил размер, а не просто уменьшилось окно на вашей машине. Иногда большой экран всего лишь отображается в уменьшенном масштабе.⁶⁷

У 3840×2160 вчетверо больше пикселей, чем у 1920×1080, но это не значит, что трафик всегда будет вчетверо больше. Всё зависит от изменившихся областей и от того, насколько хорошо работает сжатие. Понижение разрешения меняет и обработку графики на обоих концах, а не только трафик, поэтому если стало лучше, подсказку стоит искать именно в этой области.²³

flowchart TB
    accTitle: Что показывает сравнение с пониженным разрешением
    accDescr: Понижение разрешения на удалённой стороне может изменить и обработку графики, и нагрузку на передачу, поэтому одно лишь улучшение не позволяет свести причину к каналу.
    A["Понижаем разрешение на удалённой стороне"] --> B["Меняется обработка экрана на хосте"]
    A --> C["Меняется объём отправляемой информации"]
    A --> D["Меняется обработка показа на вашей машине"]

Рис. 6: Изменение разрешения влияет не только на канал, но и на обработку графики на хосте и на вашей машине.

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

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

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

flowchart TB
    accTitle: Смотрим период до и после сбоя на одной шкале времени
    accDescr: Фиксируем одно и то же действие и нагрузку до передачи, во время неё и после остановки, а затем сравниваем, как связаны сбой и эта работа.
    A["Действие и нагрузка до передачи"] --> B["Действие и нагрузка во время передачи"]
    B --> C["Действие и нагрузка после остановки"]
    C --> D["Совпадают ли сбой и восстановление"]

Рис. 7: Смотрим, как меняется замедление одного и того же действия и нагрузка до передачи, во время неё и после остановки.

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

6. Практика: подтверждаем цифрами, где именно ожидание

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

Со своей машины: проверяем круговой обход и TCP-соединение

Ниже пример на вашем клиенте Windows. Предполагается, что вы подключаетесь к хосту RDP напрямую по корпоративной локальной сети или через разрешённый VPN, а хост использует стандартный TCP-порт 3389. При работе через RD Gateway или Azure Virtual Desktop меняются и то, что вы проверяете, и сам маршрут. Не открывайте порты и не меняйте настройки брандмауэра.

$target = Read-Host 'Имя или IP-адрес хоста RDP, исследование которого вам разрешено'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Укажите хост для подключения.'
}

# Смотрим время отклика ICMP несколько раз. Один лишь сбой не доказывает недоступность RDP.
ping.exe -n 20 $target

# Проверка только для конфигураций с прямым подключением к стандартному TCP-порту 3389.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

ping проверяет время отклика на ICMP. Если в часы медленной работы значения сильно колеблются, запишите это. Но ICMP может быть заблокирован, и тогда ответа не будет вовсе. И наоборот: ряд маленьких значений не означает, что вы проверили передачу экрана или обработку в приложении RDP.⁸

TcpTestSucceeded: True — это результат, означающий, что TCP-соединение с этим портом установлено. Он не измеряет ни пропускную способность, ни UDP, ни то, насколько плавно работают действия и экран после аутентификации. У Test-NetConnection нет параметра -UDP для проверки UDP.⁹

Двадцать проб ping — короткое наблюдение. При периодических сбоях сопоставьте время появления симптома со сведениями о соединении. В Azure Virtual Desktop доступны также RTT по каждому соединению и оценка пропускной способности, но не отбрасывайте короткие остановки только на основании средних значений.¹

На хосте: проверяем ожидание до того, как приложение заберёт ввод

Запустите perfmon.exe внутри удалённого сеанса на хосте и, если среда это поддерживает, добавьте User Input Delay per Process или User Input Delay per Session. Выбрав нужный сеанс и процесс, можно наблюдать ожидание от попадания ввода в очередь до момента, когда приложение его заберёт.¹⁰

flowchart TB
    accTitle: Интервал, который измеряет User Input Delay
    accDescr: Измеряемый интервал охватывает от очереди ввода на хосте до момента, когда приложение заберёт ввод, и не включает сеть и показ экрана до и после.
    A["Ввод приходит с вашей машины"] --> B["Попадает в очередь ввода на хосте"]
    B -->|"Это и измеряется"| C["Приложение забирает ввод"]
    C --> D["Обработка в приложении и передача экрана"]
    D --> E["Показ на вашей машине"]

Рис. 8: Измеряется ожидание в очереди ввода на хосте. Это не общее время до момента, когда результат станет виден на вашей машине.

Значение — это самое долгое ожидание внутри интервала измерения. Счётчик поддерживается в Windows 10 версии 1809 и новее, а также в Windows Server 2019 и новее; на этих системах добавлять запись в реестр для его включения не требуется. Сначала наблюдайте с интервалом по умолчанию в одну секунду. Отображаемые имена, доступные счётчики и необходимые права проверяйте применительно к своей среде.¹⁰

Стандартное имя экземпляра для каждого процесса — SessionID:ProcessID <Process Image>. В PowerShell того же сеанса запишите время и идентификатор сеанса.¹⁰¹¹

Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session

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

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

На хосте: проверяем, успевают ли обновления экрана отправляться полностью

При рывках во время прокрутки используйте счётчики RemoteFX Graphics, где они доступны. Проверьте имя нужного сеанса с помощью query session или qwinsta и выберите подходящий экземпляр. Что именно измеряет счётчик и доступен ли он, нужно уточнять для используемой ОС, конфигурации хоста и ваших прав.³

Во время операции, обновляющей экран, сравните Input Frames/Second и Output Frames/Second. Если выход меньше входа, кадры теряются по пути. Значения Frames Skipped/Second в разбивке по нехватке ресурсов хоста, сети и клиента подскажут, где сузить область поиска.³

flowchart TB
    accTitle: Сужаем область поиска по отброшенным кадрам
    accDescr: Сравниваем число входных и выходных кадров во время операции с обновлениями экрана и по счётчикам причины отбрасывания сверяемся с нагрузкой на обработку, сеть и показ.
    A["Сравниваем вход и выход во время прокрутки"] --> B["Если выход меньше, проверяем отбрасывание кадров"]
    B --> C["Смотрим счётчики в разбивке по причине"]
    C --> D["Сверяем с нагрузкой на хосте, в сети и на вашей машине"]

Рис. 9: Сравните вход и выход во время прокрутки и сверьте причину отбрасывания кадров с нагрузкой на хосте, канале и вашей машине.

Если число кадров на входе изначально невелико, возможно, приложение просто редко обновляет экран. Малое число кадров на статичном экране — не отклонение. Если обновления есть, а всё равно медленно, посмотрите также Average Encoding Time, чтобы проверить, не занимает ли время сжатие на хосте.³

Замечание о чтении документации по измерениям. Схема в разделе 1 — концептуальная, она нужна для понимания обычной передачи экрана и не утверждает, что на каждую клавишу отправляется отдельный пакет кругового обхода. Некоторые конфигурации передают видео и звук отдельным механизмом. Журналы качества соединения Azure Virtual Desktop и документацию по счётчикам Graphics, в которой описаны и старые конфигурации, используйте только после проверки того, к чему относится эта возможность. Не читайте числа из такой документации как общую спецификацию вроде «любой RDP ограничен 30 кадрами в секунду».²¹³

7. Практика: настройки UDP и GPU выбираем по результатам обследования

Если сеть под подозрением, сначала проверяем фактический маршрут и транспорт

RDP использует TCP или UDP в зависимости от конфигурации и условий сети. Политика «Select RDP transport protocols» позволяет выбрать между вариантом с UDP или TCP и вариантом только с TCP. Поскольку есть и поведение с переходом на TCP, когда соединение по UDP установить не удаётся, сам факт подключения ничего не говорит о транспорте. Уточните его по сведениям о соединении на клиенте, диагностическим журналам продукта и сетевым записям администратора.¹²

flowchart TB
    accTitle: Проверяем транспорт до сравнения сетевых настроек
    accDescr: Отличаем обычное прямое подключение от подключения через шлюз или службу, проверяем фактический маршрут и транспорт и только затем выполняем разрешённые сравнения.
    A["Используемый клиент и конфигурация подключения"] --> B["Проверяем фактический маршрут и то, TCP это или UDP"]
    B --> C["Сверяем со временем появления симптома"]
    C --> D["Сравниваем только нужные настройки, по одной"]

Рис. 10: Убедитесь в используемом транспорте и маршруте, сверьте их с симптомом и только затем сравнивайте нужные настройки.

RDP Shortpath в Azure Virtual Desktop — это механизм, устанавливающий путь UDP для этой службы. С учётом того, как используются прямые пути и ретрансляция, его нельзя свести к той же таблице настроек, что и прямое подключение к офисному компьютеру через mstsc. Если Shortpath установить не удаётся, соединение возвращается к варианту на основе TCP.¹³

Не меняйте всё подряд исходя из идеи, что отключение UDP ускоряет работу. Уравняйте используемый транспорт, политики и условия VPN или шлюза, а затем сравнивайте. Отключение брандмауэра или аутентификации и публикация порта RDP напрямую в интернет — не те меры, которые стоит применять.

Если под подозрением обработка графики, проверяем, используется ли для неё GPU

Даже при наличии GPU из этого не следует, что отрисовка приложения на хосте, кодирование в RDP и декодирование на вашей машине используют его. В документации Microsoft по настройке GPU отрисовка в удалённом сеансе и аппаратное кодирование кадров также настраиваются и проверяются отдельно. Изучите поддерживаемые версии ОС, драйверы, политики и требования к клиенту.¹⁴

Если в разделе 6 выяснилось, что время сжатия велико, именно на этом этапе стоит проверить использование GPU для кодирования. Менять настройки кодирования для приложения, которое ждёт в очереди ввода, — значит целиться не туда. Работа, где нужен читаемый текст, и работа, где нужно плавное видео, требуют и разных компромиссов между качеством изображения, трафиком и нагрузкой на обработку.¹⁴²

Разработчики бизнес-приложений могут отследить ожидания внутри приложения, если будут записывать отдельно время получения события ввода, начало и конец обработки базы данных и файлов и момент, когда результат дошёл до UI. Важна и архитектура, в которой тяжёлая работа не оседает в UI-потоке. Учтите, что журнал о завершении обработки на хосте не фиксирует завершение показа на вашем экране.⁵

8. Заметки, которые стоит оставить при передаче обследования

Опишите медленное действие конкретно, например: «в Блокноте печатать можно нормально, а при прокрутке фотографий всё встаёт». Оставьте также проверенные условия и результаты.

Время появления симптома с указанием часового пояса:
ОС хоста, используемый клиент и версии:
Прямое подключение / VPN / RD Gateway / Azure Virtual Desktop и т. п.:
Медленное действие и приложение, реакция других приложений в том же сеансе:
Разрешение и число мониторов на удалённой стороне:
Одновременно работавшие копирование, печать и т. п.:
Единственное изменённое условие и результат после возврата:
Наблюдавшиеся нагрузка и счётчики на хосте и на вашей машине:

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

Похожие статьи

• Как понимать изоляцию сеансов в Windows
• Безопасно локализовать загрузку диска на 100 % в Windows
• Почему «осталась 1 секунда» длится так долго?

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

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

Спидтест показывает сотни Мбит/с, так почему ввод в RDP медленный?

То, как быстро передаётся большой объём данных, и то, сколько времени занимает возврат результата действия, — разные вещи. Здесь участвуют и отправка ввода, и обработка приложения на хосте, и сжатие экрана, и передача, и показ на вашей машине. Сервер спидтеста и хост RDP к тому же достигаются по разным сетевым маршрутам.

Печатать можно нормально, а дёргается только прокрутка. Это проблема сети?

Свести всё только к сети нельзя. Когда обновлений экрана становится больше, отставать могут отрисовка и сжатие на хосте, передача либо декодирование и показ на вашей машине. Меняйте разрешение на удалённой стороне и число мониторов по одному и сравнивайте, а при необходимости смотрите счётчики графики.

Если ping быстрый, значит ли это, что связь в RDP в порядке?

Одного этого недостаточно. ping измеряет отклик на ICMP и не измеряет ни передачу экрана в RDP, ни обработку в приложении. В конфигурациях с RD Gateway и подобными маршрут может вообще не совпадать. Если ответа нет, различайте блокировку ICMP и недоступность самого RDP.

User Input Delay — это время от нажатия клавиши до появления символа?

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

Стоит ли отключать UDP, если RDP работает медленно?

Как общую рекомендацию — нет. Сначала проверьте фактически используемый транспорт, маршрут и применённые политики. UDP может быть недоступен, и соединение уже перешло на TCP, поэтому переход только на TCP не всегда ускоряет работу. Сравнивайте в одинаковых условиях с разрешения администратора и возвращайте изменения, которые оказались ненужными.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.