Proč je RDP pomalé, i když je připojení rychlé? – zkoumejte zvlášť vstup, vykreslování a komunikaci

Test rychlosti ukazuje stovky Mb/s, a přesto se ve vzdálené ploše znaky objevují s mírným zpožděním. Při posouvání stránky s mnoha fotografiemi obraz zadrhává. Jen po stisknutí hledání v podnikové aplikaci se vše na několik sekund zastaví. Kde začít zkoumat takový stav, kdy „je připojení rychlé, ale RDP pomalé“?

Reakci RDP na vaše akce neurčuje jen přenosová rychlost připojení. I když test rychlosti vychází dobře, může se čekat na komunikaci tam a zpět, na to, až aplikace na vzdáleném počítači převezme vstup, na kódování obrazu nebo na dekódování a zobrazení na místním počítači. Nejprve rozlište, „která operace je pomalá“, a stejnou operaci porovnávejte vždy se změnou jediné podmínky. Porovnáním a měřením zúžíte oblast šetření a nastavení UDP nebo GPU zvolíte podle výsledku. Viz: Měřené úseky kvality připojení, Faktory výkonu hostitele relací.

Ve fázi, kdy jste oblast šetření teprve zúžili, však kořenová příčina ještě není potvrzená. Pokud se situace po snížení rozlišení zlepší, mění se nejen komunikace, ale i zpracování obrazu na obou koncích, a proto netvrdíme, že „příčinou bylo připojení“. Výsledky zaznamenáváme odděleně pro úseky, které jsme změřili, a pro ty, které změřené nejsou.

Tento článek se věnuje rozlišování problémů se vstupem, posouváním a reakcemi aplikací po navázání připojení. I při podobných příznacích nemusí být příčina jen jedna. Případy typu „trvá dlouho, než se zobrazí přihlašovací obrazovka“ nebo „zastaví se to jen při ověřování“ považujeme za jiný problém, který se zkoumá ze záznamů o navázání připojení a ověřování.

Článek je určen hlavně uživatelům a správcům, kteří se z aplikace Windows „Připojení ke vzdálené ploše“ (mstsc) připojují k Windows 11 nebo Windows Serveru. Příklady příkazů jsou určené pro Windows PowerShell 5.1. Předpokládáme, že stejnou operaci lze zopakovat v již připojené relaci.

Přímé připojení, VPN, RD Gateway a Azure Virtual Desktop se liší cestou, dostupnými diagnostickými informacemi i tím, kde se nastavení uplatní. Příklad kontroly TCP 3389 platí jen pro povolené přímé připojení k hostiteli RDP, který používá standardní port. Diagnostické funkce a nastavení GPU z dokumentace pro Azure Virtual Desktop nepřenášíme beze změny na běžné firemní počítače.

Na firemních zařízeních zkoumáme jen v rozsahu, který povolil správce. Na sdíleném hostiteli rozlište svou relaci a cílový proces, a pokud potřebujete záznamy jiných uživatelů, požádejte o ně správce. Dostupnost čítačů výkonu, jejich zobrazované názvy a potřebná oprávnění ověřujeme v každém prostředí zvlášť.

Zde uvedené způsoby kontroly vycházejí z oficiální dokumentace. Nejde o zprávu o měření, při kterém by se porucha na konkrétním zařízení reprodukovala a odstranila. Číselné příklady uvádíme zřetelně odlišené jako předpoklady pro účely výkladu.

Princip si můžete projít postupně, počínaje následující částí „Přenosová rychlost a doba přenosu tam a zpět“. Pokud chcete začít od příznaků, přejděte na část „První porovnání podle příznaku“. Postupy najdete v částech „Porovnání po jedné podmínce“ a „Měření, kde se čeká“.

Na diagramu plná čára označuje vztah, který platí vždy, a přerušovaná čára vztah podmíněný (podmínky jsou uvedeny u jednotlivých vztahů na podrobné stránce). Úplný seznam vztahů (celkem 7, s doklady a mírou jistoty) a definice hlavních pojmů najdete na podrobné stránce znalostní mapy (v japonštině). Data: JSON-LD / Turtle

Přenosová rychlost a doba přenosu tam a zpět

RDP (Remote Desktop Protocol) je protokol, kterým si místní zařízení a vzdálený počítač vyměňují vstup, obrazová data a další informace. Kromě obrazu a vstupu přenáší i data pro přesměrování zařízení, tisk a podobně. Viz: Jaká data RDP přenáší.

Přenosová rychlost připojení vyjadřuje, kolik dat lze přenést za sekundu. Hodnota „500 Mb/s“ z testu rychlosti se týká právě tohoto množství. Neudává, jak dlouho po akci trvá, než dorazí odpověď. Viz: Požadavky RDP na šířku pásma.

flowchart TB
    accTitle: Co vyjadřuje číslo z testu rychlosti
    accDescr: Ukazuje, že 500 Mb/s z testu rychlosti je číslo vyjadřující množství dat přenesených za sekundu a že jde o jiné číslo než doba od akce do příchodu odpovědi.
    A["Test rychlosti: 500 Mb/s"] --> B["Data přenesená za 1 s"]
    B -.->|"Jiné číslo"| C["Doba do příchodu odpovědi"]

Obrázek 1: Číslo z testu rychlosti vyjadřuje přenesitelné množství, nikoli dobu do příchodu odpovědi.

Doba přenosu tam a zpět (RTT) je čas, za který komunikace dorazí k protější straně a vrátí se zpět. Rozdíl mezi zvýšením přenosové rychlosti a zkrácením doby přenosu tam a zpět připomíná rozdíl mezi přidáním jízdních pruhů na silnici a zkrácením vzdálenosti do cíle. I když vzroste schopnost přenášet velké množství souborů, čekání na odpověď na akci zůstane, pokud se doba přenosu tam a zpět nezmění. Viz: RTT a zpoždění zobrazení obrazovky.

flowchart TB
    accTitle: Přenosová rychlost a doba tam a zpět jako silnice
    accDescr: Diagram přirovnává zvýšení přenosové rychlosti k přidání jízdních pruhů na silnici a zkrácení doby přenosu tam a zpět ke zkrácení vzdálenosti do cíle.
    A["Zvýšit přenosovou rychlost"] -->|"Na silnici"| B["Přidat jízdní pruhy"]
    B ~~~ C["Zkrátit dobu tam a zpět"]
    C -->|"Na silnici"| D["Zkrátit vzdálenost"]

Obrázek 2: Přidáním jízdních pruhů se vzdálenost do cíle nezkrátí.

Než se vrátí výsledek jednoho znaku

Uvažujme situaci, kdy do vzdáleného Poznámkového bloku napíšete jeden znak. Poznámkový blok běží na vzdáleném počítači. Pokud pro účely výkladu předpokládáme, že akce dorazí za 50 milisekund a obrazová data s výsledkem se vrátí za 50 milisekund, zabere komunikace celkem 100 milisekund, tedy 0,1 sekundy. Dobu zpracování na obou koncích jsme z tohoto příkladu vynechali.

flowchart TB
    accTitle: Příklad doby komunikace, než se vrátí výsledek jednoho znaku
    accDescr: Příklad pro účely výkladu, který předpokládá 50 milisekund tam a 50 milisekund zpět. Nezahrnuje dobu zpracování na obou koncích a nevyjadřuje ani počet paketů na jednu klávesu.
    A["Zadání znaku na místním PC"] -->|"Tam: 50 ms"| B["Vzdálený PC přijme vstup"]
    B --> C["Odeslání obrazu se vstupem"]
    C -->|"Zpět: 50 ms"| D["Výsledek dorazí na místní PC"]

Obrázek 3: Při předpokladu 50 ms tam a 50 ms zpět zabere jen komunikace 0,1 sekundy. Nejde o naměřené hodnoty.

I když vzroste množství dat, které připojení dokáže přenést, těchto 0,1 sekundy zůstane, pokud se nezmění doba přenosu tam a zpět. Obrázek 3 je koncepční schéma, které pomáhá pochopit zpracování. Neznamená, že se pro každou klávesu posílá samostatný paket tam a zpět. Cesta k serveru testu rychlosti a k cílovému počítači RDP se také liší, a proto počítáme i s VPN, bránou, odchozím pásmem na straně vzdáleného počítače a zahlcením po cestě. Viz: Jak chápat RTT, Výkon sítě a hostitele.

Vytvoření a doručení obrazu

Zpožděnou reakcí na akce zde rozumíme čekání od akce na místním počítači do chvíle, kdy uvidíte výsledek. Podílí se na ní nejen RTT, ale i zpracování v aplikaci a vytvoření a doručení obrazu. Odlišujeme ji také od zpoždění samotného úseku přenosu obrazu. Viz: Měřený úsek od zachycení obrazovky po zobrazení.

Když vstup dorazí z místního počítače na vzdálený, aplikace na vzdáleném počítači ho zpracuje a aktualizuje obrazovku, zakódovaná obrazová data se přenesou po připojení a místní počítač je dekóduje a zobrazí. Před komunikací i po ní tedy probíhá práce, kterou mají na starosti různé počítače. Viz: Zpracování od zachycení obrazovky po zobrazení.

flowchart TB
    accTitle: Zpracování obrazu před přenosem i po něm
    accDescr: Průběh od chvíle, kdy vstup z místního počítače dorazí na vzdálený počítač, přes zpracování v aplikaci, vytvoření a kompresi obrazu, až po převedení přenesených obrazových dat na místním počítači do zobrazitelné podoby a jejich zobrazení.
    I["Místní PC: zadání akce"] --> J["Připojení: přenos vstupu"]
    J --> K["Vzdálený PC: zpracování v aplikaci"]
    K --> A["Vzdálený PC: tvorba a komprese obrazu"]
    A --> B["Připojení: přenos obrazu"]
    B --> C["Místní PC: převod k zobrazení"]
    C --> D["Zobrazení na místním PC"]

Obrázek 4: Zpracování a komprese na vzdáleném počítači, přenos po připojení a převod k zobrazení na místním počítači. Každou z těchto prací vykonává jiné místo.

Kódováním v tomto článku rozumíme zpracování, při kterém vzdálený počítač převede a zkomprimuje obraz do podoby vhodné k odeslání. Kromě přenosu po připojení zabírá i čas zpracování na vzdáleném počítači. Viz: Doba kódování na vzdáleném počítači.

Dekódováním v tomto článku rozumíme zpracování, při kterém místní počítač převede doručená obrazová data zpět do zobrazitelné podoby. Odlišujeme ho od dešifrování ve smyslu zrušení šifrování. Viz: Dekódování a doba zobrazení na místním počítači.

Pokud komprese na vzdáleném počítači trvá dlouho, čeká se na připravení odeslání, i když je připojení volné. I když data dorazí, aktualizace se zpozdí, pokud místní dekódování nebo zobrazení nestíhá. Neplatí vždy, že „když je firemní počítač výkonný, na místním zařízení nezáleží“. Rezerva připojení a rezerva zpracování na jeho obou koncích jsou dvě různé věci. Viz: Čítače výkonu zpracování obrazu.

flowchart TB
    accTitle: Zpoždění, když zpracování na obou koncích nestíhá
    accDescr: Ukazuje, že když komprese na vzdáleném počítači trvá dlouho, čeká se na připravení odeslání i při volném připojení, a když místní dekódování nebo zobrazení nestíhá, aktualizace se zpozdí, i když data dorazila.
    A["Komprese na vzdáleném PC trvá"] --> B["Odeslání čeká i při volné lince"]
    B ~~~ C["Místní dekódování nestíhá"]
    C --> D["Aktualizace se zpozdí i po doručení"]

Obrázek 5: I když má připojení rezervu, aktualizace obrazovky se zpozdí, pokud zpracování na obou koncích nestíhá.

Rozdíl mezi psaním a posouváním

Když do Poznámkového bloku přidáte jeden znak, změní se jen malá část obrazovky. Při posouvání stránky s mnoha fotografiemi se jedna za druhou mění velké plochy zobrazení. RDP omezuje objem komunikace přenosem změněných částí a kompresí a ukládáním do mezipaměti přizpůsobenými obsahu. Neposílá pokaždé celou obrazovku bez komprese. Množství práce se mění podle obsahu obrazovky a četnosti aktualizací. Viz: Vztah mezi obsahem obrazovky a šířkou pásma.

flowchart TB
    accTitle: Práce s obrazem při psaní a posouvání
    accDescr: Malá změna znaku a souvislé aktualizace velké plochy se liší povahou práce při vytváření a odesílání obrazu.
    A{"Změna obrazovky"} -->|"Přidání znaku"| B["Malá oblast"]
    A -->|"Posouvání"| D["Souvislá velká plocha"]
    B --> E["Komprese a přenos podle změny"]
    D --> E

Obrázek 6: I v rámci stejného připojení se množství práce liší mezi přidáním jednoho znaku a situací, kdy se neustále pohybuje velká plocha.

Statický dokument může být nenáročný, ale při posouvání může přenosu obrazovky dojít rezerva. Když na vzdálené straně zvýšíte rozlišení nebo počet monitorů, zvětší se i zpracovávaná obrazovka. Porovnání se sníženým rozlišením je experiment, který ukáže, zda se plynulost vrátí, když ubude práce s vytvářením a odesíláním obrazu. Nejde o výpočet, který by objem komunikace určil jen z počtu pixelů. Viz: Vliv rozlišení, aktualizací obrazovky a komprese.

Čekání v aplikaci

Pokud se na několik sekund zastaví jen hledání v podnikové aplikaci, ale do Poznámkového bloku ve stejné relaci lze psát normálně, ověříme, na co tato aplikace čeká. Aplikace na vzdáleném počítači může posílat dotaz do další databáze nebo číst soubor ze sdílené složky a čekat na odpověď. To je jiná cesta než komunikace RDP mezi místním a vzdáleným počítačem. Viz: Komunikace ze vzdáleného počítače do back-endu.

flowchart TB
    accTitle: I za RDP jsou další protějšky komunikace
    accDescr: Ukazuje, že kromě komunikace mezi místním zařízením a vzdáleným počítačem může aplikace na vzdáleném počítači čekat na odpověď podnikového serveru.
    A["Místní zařízení"] -->|"RDP"| B["Podniková aplikace na vzdáleném PC"]
    B -->|"Hledání, požadavek na soubor"| C["DB, sdílená složka"]
    C -->|"Očekávaná odpověď"| B

Obrázek 7: Podniková aplikace za RDP může čekat na odpověď ještě dalšího serveru.

Když zpracování, které má na starosti obrazovku a vstup, dostane dlouhou úlohu, další vstup a aktualizace obrazovky se zpozdí. Například ve WPF se schopnost reagovat zhorší, když je vlákno UI dlouho obsazené. Samotné nízké celkové využití CPU nevylučuje čekání konkrétního vlákna UI. Viz: Dispatcher a vlákno UI.

flowchart TB
    accTitle: Zpracování obrazovky a vstupu se zahltí
    accDescr: Ukazuje, že když zpracování, které má na starosti obrazovku a vstup, dostane dlouhou úlohu, další vstup a aktualizace obrazovky se zpozdí, a nízké celkové využití CPU samo toto čekání nevylučuje.
    A["Zpracování obrazovky a vstupu"] --> B["Dostane dlouhou úlohu"]
    B --> C["Další vstup a překreslení se zpozdí"]
    C -.- D["Nízké celkové CPU to nevylučuje"]

Obrázek 8: Čekání vlákna UI nelze vyloučit jen podle celkového využití CPU.

První porovnání podle příznaku

Přenesitelné množství dat, doba čekání na odpověď a doba vytvoření a zobrazení obrazu jsou tři různé věci. Pokud je budete rozlišovat, nepřipíšete „pomalé RDP“ jediné příčině a můžete zkoumat od operace, která je pomalá právě teď.

flowchart TB
    accTitle: Nejprve oddělit tři věci, pak zkoumat
    accDescr: Ukazuje, že „pomalé RDP“ nepřipisujeme jediné příčině, ale oddělíme přenesitelné množství, dobu čekání na odpověď a dobu vytvoření a zobrazení obrazu a zkoumáme od operace, která je pomalá právě teď.
    A["„Pomalé RDP“"] --> S
    subgraph S["Sledovat zvlášť"]
    direction TB
    B["Přenesitelné množství"] ~~~ C["Doba čekání na odpověď"]
    C ~~~ D["Doba tvorby a zobrazení obrazu"]
    end
    S --> E["Zkoumat od právě pomalé operace"]

Obrázek 9: Když oddělíte přenesitelné množství, dobu čekání na odpověď a dobu vytvoření a zobrazení obrazu, můžete zkoumat od operace, která je pomalá právě teď.

Cílem rozlišování je omezit místa, kde se pomalost zkoumá. Cílem není hromadně změnit nastavení a náhodou dosáhnout zrychlení. Když využijete rozdíly jako „Poznámkový blok funguje, ale zastavuje se jen hledání“ nebo „psaní je normální, ale pomalé je jen posouvání“, můžete vstupní bod šetření zvolit ještě před změnou síťových nastavení.

Následující tabulka je výchozím bodem šetření. Není to tabulka, podle které se určuje příčina. Nejprve porovnáte operace ve stejné relaci a teprve pak měníte potřebné zařízení, cestu nebo podmínky zobrazení.

Znaky se zpožďují ve více aplikacích

Pokud se znaky po jednom zpožďují ve více aplikacích ve stejné relaci, porovnáme stejnou operaci i z jiného zařízení nebo po jiné povolené cestě. Dobu přenosu tam a zpět, čekání na vstup na vzdáleném počítači a zátěž celého vzdáleného počítače posuzujeme společně a příčinu neurčujeme podle jediného čísla.

Trhá se jen posouvání

I když je psaní normální, při posouvání stránky s mnoha fotografiemi probíhají nepřetržité aktualizace velké části obrazovky. Rozlišení nebo počet monitorů na vzdálené straně měníme po jednom a porovnáváme na stejné stránce. Pokud se situace zlepší, dalším předmětem šetření je komprese na vzdáleném počítači, přenos obrazovky a místní dekódování. Samotné rozlišení neprozradí, která z těchto tří věcí je příčinou. Viz: Zátěž podle obsahu obrazovky a rozlišení.

Zamrzá jen jedna aplikace

Pokud se zastaví jen podniková aplikace, ve které jste stiskli hledání, porovnáme, zda reaguje Poznámkový blok nebo jiná aplikace ve stejné relaci. Pokud jiné aplikace fungují, nejprve zkoumáme zpracování v cílové aplikaci, disk a požadavky do databáze nebo sdílené složky. To, že aplikaci ovládáte přes RDP, a to, že příčinou čekání je komunikace RDP, jsou dvě různé věci. Viz: Faktory výkonu aplikace a back-endu.

Zpomalení všech jen při nárůstu uživatelů

Pokud se ve stejné době zpomalí více uživatelů, ověříme u správce stav ostatních relací. Zátěž CPU, paměti a úložiště sdíleného hostitele a sdíleného připojení porovnáváme s časem výskytu příznaků. K záznamům a procesům ostatních uživatelů bez svolení nepřistupujeme a jejich úlohy nezastavujeme. Viz: Prostředky sdíleného hostitele a počet uživatelů.

Zpomalení během kopírování nebo tisku

Pokud se potíže časově kryjí se spuštěním vašeho kopírování nebo tisku, pozastavíme pro porovnání jen ty přenosy, jejichž zastavení je povolené. Zaznamenáme, zda se po pozastavení stav vrátí do normálu a zda se po obnovení opět zpomalí, a zkoumáme souběh s jinými přenosy než obrazovky a s přesměrováním zařízení. Porovnání, při kterém by se hromadně vypnula zařízení potřebná pro práci, neprovádíme. Viz: Vliv přesměrování zařízení.

Porovnání po jedné podmínce

Není nutné postupně měnit všechna nastavení. Nejprve vytvoříme základ pro porovnání a vybereme jen kontroly odpovídající příznaku. Před změnou nastavení nebo opětovným připojením uložte rozdělanou práci a zaznamenejte původní hodnoty a způsob, jak je vrátit. Pokud chybí potřebná oprávnění nebo funkce, nezapínáme je násilím a předáme věc správci.

Místní ovládání a ovládání přes RDP nemusí probíhat za stejných podmínek. To, že je vzdálený počítač rychlý přímo na své fyzické obrazovce, je užitečné vodítko, ale relace a podmínky vykreslování se mohou lišit. Sjednoťte uživatele, data a stav aplikace a neomezujte příčinu na připojení jen proto, že „přímo na obrazovce je to rychlé“.

Porovnání stejné operace

Připravíte stejného uživatele, stejná data a stejnou operaci. Na sdíleném hostiteli si ověříte svou relaci a aplikace ani procesy ostatních uživatelů se nezastavují. I použití jiného zařízení nebo jiné cesty je omezeno na rozsah povolený správcem.

1. V původním nastavení zopakujete pomalou operaci a zaznamenáte čas a příznak.

   V Poznámkovém bloku ve stejné vzdálené relaci jako problémová aplikace napíšete přibližně stejné množství textu. Rozlišíte tak, zda jde jen o jednu aplikaci, nebo o celou relaci.

2. Ve stejném čase zkontrolujete zátěž vzdáleného a místního počítače.

   Ve Správci úloh sledujete na vzdáleném počítači CPU, paměť a disk cílové aplikace a na místním počítači zátěž klienta RDP. Nekontrolujete jen celkovou hodnotu CPU, ale i cílový proces. Viz: Co sledovat při zkoumání zátěže.

3. Změníte jen jednu z těchto podmínek: jiné zařízení, jinou povolenou cestu, nebo podmínky zobrazení, a stejnou operaci zopakujete.

   Pokud se při porovnání současně změní i stav vzdáleného počítače nebo aplikace, zaznamenáte i tento rozdíl. Výsledek, při kterém se změnilo více podmínek, nepovažujeme za účinek jediné podmínky.

4. Vrátíte původní podmínky a stejnou operaci znovu ověříte.

   Pokud zůstane rychlost zachována i po vrácení, může jít mimo jiné o dočasnou změnu zátěže. Neusuzujeme hned, že změna pomohla, a zaznamenáme podmínky, za kterých se příznak opakuje.

Máte pohromadě výsledky z původního stavu, po změně a po vrácení zpět a můžete porovnat, které podmínky odpovídají kterým příznakům. Podmínka, se kterou se situace zlepšila, je vodítkem pro šetření a sama o sobě kořenovou příčinu neprokazuje.

flowchart TB
    accTitle: Omezit podmínky měněné najednou
    accDescr: Postup, kdy určíme operaci, která se reprodukuje v původním stavu, změníme jen jednu podmínku, porovnáme a ověříme i výsledek po vrácení zpět.
    A["Stejná operace v původním nastavení"] --> B["Změnit jen jednu podmínku"]
    B --> C["Zopakovat stejnou operaci"]
    C --> D["Vrátit zpět a znovu ověřit"]
    D --> E["Zaznamenat podmínku zlepšení"]

Obrázek 10: Stejnou operaci opakujeme v původním stavu, po změně a po vrácení zpět a zaznamenáme podmínku, která se změnila.

Porovnání rozlišení na vzdálené straně

Toto porovnání použijete, když jsou náročné aktualizace obrazovky, například při posouvání. Zaznamenáte rozlišení a počet monitorů před změnou, uložíte práci a pak se znovu připojíte. Nastavení, které zhoršuje obrazovku potřebnou pro práci nebo čitelnost textu, se nepoužívá natrvalo.

1. Změníte jen jedno z dvojice: počet monitorů, nebo rozlišení.

   V mstsc můžete porovnávat pomocí nastavení na kartě „Zobrazení“ před připojením nebo zadáním šířky a výšky. Viz: Zadání obrazovky v mstsc.

2. Ověříte, že se skutečná velikost plochy vzdáleného počítače změnila, a posouváte stejnou stránku.

   Pokud jen zmenšíte okno na místním počítači, může se velká plocha pouze zobrazovat zmenšeně. Rozlišujete dynamické rozlišení a smart sizing a ověříte, za jakých podmínek je používaný klient podporuje. Viz: Rozlišení plochy a měřítko zobrazení.

3. Vrátíte původní nastavení, zopakujete stejnou operaci a porovnáte zátěž na obou koncích a pohyb obrazu.

   Pokud jste najednou snížili rozlišení i přešli na jeden monitor, jde jen o hrubé porovnání. Pokud se situace zlepší, vracejte změny po jedné a jejich vliv oddělte.

Pokud se situace zlepší, vodítko leží v oblasti zpracování a přenosu obrazovky. 3840×2160 má čtyřnásobek pixelů oproti 1920×1080, objem komunikace však nemusí být vždy čtyřnásobný. Mění se podle změněných částí a komprese a změna rozlišení ovlivňuje i zpracování na obou koncích. Viz: Vztah mezi počtem pixelů a objemem komunikace, Kontrola zpracování obrazu.

flowchart TB
    accTitle: Co ukáže porovnání se sníženým rozlišením
    accDescr: Snížení rozlišení na vzdálené straně může změnit zátěž zpracování obrazu i přenosu, a proto samotné zlepšení neumožňuje omezit příčinu na připojení.
    A["Snížit rozlišení na vzdálené straně"] --> S
    subgraph S["Mění se zpracování"]
    direction TB
    B["Zpracování obrazu na vzdáleném PC"] ~~~ C["Množství odesílaných dat"]
    C ~~~ D["Zobrazení na místním PC"]
    end

Obrázek 11: Změna rozlišení je porovnání, které ovlivňuje nejen připojení, ale i zpracování obrazu na vzdáleném a místním počítači.

Porovnání kopírování a tisku s příznaky

Pozastavujeme jen procesy, jejichž zastavení je povolené, například přenosy, které jste sami spustili. Firemní zálohování, bezpečnostní procesy ani úlohy ostatních uživatelů nezastavujeme. Přesměrování zvukových a vstupních zařízení potřebných pro práci hromadně nevypínáme.

1. Před spuštěním a během kopírování, synchronizace s cloudem nebo tisku zaznamenáte stejnou operaci a zátěž.

   Přes RDP proudí kromě obrazovky i data jednotek, tiskáren a podobně. Přesměrování, které umožňuje používat místní zařízení na vzdáleném počítači, může během používání zvýšit zátěž komunikace a zpracování. Viz: Vliv přesměrování zařízení.

2. Cílový přenos v povoleném rozsahu pozastavíte a stejnou operaci znovu ověříte.

   Pokud lze přenos obnovit a porovnat, zaznamenáte i příznaky po obnovení. I když zkoušíte změny nepotřebného přesměrování zařízení, měníte je po jednom a tak, aby šlo vrátit původní nastavení.

Můžete posoudit, zda si odpovídá spuštění přenosu a potíže a pozastavení a zotavení. Pokud se souvislost ukáže, porovnáme přenosy mimo obrazovku a zátěž sdílených prostředků se záznamy správce.

flowchart TB
    accTitle: Stav před potížemi a po nich na stejné časové ose
    accDescr: Před přenosem, během něj a po jeho zastavení zaznamenáme stejnou operaci a zátěž a porovnáme vztah mezi potížemi a prací.
    A["Operace a zátěž před přenosem"] --> B["Operace a zátěž během přenosu"]
    B --> C["Operace a zátěž po zastavení"]
    C --> D["Odpovídají si potíže a zotavení?"]

Obrázek 12: Sledujeme, jak se před přenosem, během něj a po zastavení mění pomalost stejné operace a zátěž.

Měření, kde se čeká

Z místního počítače zkoumáme komunikaci tam a zpět a připojení TCP, na vzdáleném počítači čekání ve vstupní frontě a aktualizace obrazovky. Každé číslo měří jen omezený úsek, a proto výsledky čteme ve srovnání s tabulkou v části „Rozsah platnosti výsledků měření“.

Kontrola ICMP a připojení TCP

Spouští se na místním zařízení s Windows. Týká se jen konfigurace, kdy se ve firemní síti LAN nebo přes povolenou VPN připojujete přímo k hostiteli RDP se standardním TCP 3389. U konfigurací přes RD Gateway či Azure Virtual Desktop nebo s vlastním portem určete cíl kontroly společně se správcem. Porty nezveřejňujeme a bránu firewall neměníme.

1. Zadáte povolený cílový počítač a zaznamenáte výsledky odpovědi ICMP a připojení TCP.

   $target = Read-Host 'Název nebo IP adresa hostitele RDP, jehož zkoumání je povoleno'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Zadejte cílový počítač.'
   }
       
   # Dobu odpovědi ICMP sledujeme vícekrát. Samotné selhání neznamená, že RDP nefunguje.
   ping.exe -n 20 $target
       
   # Kontrola jen pro konfiguraci s přímým připojením na standardní TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Výsledky z doby zpomalení a z běžné doby porovnáte s časem výskytu příznaků a se skutečnou cestou připojení.

   20 pokusů ping je jen krátké pozorování. Kolísání hodnot a chybějící odpovědi zaznamenáte, ICMP však může být blokované. Občasné výpadky nevylučujete jen podle průměrné hodnoty a použijete informace o připojení nebo záznamy komunikace od správce. Viz: Co ping měří.

TcpTestSucceeded: True znamená, že se podařilo navázat připojení TCP k zadanému portu. Šířku pásma, UDP, operace po ověření ani plynulost obrazu neměří. Test-NetConnection nemá přepínač -UDP, kterým by se zkoumalo UDP. Viz: Syntaxe a výsledky Test-NetConnection.

Při posuzování zohledňujeme rozdíly v cestě a službě. U RD Gateway a podobně se cesta ICMP nebo přímého připojení TCP k hostiteli nemusí shodovat se skutečnou cestou RDP. V Azure Virtual Desktop jsou k dispozici RTT a odhad šířky pásma pro jednotlivá připojení, tato diagnostická funkce je však určená pro tuto službu. Krátké výpadky nevylučujeme jen podle průměrné hodnoty. Viz: Protokoly kvality připojení v Azure Virtual Desktop.

flowchart TB
    accTitle: Ověřená cesta a skutečná cesta RDP
    accDescr: V konfiguracích s RD Gateway a podobně se cesta ICMP nebo přímého připojení TCP z místního počítače k hostiteli nemusí shodovat se skutečnou cestou RDP.
    A["Místní zařízení"] -->|"ICMP, přímé TCP"| C["Hostitel RDP"]
    A -->|"Skutečné RDP"| B["RD Gateway apod."]
    B --> C

Obrázek 13: Cesta ICMP nebo přímého připojení TCP k hostiteli se nemusí shodovat s cestou skutečného RDP.

Měření čekání ve vstupní frontě

User Input Delay měří čekání od chvíle, kdy se vstup na vzdáleném počítači zařadí do fronty, do chvíle, kdy si ho proces vyzvedne. Nejde o celkovou dobu od stisku klávesy do zobrazení znaku. Viz: Definice User Input Delay.

Zkoumá se uvnitř vzdálené relace na vzdáleném počítači. Podle Microsoftu jsou podporovány Windows 10 verze 1809 a novější a Windows Server 2019 a novější. Na těchto systémech není k zapnutí nutné přidávat položku do registru. Ověříte zobrazovaný název, oprávnění a přítomnost čítače, a pokud ho nelze použít, zaznamenáte tuto skutečnost a poradíte se se správcem. Viz: Podmínky podpory a nastavení.

1. V PowerShellu ve stejné relaci si poznamenáte čas a ID relace.

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

   K dotazování na relace ostatních uživatelů mohou být potřeba další oprávnění. Standardní název instance cílového procesu je SessionID:ProcessID <Process Image>. Dbáte na to, abyste jen podle ID relace nesmíchali hodnoty jiných uživatelů nebo procesů se stejným názvem. Viz: Oprávnění pro query session, Identifikace instance.

2. V perfmon.exe přidáte dostupný čítač User Input Delay per Process nebo User Input Delay per Session.

   Vyberete cílový proces nebo relaci a zpočátku sledujete ve výchozím intervalu 1 sekundy. Rozlišujte agregovanou instanci, která sdružuje více relací, a hodnoty jednotlivých relací.

3. Zopakujete operaci s pomalým vstupem a porovnáte čekání ve frontě s časem výskytu příznaku.

   U jednotlivých měřených objektů se sleduje nejdelší doba čekání v měřeném intervalu. I když je hodnota nízká, zpracování poté, co aplikace vstup vyzvedne, a zpoždění do návratu výsledku na místní počítač tím nemizí.

Můžete zjistit, zda se čeká ve vstupní frontě na vzdáleném počítači. Jde o jiný ukazatel než vnímaná doba, která zahrnuje komunikaci tam a zpět a zobrazení na místním počítači. Viz: Význam maximální hodnoty a měřeného intervalu.

flowchart TB
    accTitle: Úsek, který měří User Input Delay
    accDescr: Měřeným úsekem je doba od vstupní fronty na vzdáleném počítači do vyzvednutí aplikací; komunikace a zobrazení obrazovky před ním a po něm zahrnuty nejsou.
    A["Vstup dorazí z místního PC"] --> B["Zařazení do vstupní fronty"]
    B -->|"Měří se tento úsek"| C["Aplikace vyzvedne vstup"]
    C --> D["Zpracování v aplikaci a přenos obrazu"]
    D --> E["Zobrazení na místním PC"]

Obrázek 14: Měří se čekání ve vstupní frontě na vzdáleném počítači. To není totéž co celková doba, než uvidíte výsledek na místním počítači.

Aktualizace obrazovky a důvody vynechávání snímků

Připravíte operaci se souvislými aktualizacemi obrazovky, například posouvání. Dostupnost čítačů RemoteFX Graphics a místo měření je nutné ověřit podle OS, konfigurace hostitele a oprávnění. Zde dostupné čítače pouze čteme. Nejde o postup instalace nebo zapnutí staré funkce RemoteFX. Viz: Podmínky platnosti čítačů Graphics.

1. Pomocí query session nebo qwinsta zjistíte název cílové relace a vyberete odpovídající instanci čítače.

2. Během operace s aktualizacemi obrazovky porovnáte Input Frames/Second a Output Frames/Second.

   Pokud je výstupních snímků méně než vstupních, část snímků se cestou vynechává. Zkontrolujete hodnoty Frames Skipped/Second rozdělené podle nedostatku prostředků na vzdáleném počítači, v síti a na klientovi.

3. Důvody vynechávání porovnáte se zátěží obou konců a komunikace a zkontrolujete i Average Encoding Time.

   Pokud je doba kódování dlouhá, zkoumáte kompresi na vzdáleném počítači. Pokud je snímků málo už na vstupu, je také možné, že aplikace obrazovku často neaktualizuje. Nízký počet snímků při statické obrazovce sám o sobě není anomálie.

Ze vstupních a výstupních snímků během aktualizací obrazovky, z důvodů vynechávání a z doby kódování můžete zúžit oblast šetření. Rozdělení podle čítačů je vodítkem a posuzujeme ho spolu se skutečnou zátěží a konfigurací připojení. Viz: Jak číst počty snímků a dobu kódování.

flowchart TB
    accTitle: Zúžení oblasti šetření podle vynechávání snímků
    accDescr: Během operace s aktualizacemi obrazovky porovnáme počty vstupních a výstupních snímků a pomocí čítačů důvodů vynechávání je porovnáme se zátěží zpracování, komunikace a zobrazení.
    A["Porovnat vstup a výstup při posouvání"] --> B["Méně výstupu: ověřit vynechávání"]
    B --> C["Sledovat čítače podle důvodu"]
    C --> D["Porovnat se zátěží vzdáleného PC, sítě a místního PC"]

Obrázek 15: Porovnáme vstup a výstup během posouvání a důvody vynechávání porovnáme se zátěží vzdáleného počítače, připojení a místního počítače.

Koncepční schémata přenosu obrazovky ani starší dokumentaci nezobecňujeme na všechny konfigurace. Existují i konfigurace, které přenášejí video a zvuk jiným mechanismem. Dokumentace k čítačům Graphics popisuje i starší konfigurace, a proto uvedené hodnoty nevykládáme jako společnou specifikaci typu „každé RDP má maximálně 30 fps“. Funkce a hodnoty používáme až po ověření, na co se vztahují. Viz: Přenos obrazovky a typ zátěže, Dokumentace k čítačům Graphics.

Rozsah platnosti výsledků měření

Nízké číslo neztotožňujeme s pohodlným ovládáním. Rozsah jednotlivých ukazatelů si můžete ověřit v dokumentaci Microsoftu uvedené v postupech.

Nastavení komunikace a GPU

Nastavení UDP a GPU volíme podle toho, co ukázalo porovnání a měření. Pokud je podezřelá komunikace, nejprve ověřujeme způsob připojení a cestu; pokud je podezřelé zpracování obrazu, nejprve ověřujeme, ve kterých fázích se GPU používá.

Kontrola TCP, UDP a cesty připojení

Pokud porovnání a měření ukážou na komunikaci, ověříte se správcem používaného klienta, cestu a uplatňované zásady. I když je změna nastavení nutná, omezíte ji na schválený rozsah a zaznamenáte hodnoty před změnou a způsob obnovení. Bránu firewall ani ověřování nevypínáme a port RDP nezveřejňujeme přímo do internetu.

1. Pomocí informací o připojení, diagnostických protokolů produktu a záznamů komunikace od správce ověříte skutečné použití TCP či UDP a cestu.

   RDP používá TCP nebo UDP podle konfigurace a podmínek komunikace. Pomocí „Select RDP transport protocols“ lze zvolit nastavení, které používá UDP nebo TCP, nebo nastavení jen s TCP. Protože při nenavázání připojení UDP může dojít k použití TCP, samotné úspěšné připojení způsob přenosu neprozradí. Viz: Výběr transportu RDP a záložní přechod.

2. Čas výskytu příznaků porovnáte s cestou a způsobem přenosu a po jednom porovnáváte jen potřebná nastavení.

   Nastavení neměníme plošně s představou, že „vypnutím UDP se to zrychlí“. Porovnáváme při stejných podmínkách VPN a brány, stejné operaci a stejných podmínkách zobrazení a nepotřebné změny vracíme zpět.

Se znalostí způsobu přenosu a cesty můžete zaznamenat vztah mezi změnou a příznaky. Omezení jen na TCP nemusí vždy znamenat zrychlení.

flowchart TB
    accTitle: Síťová nastavení porovnat až po ověření způsobu připojení
    accDescr: Rozlišíme běžné přímé připojení a připojení přes bránu nebo službu, ověříme skutečnou cestu a způsob přenosu a teprve pak provedeme povolené porovnání.
    A["Používaný klient a konfigurace připojení"] --> B["Ověřit skutečnou cestu, TCP či UDP"]
    B --> C["Porovnat s časem příznaků"]
    C --> D["Porovnat po jednom jen nutná nastavení"]

Obrázek 16: Ověříme používaný způsob připojení a cestu, porovnáme je s příznaky a teprve pak porovnáváme jen nutná nastavení.

RDP Shortpath je mechanismus služby Azure Virtual Desktop. Navazuje cestu UDP této služby a podle konfigurace používá přímou cestu nebo cestu přes prostředníka. Pokud ji navázat nelze, vrátí se k připojení založenému na TCP. Nelze pro ni použít stejnou tabulku nastavení jako pro přímé připojení k firemnímu počítači pomocí mstsc. Viz: Cesty RDP Shortpath a záložní přechod.

flowchart TB
    accTitle: Cesty RDP Shortpath a záložní přechod
    accDescr: RDP Shortpath v Azure Virtual Desktop se pokusí navázat cestu UDP; pokud se to podaří, použije podle konfigurace přímou cestu nebo prostředníka, a pokud ne, vrátí se k připojení založenému na TCP.
    A["RDP Shortpath"] --> B{"Cesta UDP"}
    B -->|"Navázána"| C["Přímo, nebo přes prostředníka"]
    B -->|"Nenavázána"| D["Návrat k TCP"]

Obrázek 17: Pokud RDP Shortpath nedokáže navázat cestu UDP, vrátí se k připojení založenému na TCP.

Kontrola využití GPU při zpracování obrazu

Tuto kontrolu provádíte, pokud porovnání a měření ukážou na zpracování obrazu. Ověříte výsledky měření zpracování obrazu a podporované OS, ovladače, zásady a klienta. Samotná přítomnost GPU není důvodem ke změně nastavení. Nejprve získáte souhlas správce a připravíte se na vrácení zpět.

1. Rozdělíte vykreslování v aplikaci na vzdáleném počítači, kódování RDP a místní dekódování a vyberete podezřelou fázi.

   I když je GPU k dispozici, nemusí ho využívat všechny fáze. Také v dokumentaci Microsoftu ke konfiguraci Azure Virtual Desktop se vykreslování ve vzdálené relaci a hardwarové kódování snímků nastavují a ověřují zvlášť. Viz: Konfigurace a ověření GPU pro vykreslování a kódování.

2. Podle postupu pro daný produkt ověříte skutečné využití a před nutnou změnou i po ní změříte stejnou operaci.

   Pokud je doba komprese dlouhá, zkoumáte využití GPU pro kódování. Pokud aplikace čeká ve vstupní frontě, změna nastavení kódování míří na jiné místo. Čitelnost textu a plynulost videa vyžadují také jinou volbu kvality obrazu, objemu komunikace a zátěže zpracování. Viz: Rozdíly podle typu zátěže.

Můžete zaznamenat nejen to, zda je GPU k dispozici, ale i to, zda se v problémové fázi využívá a jak se při stejné operaci změnila zátěž a reakce. Změny, které nepřinesly zlepšení, po dohodě se správcem vracíme zpět.

flowchart TB
    accTitle: Ověření využití GPU po fázích
    accDescr: Rozdělíme vykreslování v aplikaci na vzdáleném počítači, kódování RDP a místní dekódování; protože ani s GPU nemusí GPU využívat všechny fáze, ověříme jeho využití v podezřelé fázi.
    A["Vykreslování v aplikaci na vzdáleném PC"] --> B["Kódování RDP"]
    B --> C["Místní dekódování"]
    C -.- D["Ověřit využití GPU po fázích"]

Obrázek 18: I když je GPU k dispozici, nemusí ho využívat vykreslování, kódování i dekódování.

Opětovné ověření a předání

Zlepšení ověřujeme tak, že po změně lze stejnou operaci provést bez potíží a zároveň zůstává zachována potřebná kvalita obrazu, zařízení a pracovní funkce. Porovnejte také výsledek po návratu k původním podmínkám. Pokud jde jen o chvilkové zotavení, příčinu nepovažujeme za potvrzenou a zaznamenáme i dobu špičky a souběžné procesy.

flowchart TB
    accTitle: Pořadí ověření zlepšení
    accDescr: Ukazuje, že po změně ověříme nejen to, zda lze stejnou operaci provést bez potíží, ale i zachování potřebné kvality obrazu, zařízení a pracovních funkcí, porovnáme to s výsledkem po návratu k původním podmínkám a podle chvilkového zotavení příčinu nepotvrzujeme.
    A["Po změně zkusit stejnou operaci"] --> B["Ověřit obraz, zařízení a funkce"]
    B --> C["Porovnat s výsledkem po vrácení"]
    C -.- D["Chvilkové zotavení nic nepotvrzuje"]

Obrázek 19: Kromě výsledku stejné operace porovnáme i potřebné funkce a výsledek po vrácení zpět.

Předání nevyřešeného problému

Užitečným výsledkem je i to, že se stav nezlepší, problém se nereprodukuje nebo čítač nelze použít. Provedená porovnání oddělíme od kontrol, které provést nešlo, a pomocí následující poznámky věc předáme správci nebo vývojáři. Ze sdílených protokolů odstraňte uživatelská jména, cílové počítače a další firemní informace, které pro šetření nejsou potřeba.

Čas výskytu příznaku a časové pásmo:
OS vzdáleného počítače, použitý klient a verze:
Přímé připojení / VPN / RD Gateway / Azure Virtual Desktop apod.:
Pomalá operace a aplikace, reakce jiné aplikace ve stejné relaci:
Rozlišení na vzdálené straně a počet monitorů:
Souběžně probíhající kopírování, tisk apod.:
Jediná změněná podmínka a výsledek po vrácení zpět:
Zátěž a čítače zjištěné na vzdáleném a místním počítači:

Doplníme také, zda se podařilo ověřit skutečné použití TCP či UDP, položky, které nešlo ověřit například kvůli nedostatečným oprávněním, a nastavení přijatelná z pohledu provozu. Když místo „připojení je pomalé“ napíšete „v Poznámkovém bloku se píše normálně, ale při posouvání fotografií se to zastaví“, může další řešitel zkoumat za stejných podmínek.

Uživatel zaznamená operaci, která problém reprodukuje, a výsledky porovnání; správce porovná záznamy o cestě připojení, sdíleném hostiteli a relacích. Samotná skutečnost, že se čeká v RDP, neznamená, že i zpracování, které čekání způsobuje, je RDP. Viz: Rozdělení rolí mezi hostitele a back-end.

Vývojář aplikace zaznamenává zvlášť přijetí vstupní události, začátek a konec práce s databází a soubory a promítnutí do UI. Zvažuje také návrh, který nenechává náročnou práci blokovat vlákno UI. Protokol o dokončení zpracování na vzdáleném počítači však nezaznamenává dokončení zobrazení na místním počítači. Viz: Oddělení zpracování pro zachování schopnosti UI reagovat.

Související články

• Jak rozumět izolaci relací ve Windows
• Bezpečná diagnostika 100% využití disku ve Windows
• Proč nekončí „zbývá 1 sekunda“?

Reference

Jde o primární zdroje z Microsoft Learn. Odkazovaný obsah jsme ověřili 17. září 2026. Při čtení rozlišujte podmínky platnosti pro jednotlivé produkty a to, že nejde o měření provedená v rámci tohoto článku.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Rozdíl mezi RTT a zpožděním od zachycení obrazovky na vzdáleném počítači po zobrazení na místním počítači. Samotná diagnostická funkce je určená pro Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Vztah mezi obsahem obrazovky, rozlišením, aktualizací snímků, kompresí, mezipamětí a objemem komunikace.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Způsob kontroly vstupních a výstupních snímků, důvodů vynechávání a doby kódování. Obsahuje popis starších konfigurací, a proto číselné limity nezobecňujeme na všechna RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Zátěž sdíleného hostitele, komunikace ze vzdáleného počítače do back-endu, vliv přesměrování zařízení.
• Microsoft Learn, Threading model. Vlákno UI a Dispatcher ve WPF, oddělení zpracování pro zachování schopnosti reagovat.
• Microsoft Learn, mstsc. Zadání šířky a výšky vzdálené plochy a více monitorů.
• Microsoft Learn, Supported RDP properties. Rozdíl mezi rozlišením plochy, dynamickým rozlišením a smart sizing. Podporované klienty a podmínky platnosti pro jednotlivé produkty ověřujeme.
• Microsoft Learn, ping. Kontrola odpovědi pomocí ICMP Echo a parametry příkazu.
• Microsoft Learn, Test-NetConnection. Kontrola připojení TCP a význam výstupu.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Měřený úsek User Input Delay, podporované OS, instance a význam maximální hodnoty.
• Microsoft Learn, query session. Informace o relacích a oprávnění potřebná k dotazování na jiné relace.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Výběr TCP či UDP, které RDP používá, a záložní přechod.
• Microsoft Learn, RDP Shortpath. Cesta UDP pro Azure Virtual Desktop a chování, když ji nelze navázat.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Konfigurace a ověření GPU zvlášť pro vykreslování a kódování snímků.

Související články

Nejnovější články se stejnými štítky. Prohloubte si znalosti v příbuzných tématech.

Související témata

Stránky s tématy blízkými tomuto článku. Od článku můžete přejít k souvisejícím službám a dalším článkům.

Služby k tomuto tématu

Tento článek navazuje na následující stránky služeb. Vyberte si nejbližší vstup.

Často kladené otázky

Otázky, které se při konzultacích k tématu tohoto článku objevují nejčastěji.

Proč je vstup v RDP pomalý, když test rychlosti ukazuje stovky Mb/s?

Rychlost přenosu velkých objemů dat a doba, než se na akci vrátí reakce, jsou dvě různé věci. Podílí se na ní odeslání vstupu, zpracování v aplikaci na vzdáleném počítači, komprese obrazu, přenos a zobrazení na místním počítači. Komunikační cesta k serveru testu rychlosti a k cílovému počítači RDP se navíc liší.

Psaní funguje normálně, ale posouvání se trhá. Je to problém připojení?

Nelze to zúžit jen na připojení. Když přibude aktualizací obrazovky, nemusí stíhat vykreslování a komprese na vzdáleném počítači, komunikace nebo dekódování a zobrazení na místním počítači. Rozlišení nebo počet monitorů na vzdálené straně měníme po jednom, porovnáváme a v případě potřeby zkoumáme čítače související s vykreslováním.

Když je ping rychlý, je komunikace RDP v pořádku?

Jen podle toho to posoudit nelze. Ping měří odpověď na ICMP, nikoli přenos obrazovky RDP ani zpracování v aplikaci. V konfiguracích s RD Gateway a podobně se navíc nemusí shodovat ani cesta. I když odpověď nepřijde, rozlišujte mezi blokováním ICMP a nedostupností samotného RDP.

Je User Input Delay doba od stisku klávesy do zobrazení znaku?

Není. Je to čítač, který měří dobu čekání od zařazení vstupu do fronty na vzdáleném počítači do jeho vyzvednutí procesem. Nejde o vnímané zpoždění, které by zahrnovalo komunikaci tam a zpět, zpracování v aplikaci po vyzvednutí vstupu a kompresi, dekódování a zobrazení obrazu.

Mám při pomalém RDP vypnout UDP?

Plošně to nedoporučujeme. Nejprve ověříme skutečný způsob připojení, cestu a uplatňované zásady. Může se stát, že UDP nelze použít a spojení už přešlo na TCP, a omezení jen na TCP proto nemusí vždy přinést zrychlení. Se svolením správce porovnáváme při stejných podmínkách a nepotřebné změny vracíme zpět.

O autorovi

Stránka s profilem autora článku.

Go Komura

Zástupce společnosti KomuraSoft LLC

Specializuje se na vývoj softwaru pro Windows, technické konzultace a vyšetřování chyb. Silnou stránkou jsou zakázky, v nichž zůstává stávající software, a vyšetřování poruch s nejasnou příčinou.