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

Тест скорости показывает сотни Мбит/с, а в удалённом рабочем столе символы появляются с небольшой задержкой. При прокрутке страницы с множеством фотографий изображение подтормаживает. Бизнес-приложение замирает на несколько секунд только после нажатия кнопки поиска. С чего начинать диагностику такого состояния, когда «канал быстрый, а RDP тормозит»?

Отклик RDP на действия определяется не только скоростью передачи канала. Даже при хорошем результате теста скорости ожидание может возникнуть на любом из этапов: круговой обход сети, ожидание ввода в приложении на удалённом компьютере, кодирование изображения экрана либо декодирование и показ на локальном компьютере. Сначала определите, «какое именно действие медленное», и сравнивайте одно и то же действие, меняя условия по одному. Сравнения и измерения сужают область поиска, а настройки UDP и GPU выбирают по их результатам. См.: участки измерения качества подключения, факторы производительности узла сеансов.

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

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

Статья рассчитана в первую очередь на пользователей и администраторов, которые подключаются к Windows 11 или Windows Server через приложение Windows «Подключение к удаленному рабочему столу» (mstsc). Примеры команд предназначены для Windows PowerShell 5.1. Предполагается, что одно и то же действие можно воспроизвести в уже установленном сеансе.

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

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

Приведённые здесь способы проверки основаны на официальной документации. Это не отчёт об измерениях, в которых сбой был воспроизведён и устранён на конкретном устройстве. Числовые примеры явно обозначены как допущения для объяснения.

Механизм можно читать по порядку, начиная со следующего раздела «Скорость передачи и время кругового обхода». Если хотите начать с симптомов, переходите к разделу «Первое сравнение по симптомам». Порядок действий описан в разделах «Сравнение условий по одному» и «Измерение места ожидания».

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

Скорость передачи и время кругового обхода

RDP (Remote Desktop Protocol) — это протокол, по которому локальное устройство и удалённый компьютер обмениваются вводом, информацией об изображении экрана и другими данными. Он передаёт не только изображение и ввод, но и данные перенаправления устройств, печати и т. п. См.: какие данные передаёт RDP.

Скорость передачи канала показывает, сколько данных можно перенести за секунду. «500 Мбит/с» из теста скорости — это число, относящееся к этому объёму. Оно не показывает время от действия до получения ответа. См.: требования RDP к пропускной способности.

flowchart TB
    accTitle: Что означает результат теста скорости
    accDescr: Показывает, что 500 Мбит/с из теста скорости — это объём данных, переносимый за секунду, то есть число, отличное от времени от действия до получения ответа.
    A["Тест скорости: 500 Мбит/с"] --> B["Объём данных за секунду"]
    B -.->|"другое число"| C["Время до получения ответа"]

Рис. 1: Результат теста скорости выражает переносимый объём, а не время до получения ответа.

Время кругового обхода (RTT) — это время, за которое сообщение доходит до другой стороны и возвращается. Разница между повышением скорости передачи и сокращением времени кругового обхода похожа на разницу между добавлением полос на дороге и сокращением расстояния до места назначения. Даже если способность переносить большие объёмы файлов растёт, при неизменном времени кругового обхода ожидание ответа на действие остаётся. См.: RTT и задержка отображения экрана.

flowchart TB
    accTitle: Скорость передачи и время кругового обхода на примере дороги
    accDescr: Схема сравнивает повышение скорости передачи с добавлением полос на дороге, а сокращение времени кругового обхода — с сокращением расстояния до места назначения.
    A["Повысить скорость передачи"] -->|"на дороге"| B["Добавить полосы"]
    B ~~~ C["Сократить время обхода"]
    C -->|"на дороге"| D["Сократить расстояние"]

Рис. 2: Дополнительные полосы не сокращают расстояние до места назначения.

Возврат результата одного символа

Представим, что вы вводите один символ в удалённом «Блокноте». «Блокнот» работает на удалённом компьютере. Если для объяснения принять, что действие доходит за 50 миллисекунд, а информация об изображении с результатом возвращается ещё за 50 миллисекунд, на связь уходит в сумме 100 миллисекунд, то есть 0,1 секунды. Время обработки на обоих концах в этом примере не учитывается.

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

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

Даже если канал способен переносить больше данных, эти 0,1 секунды остаются, пока время кругового обхода не меняется. Рис. 3 — концептуальная схема для понимания обработки. Она не означает, что для каждой клавиши отправляется отдельный обмен пакетами туда и обратно. Маршрут до сервера теста скорости и до удалённого компьютера RDP тоже различается, и нужно учитывать VPN, шлюз, исходящий канал на стороне удалённого компьютера и перегрузку по пути. См.: как понимать RTT, производительность сети и хоста.

Формирование и доставка изображения экрана

Задержка отклика на действие здесь означает ожидание от действия на локальном компьютере до появления результата. В неё входит не только RTT, но и обработка в приложении, а также формирование и доставка изображения экрана. Её следует отличать и от задержки одного лишь участка передачи изображения. См.: участок измерения от захвата экрана до показа.

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

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

Рис. 4: Обработка и сжатие на удалённом компьютере, перенос по каналу и возврат к виду для показа на локальном. Всё это работа, выполняемая в разных местах.

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

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

Если сжатие на удалённом компьютере занимает много времени, отправка ждёт подготовки, даже когда канал свободен. Даже если информация уже пришла, обновление запаздывает, если локальное декодирование или показ не успевают. Не всегда верно, что «рабочий компьютер мощный, поэтому локальное устройство может быть любым». Запас канала и запас обработки на обоих его концах — разные вещи. См.: счётчики производительности обработки экрана.

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

Рис. 5: Даже при запасе канала обновление экрана запаздывает, если обработка на обоих концах не успевает.

Разница между вводом текста и прокруткой

Когда вы добавляете один символ в «Блокноте», меняется небольшая часть экрана. При прокрутке страницы с множеством фотографий изображение на большой площади меняется раз за разом. RDP сокращает объём передаваемых данных, передавая изменённые участки и применяя сжатие и кэширование под конкретное содержимое. Он не отправляет каждый раз весь экран без сжатия. Объём работы зависит от содержимого экрана и частоты обновлений. См.: связь содержимого экрана и пропускной способности.

flowchart TB
    accTitle: Объём работы с экраном при вводе и прокрутке
    accDescr: Небольшое изменение одного символа и непрерывное обновление большой площади различаются по характеру работы по формированию и отправке изображения экрана.
    A{"Изменение экрана"} -->|"добавить символ"| B["Малая область"]
    A -->|"прокрутка"| D["Большая область подряд"]
    B --> E["Сжатие и передача по изменениям"]
    D --> E

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

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

Ожидание в приложении

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

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

Рис. 7: Бизнес-приложение за RDP может в свою очередь ждать ответа другого сервера.

Если обработка, отвечающая за экран и ввод, занята долгой работой, следующий ввод и обновление экрана запаздывают. Например, в WPF длительная занятость UI-потока ухудшает отзывчивость. Одна лишь низкая загрузка CPU в целом не исключает ожидания конкретного UI-потока. См.: Dispatcher и UI-поток.

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

Рис. 8: Ожидание UI-потока нельзя исключить только по общей загрузке CPU.

Первое сравнение по симптомам

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

flowchart TB
    accTitle: Сначала разделить три вещи, затем исследовать
    accDescr: Показывает, что вместо сведения «RDP тормозит» к одной причине разделяют переносимый объём, время ожидания ответа и время формирования и показа изображения и начинают с действия, которое медленное сейчас.
    A["«RDP тормозит»"] --> S
    subgraph S["Смотреть по отдельности"]
    direction TB
    B["Переносимый объём"] ~~~ C["Время ожидания ответа"]
    C ~~~ D["Время формирования и показа"]
    end
    S --> E["Начать с медленного сейчас действия"]

Рис. 9: Если разделить переносимый объём, время ожидания ответа и время формирования и показа изображения, можно начать с действия, которое медленное сейчас.

Цель диагностики — ограничить место, где ищут причину медленной работы. Цель не в том, чтобы случайно ускорить работу массовым изменением настроек. Используя различия вроде «Блокнот работает, а замирает только поиск» или «ввод нормальный, а тормозит только прокрутка», можно выбрать отправную точку диагностики ещё до изменения сетевых настроек.

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

Символы запаздывают в нескольких приложениях

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

Дёргается только прокрутка

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

Зависает только одно приложение

Если останавливается только бизнес-приложение, в котором нажали поиск, проверьте, отвечает ли «Блокнот» или другое приложение в том же сеансе. Если другие приложения работают, сначала исследуйте обработку в этом приложении, диск и запросы к базе данных и общей папке. То, что вы работаете через RDP, и то, что связь RDP является причиной ожидания, — разные вещи. См.: факторы производительности приложений и серверной части.

Медленно у всех, когда пользователей больше

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

Замедление во время копирования или печати

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

Сравнение условий по одному

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

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

Сравнение одного и того же действия

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

1. Воспроизведите медленное действие с исходными настройками и запишите время и симптом.

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

2. Проверьте нагрузку на удалённом и локальном компьютерах в одно и то же время.

   В Диспетчере задач на удалённом компьютере смотрите CPU, память и диск нужного приложения, а на локальном — нагрузку клиента RDP. Проверяйте не только общее значение CPU, но и конкретный процесс. См.: что проверять при оценке нагрузки.

3. Измените только одно условие — другое устройство, другой разрешённый маршрут или условия отображения — и повторите то же действие.

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

4. Верните исходные условия и снова проверьте то же действие.

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

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

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

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

Сравнение разрешения на удалённой стороне

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

1. Измените что-то одно: число мониторов или разрешение.

   В mstsc сравнивать можно с помощью настроек на вкладке «Экран» до подключения или указав ширину и высоту. См.: параметры экрана в mstsc.

2. Убедитесь, что фактический размер рабочего стола удалённого компьютера изменился, и прокрутите ту же страницу.

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

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

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

Если стало лучше, подсказка находится в области обработки и передачи изображения экрана. В 3840×2160 в четыре раза больше пикселей, чем в 1920×1080, но объём передаваемых данных не всегда растёт в четыре раза. Он зависит от изменённых участков и сжатия, а изменение разрешения влияет и на обработку на обоих концах. См.: связь числа пикселей и объёма данных, проверка обработки экрана.

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

Рис. 11: Изменение разрешения — сравнение, которое затрагивает не только канал, но и обработку экрана на удалённом и локальном компьютерах.

Сопоставление копирования и печати с симптомами

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

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

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

2. Приостановите нужную передачу в разрешённых пределах и снова проверьте то же действие.

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

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

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

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

Измерение места ожидания

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

Проверка ICMP и TCP-подключения

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

1. Укажите разрешённый удалённый компьютер и запишите результаты ответа ICMP и TCP-подключения.

   $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
       
   

2. Сопоставьте результаты в период замедления и в обычное время со временем появления симптома и фактическим маршрутом подключения.

   20 запросов ping — это короткое наблюдение. Записывайте колебания значений и отсутствие ответов, учитывая, что ICMP может блокироваться. Не исключайте прерывистые остановки по одному лишь среднему значению, а используйте сведения о подключении и сетевые журналы администратора. См.: что измеряет ping.

TcpTestSucceeded: True означает, что TCP-подключение к указанному порту прошло успешно. Пропускная способность, UDP, работа после проверки подлинности и плавность изображения при этом не измеряются. У Test-NetConnection нет переключателя -UDP для проверки UDP. См.: синтаксис и результаты Test-NetConnection.

Оценивая результат, учитывайте различия маршрутов и служб. При RD Gateway и подобных маршрут ICMP или прямого TCP-подключения к хосту может не совпадать с фактическим маршрутом RDP. В Azure Virtual Desktop можно использовать RTT и оценку пропускной способности для каждого подключения, но эта диагностическая функция предназначена для данной службы. Короткие остановки не исключают по одному лишь среднему значению. См.: журналы качества подключения Azure Virtual Desktop.

flowchart TB
    accTitle: Проверенный маршрут и фактический маршрут RDP
    accDescr: В конфигурациях с RD Gateway и подобными маршрут ICMP или прямого TCP-подключения с локального устройства к хосту может не совпадать с фактическим маршрутом RDP.
    A["Локальное устройство"] -->|"ICMP, прямой TCP"| C["RDP-хост"]
    A -->|"фактический RDP"| B["RD Gateway и др."]
    B --> C

Рис. 13: ICMP и прямое TCP-подключение к хосту могут идти не тем маршрутом, что фактический RDP.

Измерение ожидания в очереди ввода

User Input Delay измеряет ожидание от попадания ввода в очередь на удалённом компьютере до момента, когда процесс его заберёт. Это не общее время от нажатия клавиши до появления символа. См.: определение User Input Delay.

Измерение выполняют в удалённом сеансе на удалённом компьютере. По условиям Microsoft нужны Windows 10 версии 1809 или новее либо Windows Server 2019 или новее. В этих системах добавлять параметр реестра для включения не требуется. Проверьте отображаемое имя, права и наличие счётчика, а если воспользоваться им нельзя, запишите этот факт и обратитесь к администратору. См.: условия поддержки и настройка.

1. В PowerShell в том же сеансе запишите время и идентификатор сеанса.

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

   Для просмотра сеансов других пользователей могут потребоваться дополнительные права. Стандартное имя экземпляра для исследуемого процесса — SessionID:ProcessID <Process Image>. Следите за тем, чтобы по одному лишь идентификатору сеанса не смешать значения других пользователей или одноимённых процессов. См.: права для query session, идентификация экземпляров.

2. В perfmon.exe добавьте доступный счётчик User Input Delay per Process или User Input Delay per Session.

   Выберите исследуемый процесс или сеанс и для начала наблюдайте с интервалом по умолчанию в 1 секунду. Различайте сводный экземпляр, объединяющий несколько сеансов, и значения отдельных сеансов.

3. Воспроизведите действие с медленным вводом и сравните ожидание в очереди со временем появления симптома.

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

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

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

Рис. 14: Измеряется ожидание в очереди ввода на удалённом компьютере. Это не общее время до появления результата на локальном компьютере.

Обновление экрана и причины пропуска кадров

Подготовьте действие с непрерывным обновлением экрана, например прокрутку. Доступность счётчиков RemoteFX Graphics и место измерения нужно проверить: они зависят от ОС, конфигурации хоста и прав. Здесь мы только читаем доступные счётчики. Это не процедура установки или включения старой функции RemoteFX. См.: условия применимости счётчиков Graphics.

1. С помощью query session или qwinsta определите имя исследуемого сеанса и выберите соответствующий экземпляр счётчика.

2. Во время действия с обновлением экрана сравните Input Frames/Second и Output Frames/Second.

   Если выходных кадров меньше, чем входных, часть кадров по пути пропускается. Проверьте значения Frames Skipped/Second в разбивке по нехватке ресурсов удалённого компьютера, сети и клиента.

3. Сопоставьте причины пропуска кадров с нагрузкой на обоих концах и на связь и проверьте также Average Encoding Time.

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

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

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

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

Концептуальные схемы передачи экрана и старую документацию не обобщают на все конфигурации. Есть конфигурации, где видео и звук передаются отдельным механизмом. В документации по счётчикам Graphics описаны и старые конфигурации, поэтому приведённые там числа не следует трактовать как общую спецификацию вида «у любого RDP максимум 30 fps». Перед использованием проверьте, к чему относятся функции и числа. См.: передача экрана и тип нагрузки, документация по счётчикам Graphics.

Область применения результатов измерений

Низкое значение не равнозначно комфортной работе. Область каждого показателя можно проверить в документации Microsoft, указанной в процедурах.

Настройки сети и GPU

Настройки UDP и GPU выбирают по тому, что показали сравнения и измерения. Если подозрение падает на связь, сначала проверьте способ подключения и маршрут, а если на обработку экрана — этап, на котором используется GPU.

Проверка TCP/UDP и маршрута подключения

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

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

   RDP использует TCP или UDP в зависимости от конфигурации и условий связи. В политике «Select RDP transport protocols» можно выбрать вариант с использованием UDP или TCP либо вариант только с TCP. Поскольку возможно и поведение, при котором используется TCP, если UDP-подключение не устанавливается, одно лишь успешное подключение не говорит о способе. См.: выбор транспорта RDP и откат.

2. Сопоставьте время симптома с маршрутом и способом подключения и сравнивайте по одной только нужные настройки.

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

Зная способ подключения и маршрут, можно записать связь между изменением и симптомом. Переход только на TCP не всегда даёт ускорение.

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

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

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

flowchart TB
    accTitle: Маршруты RDP Shortpath и откат
    accDescr: RDP Shortpath в Azure Virtual Desktop пытается установить UDP-маршрут; при успехе в зависимости от конфигурации использует прямой маршрут или ретранслятор, а при неудаче возвращается к подключению на основе TCP.
    A["RDP Shortpath"] --> B{"UDP-маршрут"}
    B -->|"установлен"| C["Напрямую или через ретранслятор"]
    B -->|"не установлен"| D["Возврат к TCP"]

Рис. 17: Если RDP Shortpath не может установить UDP-маршрут, он возвращается к подключению на основе TCP.

Проверка использования GPU для обработки экрана

Эту проверку выполняют, если сравнения и измерения указывают на обработку экрана. Проверьте результаты измерений обработки экрана, а также поддерживаемые ОС, драйверы, политики и клиенты. Настройки не меняют только потому, что в компьютере есть GPU. Сначала получите одобрение администратора и подготовьте возможность возврата.

1. Разделите отрисовку в приложении на удалённом компьютере, кодирование RDP и локальное декодирование и выберите подозрительный этап.

   Даже при наличии GPU не каждый этап обязательно его использует. И в документации Microsoft по конфигурации Azure Virtual Desktop отрисовка в удалённом сеансе и аппаратное кодирование кадров настраиваются и проверяются отдельно. См.: конфигурация и проверка GPU для отрисовки и кодирования.

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

   Если время сжатия большое, исследуйте использование GPU для кодирования. Менять настройки кодирования для приложения, которое ждёт в очереди ввода, значит воздействовать не на то место. Для читаемости текста и плавности видео по-разному выбирают и качество изображения, объём передаваемых данных и нагрузку на обработку. См.: различия в зависимости от типа нагрузки.

Так можно записать не просто наличие GPU, а то, используется ли он на проблемном этапе и как изменились нагрузка и отклик одного и того же действия. Изменения, не давшие улучшения, после согласования с администратором отменяют.

flowchart TB
    accTitle: Проверка использования GPU по этапам
    accDescr: Разделяют отрисовку в приложении на удалённом компьютере, кодирование RDP и локальное декодирование и, поскольку даже при наличии GPU не каждый этап его использует, проверяют использование на подозрительном этапе.
    A["Отрисовка в приложении на хосте"] --> B["Кодирование RDP"]
    B --> C["Локальное декодирование"]
    C -.- D["Использование GPU по этапам"]

Рис. 18: Даже при наличии GPU отрисовка, кодирование и декодирование не обязательно все его используют.

Повторная проверка и передача

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

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

Рис. 19: Помимо результата того же действия сверяют нужные функции и результат после возврата.

Передача нерешённой проблемы

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

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

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

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

Разработчик приложения записывает отдельно приём события ввода, начало и окончание операций с базой данных и файлами и отражение изменений в UI. Он также рассматривает архитектуру, в которой тяжёлая работа не задерживается в UI-потоке. Однако журнал завершения обработки на удалённом компьютере не фиксирует завершение показа на локальном компьютере. См.: разделение обработки для сохранения отзывчивости UI.

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

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

Справочные материалы

Ниже приведены первоисточники Microsoft Learn. Содержание, на которое мы ссылаемся, проверено 17 сентября 2026 г. При чтении различайте условия применимости для каждого продукта и учитывайте, что это не измерения, выполненные для этой статьи.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Различие между RTT и задержкой от захвата экрана на удалённом компьютере до показа на локальном. Сама диагностическая функция предназначена для Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Зависимость объёма передаваемых данных от содержимого экрана, разрешения, обновления кадров, сжатия и кэширования.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Способ проверки входных и выходных кадров, причин пропуска кадров и времени кодирования. Документ включает описание старых конфигураций, поэтому численные пределы не обобщаются на любой RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Нагрузка на общий хост, связь удалённого компьютера с серверной частью и влияние перенаправления устройств.
• Microsoft Learn, Threading model. UI-поток и Dispatcher в WPF, разделение обработки для сохранения отзывчивости.
• Microsoft Learn, mstsc. Задание ширины и высоты удалённого рабочего стола и нескольких мониторов.
• Microsoft Learn, Supported RDP properties. Различие между разрешением рабочего стола, динамическим разрешением и smart sizing. Проверяйте поддерживаемые клиенты и условия применимости для каждого продукта.
• Microsoft Learn, ping. Проверка ответа с помощью ICMP Echo и параметры команды.
• Microsoft Learn, Test-NetConnection. Проверка TCP-подключения и значение вывода.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Участок измерения User Input Delay, поддерживаемые ОС, экземпляры и смысл максимального значения.
• Microsoft Learn, query session. Сведения о сеансах и права, необходимые для просмотра других сеансов.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Выбор TCP или UDP, используемого RDP, и откат.
• Microsoft Learn, RDP Shortpath. UDP-маршрут для Azure Virtual Desktop и поведение, когда его не удаётся установить.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Конфигурация и проверка GPU отдельно для отрисовки и кодирования кадров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нужно ли отключать UDP, если RDP тормозит?

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

Об авторе

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

Го Комура

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

Работает в основном с разработкой ПО для Windows, техническими консультациями и поиском причин неисправностей; сильные стороны — проекты, где остаются существующие активы, и расследование сбоев, причину которых трудно увидеть.