Чому 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 має в 4 рази більше пікселів, ніж 1920×1080, але обсяг трафіку не завжди зростає в 4 рази. Він залежить від змінених ділянок і стиснення, а зміна роздільної здатності впливає й на обробку на обох боках. Див.: кількість пікселів і обсяг трафіку, перевірка обробки екрана.

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. Розглядається лише конфігурація з прямим підключенням до RDP-хоста, який використовує стандартний TCP 3389, через корпоративну локальну мережу або дозволений VPN. Для конфігурацій через 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. Якщо UDP-з’єднання не встановлюється, може використовуватися TCP, тому за самим лише успішним підключенням спосіб не визначити. Див.: вибір RDP transport і перехід на резервний варіант.

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: Якщо UDP-маршрут встановити не вдається, RDP Shortpath повертається до підключення на основі TCP.

Перевірка використання GPU для обробки екрана

Цю перевірку проводять, коли порівняння й вимірювання вказують на обробку екрана. Перевіряють результати вимірювання обробки екрана, а також підтримувані ОС, драйвери, політики й клієнт. Сама лише наявність GPU не є підставою змінювати налаштування. Спочатку отримують згоду адміністратора й готують спосіб повернути початковий стан.

1. Розділіть відмальовування застосунку на віддаленому комп’ютері, кодування RDP і декодування на вашому боці та виберіть етап, який викликає підозру.

   Навіть якщо GPU є, не всі етапи обов’язково його використовують. У матеріалах Microsoft щодо конфігурації Azure Virtual Desktop відмальовування у віддаленому сеансі й апаратне кодування кадрів також налаштовують і перевіряють окремо. Див.: конфігурація й перевірка GPU для відмальовування і кодування.

2. Перевірте фактичне використання за інструкціями потрібного продукту й вимірюйте ту саму дію до і після потрібної зміни.

   Якщо час стиснення тривалий, дослідіть використання GPU для кодування. Якщо застосунок чекає в черзі введення, зміна налаштувань кодування спрямована не туди. Для читабельності тексту і плавності відео баланс між якістю зображення, обсягом трафіку й навантаженням на обробку також вибирають по-різному. Див.: відмінності залежно від типу навантаження.

Можна записати не лише наявність 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, технічними консультаціями та розслідуванням дефектів. Особливо сильна сторона — проєкти з наявними активами та розслідування збоїв з неочевидною причиною.