De ce este RDP lent deși conexiunea este rapidă? — Investigați separat intrarea, randarea și comunicația

Testul de viteză arată sute de Mbps, dar în sesiunea de desktop la distanță caracterele apar cu o mică întârziere. La derularea unei pagini cu multe fotografii, imaginea se blochează pe moment. O aplicație de business se oprește câteva secunde doar când apăsați butonul de căutare. De unde ar trebui să începeți investigarea unei astfel de situații, în care „conexiunea este rapidă, dar RDP este lent”?

Capacitatea de răspuns a RDP nu este determinată doar de viteza de transfer a conexiunii. Chiar dacă testul de viteză arată valori mari, pot apărea așteptări în drumul dus-întors al comunicației, în așteptarea intrării de către aplicația de pe computerul la distanță, în codarea ecranului sau în decodarea și afișarea locală. Mai întâi separați „ce operație este lentă”, apoi comparați aceeași operație schimbând câte o singură condiție. Restrângeți zona de investigat prin comparații și măsurători, iar setările UDP și GPU alegeți-le în funcție de rezultat. Consultați: Intervalele măsurate pentru calitatea conexiunii, Factorii de performanță ai gazdei de sesiune.

Totuși, în etapa în care ați restrâns zona de investigat, cauza principală nu este încă stabilită. Chiar dacă reducerea rezoluției aduce o ameliorare, nu afirmăm că „vina era a conexiunii”, deoarece se schimbă nu doar comunicația, ci și procesarea grafică de la ambele capete. Înregistrăm rezultatele separând intervalele măsurate de cele nemăsurate.

Acest articol izolează cauzele pentru tastare, derulare și răspunsul aplicațiilor după stabilirea conexiunii. Chiar dacă simptomele seamănă, cauza nu este neapărat una singură. Situațiile în care „durează mult până apare ecranul de conectare” sau „se blochează doar la autentificare” sunt tratate ca o problemă separată, care se investighează pornind de la jurnalele de stabilire a conexiunii și de autentificare.

Articolul se adresează în principal utilizatorilor și administratorilor care se conectează la Windows 11 sau Windows Server din aplicația Windows „Conexiune desktop la distanță” (mstsc). Exemplele de comenzi sunt pentru Windows PowerShell 5.1. Presupunem că aceeași operație poate fi reprodusă într-o sesiune deja conectată.

Conexiunea directă, VPN-ul, RD Gateway și Azure Virtual Desktop diferă prin traseu, prin informațiile de diagnostic disponibile și prin locul în care se aplică setările. Exemplul de verificare a portului TCP 3389 se limitează la conexiunile directe permise către gazde RDP care folosesc portul standard. Funcțiile de diagnostic și setările GPU din documentația pentru Azure Virtual Desktop nu se aplică ca atare pe PC-urile obișnuite din companie.

Pe dispozitivele companiei, investigați în limitele permise de administrator. Pe o gazdă partajată, identificați-vă propria sesiune și procesul vizat, iar dacă aveți nevoie de jurnalele altor utilizatori, solicitați-le administratorului. Disponibilitatea contoarelor de performanță, numele afișate și permisiunile necesare se verifică pentru fiecare mediu în parte.

Metodele de verificare prezentate aici se bazează pe documentația oficială. Nu sunt rapoarte de măsurători în care o defecțiune a fost reprodusă și rezolvată pe un anumit dispozitiv. Exemplele numerice sunt marcate clar ca ipoteze pentru explicație.

Mecanismul poate fi citit în ordine, începând cu secțiunea următoare, „Viteza de transfer și timpul dus-întors”. Dacă porniți de la simptome, treceți la „Prima comparație, aleasă după simptom”. Pașii practici se află în „Compararea condițiilor una câte una” și „Măsurarea locului în care se așteaptă”.

În diagramă, linia continuă marchează o relație care este întotdeauna valabilă, iar linia punctată una condiționată (condițiile sunt indicate pentru fiecare relație pe pagina de detalii). Lista completă a relațiilor (7 în total, cu dovezi și grad de certitudine) și definițiile conceptelor principale sunt reunite în pagina de detalii a hărții cunoștințelor (în japoneză). Date: JSON-LD / Turtle

Viteza de transfer și timpul dus-întors

RDP (Remote Desktop Protocol) este un protocol prin care dispozitivul local și computerul la distanță schimbă intrări, informații despre ecran și alte date. Pe lângă ecran și intrare, transportă și date pentru redirecționarea dispozitivelor, imprimare și altele. Consultați: Informațiile transferate de RDP.

Viteza de transfer a conexiunii arată câte date pot fi transportate într-o secundă. Valoarea „500 Mbps” dintr-un test de viteză se referă la această cantitate. Nu este o valoare care arată cât timp trece de la o acțiune până la sosirea răspunsului. Consultați: Cerințele de lățime de bandă ale RDP.

flowchart TB
    accTitle: Ce reprezintă valoarea testului de viteză
    accDescr: Arată că valoarea de 500 Mbps din testul de viteză reprezintă cantitatea de date transportată într-o secundă și este o valoare diferită de timpul care trece de la o acțiune până la sosirea răspunsului.
    A["Test de viteză: 500 Mbps"] --> B["Date transportate pe secundă"]
    B -.->|"Altă valoare"| C["Timpul până la răspuns"]

Figura 1: Valoarea testului de viteză arată cantitatea transportată, nu timpul până la sosirea răspunsului.

Timpul dus-întors (RTT) este timpul în care comunicația ajunge la celălalt capăt și se întoarce. Diferența dintre creșterea vitezei de transfer și reducerea timpului dus-întors seamănă cu diferența dintre a adăuga benzi unui drum și a scurta distanța până la destinație. Chiar dacă crește capacitatea de a transporta volume mari de fișiere, dacă timpul dus-întors rămâne același, așteptarea răspunsului la acțiuni rămâne. Consultați: RTT și întârzierea afișării ecranului.

flowchart TB
    accTitle: Viteza de transfer și timpul dus-întors comparate cu un drum
    accDescr: Figura compară creșterea vitezei de transfer cu adăugarea de benzi unui drum, iar reducerea timpului dus-întors cu scurtarea distanței până la destinație.
    A["Creșterea vitezei de transfer"] -->|"Pe un drum"| B["Mai multe benzi"]
    B ~~~ C["Reducerea timpului dus-întors"]
    C -->|"Pe un drum"| D["Distanță mai scurtă"]

Figura 2: Mai multe benzi nu scurtează distanța până la destinație.

Până revine rezultatul unui caracter

Să luăm situația în care tastați un caracter în Notepad pe computerul la distanță. Notepad rulează pe computerul la distanță. Dacă, pentru explicație, presupunem că acțiunea ajunge acolo în 50 de milisecunde, iar informațiile de ecran rezultate se întorc în 50 de milisecunde, timpul folosit de comunicație este în total 100 de milisecunde, adică 0,1 secunde. Timpii de procesare de la cele două capete sunt excluși din acest exemplu.

flowchart TB
    accTitle: Exemplu de timp de comunicație până revine rezultatul unui caracter
    accDescr: Exemplu explicativ în care se presupune câte 50 de milisecunde pentru dus și pentru întors. Nu include timpii de procesare de la cele două capete și nu reprezintă numărul de pachete pentru fiecare tastă.
    A["Tastați local un caracter"] -->|"Dus: 50 ms"| B["Gazda primește intrarea"]
    B --> C["Trimite ecranul actualizat"]
    C -->|"Întors: 50 ms"| D["Rezultatul ajunge local"]

Figura 3: Dacă presupunem 50 de milisecunde la dus și 50 la întors, doar comunicația durează 0,1 secunde. Nu este o valoare măsurată.

Chiar dacă cantitatea pe care o poate transporta conexiunea crește, dacă timpul dus-întors nu se schimbă, aceste 0,1 secunde rămân. Figura 3 este o diagramă conceptuală care ajută la înțelegerea procesării. Nu înseamnă că pentru fiecare tastă se trimite un pachet independent, dus-întors. Traseul către serverul testului de viteză diferă de cel către computerul la care vă conectați prin RDP, așa că trebuie luate în calcul VPN-ul, gateway-ul, direcția de upload a părții la distanță și congestia de pe parcurs. Consultați: Cum se interpretează RTT, Performanța rețelei și a gazdei.

Generarea și livrarea imaginii ecranului

Întârzierea răspunsului, în sensul folosit aici, este așteptarea de la o acțiune locală până când rezultatul devine vizibil. Pe lângă RTT, contează și procesarea aplicației și procesarea care generează și livrează imaginea ecranului. O distingem și de întârzierea care privește doar segmentul de transfer al ecranului. Consultați: Intervalul măsurat de la capturarea ecranului la afișare.

Când intrarea ajunge de la dispozitivul local la computerul la distanță, aplicația de acolo o procesează și actualizează ecranul, informațiile de ecran codate sunt transportate prin rețea, apoi dispozitivul local le decodează și le afișează. Și înainte, și după comunicație există sarcini de care se ocupă computere diferite. Consultați: Procesarea de la capturarea ecranului la afișare.

flowchart TB
    accTitle: Procesarea ecranului are loc și înainte, și după rețea
    accDescr: Fluxul în care intrarea locală ajunge la computerul la distanță, aplicația de acolo o procesează, ecranul este generat și comprimat, iar informațiile de ecran transportate prin rețea sunt readuse local la o formă afișabilă și afișate.
    I["Local: introduceți acțiunea"] --> J["Rețea: transportă intrarea"]
    J --> K["La distanță: aplicația procesează"]
    K --> A["La distanță: generare, comprimare"]
    A --> B["Rețea: transportă imaginea"]
    B --> C["Local: readuce la formă afișabilă"]
    C --> D["Afișare pe ecranul local"]

Figura 4: Computerul la distanță procesează și comprimă, rețeaua transportă, iar dispozitivul local readuce datele la forma de afișare. Fiecare este o sarcină efectuată în alt loc.

În acest articol, codarea este procesarea care, pe computerul la distanță, convertește și comprimă ecranul într-o formă ușor de transmis. Separat de transferul prin rețea, aceasta consumă timp de procesare pe computerul la distanță. Consultați: Timpul de codare pe computerul la distanță.

În acest articol, decodarea este procesarea care readuce informațiile de ecran primite la o formă care poate fi afișată pe dispozitivul local. O distingem de decriptare, care înseamnă eliminarea criptării. Consultați: Timpul de decodare și afișare locală.

Dacă comprimarea pe computerul la distanță durează mult, pregătirea trimiterii trebuie așteptată chiar dacă linia este liberă. Chiar dacă informațiile au sosit, actualizarea întârzie dacă decodarea sau afișarea locală nu ține pasul. Nu este neapărat adevărat că „PC-ul de la birou este performant, deci dispozitivul local poate fi oricare”. Rezerva conexiunii și rezerva de procesare de la cele două capete ale ei sunt lucruri diferite. Consultați: Contoarele de performanță pentru procesarea grafică.

flowchart TB
    accTitle: Întârzieri când procesarea de la capete nu ține pasul
    accDescr: Arată că, dacă comprimarea pe computerul la distanță durează mult, pregătirea trimiterii este așteptată chiar dacă linia este liberă, iar dacă decodarea sau afișarea locală nu ține pasul, actualizarea întârzie chiar dacă informațiile au sosit.
    A["Comprimare lentă la distanță"] --> B["Așteaptă deși linia e liberă"]
    B ~~~ C["Decodarea locală rămâne în urmă"]
    C --> D["Sosit, dar actualizat cu întârziere"]

Figura 5: Chiar dacă linia are rezervă, actualizarea ecranului întârzie dacă procesarea de la capete nu ține pasul.

Diferența dintre tastare și derulare

Când adăugați un caracter în Notepad, se schimbă doar o mică parte a ecranului. La derularea unei pagini cu multe fotografii, în schimb, afișajul se schimbă succesiv pe o suprafață mare. RDP reduce traficul transferând părțile modificate și folosind comprimare și cache potrivite conținutului. Nu trimite de fiecare dată întregul ecran necomprimat. Volumul de lucru variază în funcție de conținutul ecranului și de frecvența actualizărilor. Consultați: Relația dintre conținutul ecranului și lățimea de bandă.

flowchart TB
    accTitle: Volumul de lucru al ecranului la tastare și la derulare
    accDescr: O mică schimbare de caracter și actualizarea continuă a unei suprafețe mari diferă ca natură a muncii de generare și trimitere a ecranului.
    A{"Schimbarea ecranului"} -->|"Adăugați un caracter"| B["Zonă mică"]
    A -->|"Derulare"| D["Zonă mare, continuu"]
    B --> E["Comprimare și transfer după schimbare"]
    D --> E

Figura 6: Chiar și pe aceeași conexiune, volumul de lucru diferă între adăugarea unui caracter și o suprafață mare care se mișcă continuu.

Un document static poate fi ușor, dar în timpul derulării se poate epuiza rezerva transferului de ecran. Dacă măriți rezoluția pe partea la distanță sau numărul de monitoare, crește și ecranul care trebuie procesat. Comparația în care reduceți rezoluția este un experiment care arată dacă fluiditatea revine atunci când scade munca de generare și trimitere a ecranului. Nu este un calcul care stabilește traficul doar pe baza numărului de pixeli. Consultați: Efectul rezoluției, al actualizărilor ecranului și al comprimării.

Așteptările aplicației

Dacă într-o aplicație de business doar căutarea se oprește câteva secunde, iar în aceeași sesiune puteți tasta normal în Notepad, verificați ce așteaptă aplicația respectivă. Se poate ca aplicația de pe computerul la distanță să trimită o interogare unei alte baze de date sau să citească un fișier dintr-un folder partajat și să aștepte răspunsul. Acesta este un traseu separat de comunicația RDP dintre dispozitivul local și computerul la distanță. Consultați: Comunicația de la computerul la distanță către backend.

flowchart TB
    accTitle: Dincolo de RDP există și alți parteneri de comunicație
    accDescr: Arată cazul în care, separat de comunicația dintre dispozitivul local și computerul la distanță, aplicația de pe computerul la distanță așteaptă răspunsul unui server de business.
    A["Dispozitiv local"] -->|"RDP"| B["Aplicația de business la distanță"]
    B -->|"Căutare, cerere de fișier"| C["Bază de date, folder partajat"]
    C -->|"Răspunsul așteptat"| B

Figura 7: Aplicația de business de dincolo de RDP poate aștepta, la rândul ei, răspunsul unui alt server.

Dacă procesarea care se ocupă de ecran și de intrare preia o sarcină lungă, următoarea intrare și actualizarea ecranului întârzie. De exemplu, în WPF capacitatea de răspuns are de suferit dacă firul UI este ocupat mult timp. O utilizare totală a CPU scăzută nu este suficientă pentru a exclude așteptarea unui anumit fir UI. Consultați: Dispatcher și firul UI.

flowchart TB
    accTitle: Se blochează procesarea care se ocupă de ecran și de intrare
    accDescr: Arată că, dacă procesarea care se ocupă de ecran și de intrare preia o sarcină lungă, următoarea intrare și actualizarea ecranului întârzie, iar o utilizare totală a CPU scăzută nu este suficientă pentru a exclude această așteptare.
    A["Procesarea ecranului și intrării"] --> B["Preia o sarcină lungă"]
    B --> C["Intrarea și actualizarea întârzie"]
    C -.- D["Nu se exclude nici la CPU scăzut"]

Figura 8: Așteptarea firului UI nu poate fi exclusă doar pe baza utilizării totale a CPU.

Prima comparație, aleasă după simptom

Cantitatea care poate fi transportată, timpul de așteptare a răspunsului și timpul de generare și afișare a ecranului sunt lucruri diferite. Dacă păstrați această distincție, nu reduceți „RDP este lent” la o singură cauză și puteți porni investigația de la operația care este lentă acum.

flowchart TB
    accTitle: Separați cele trei înainte de investigație
    accDescr: Arată că „RDP este lent” nu se reduce la o singură cauză, ci se separă cantitatea care poate fi transportată, timpul de așteptare a răspunsului și timpul de generare și afișare a ecranului, iar investigația pornește de la operația care este lentă acum.
    A["„RDP este lent”"] --> S
    subgraph S["Priviți separat"]
    direction TB
    B["Cantitatea transportată"] ~~~ C["Așteptarea răspunsului"]
    C ~~~ D["Generarea și afișarea ecranului"]
    end
    S --> E["Porniți de la operația lentă"]

Figura 9: Dacă separați cantitatea transportată, timpul de așteptare a răspunsului și timpul de generare și afișare a ecranului, puteți porni de la operația care este lentă acum.

Scopul izolării cauzei este să limitați locul în care investigați lentoarea. Scopul nu este să faceți sistemul mai rapid din întâmplare, schimbând setările în bloc. Folosind diferențe precum „Notepad merge, dar căutarea se oprește” sau „tastarea este normală, dar derularea este greoaie”, puteți alege punctul de pornire al investigației chiar înainte de a modifica setările de comunicație.

Tabelul următor este un punct de pornire pentru investigație. Nu este un tabel care stabilește cauza. Comparați mai întâi operațiile în aceeași sesiune, apoi schimbați dispozitivul, traseul sau condițiile de afișare necesare.

Caracterele întârzie în mai multe aplicații

Dacă în aceeași sesiune caracterele apar cu întârziere în mai multe aplicații, comparați aceeași operație și de pe alt dispozitiv sau pe alt traseu permis. Corelați timpul dus-întors, așteptarea intrării pe computerul la distanță și sarcina totală a acestuia și nu stabiliți cauza pe baza unei singure valori.

Doar derularea este sacadată

Chiar dacă tastarea este normală, la derularea unei pagini cu multe fotografii actualizările ecranului continuă pe o suprafață mare. Schimbați pe rând rezoluția pe partea la distanță sau numărul de monitoare și comparați pe aceeași pagină. Dacă situația se ameliorează, următoarele ținte ale investigației sunt comprimarea pe computerul la distanță, transferul ecranului și decodarea locală. Doar pe baza rezoluției nu aflați care dintre aceste trei este cauza. Consultați: Sarcina în funcție de conținutul ecranului și de rezoluție.

Doar o aplicație se blochează

Dacă se oprește doar aplicația de business în care ați apăsat butonul de căutare, comparați dacă Notepad sau alt program din aceeași sesiune răspunde. Dacă celelalte aplicații funcționează, investigați mai întâi procesarea aplicației vizate, discul și cererile către baza de date sau folderul partajat. Faptul că lucrați prin RDP și faptul că comunicația RDP este cauza așteptării sunt lucruri diferite. Consultați: Factorii de performanță ai aplicației și ai backendului.

Toți sunt lenți doar la orele de vârf

Dacă sistemul încetinește pentru mai mulți utilizatori în același interval orar, verificați cu administratorul starea celorlalte sesiuni. Corelați sarcina CPU-ului, a memoriei și a stocării gazdei partajate, precum și sarcina liniei partajate, cu ora la care apar simptomele. Nu accesați fără permisiune jurnalele sau procesele altor utilizatori și nu le opriți joburile. Consultați: Resursele gazdei partajate și numărul de utilizatori.

Încetinire în timpul copierii sau imprimării

Dacă momentul în care ați început o copiere sau o imprimare coincide cu problema, suspendați pentru comparație doar transferurile pe care aveți permisiunea să le opriți. Notați dacă situația revine după oprire și dacă încetinește din nou la reluare, apoi investigați competiția cu transferurile din afara ecranului și cu redirecționarea dispozitivelor. Nu faceți comparații care dezactivează în bloc dispozitivele necesare pentru lucru. Consultați: Efectul redirecționării dispozitivelor.

Compararea condițiilor una câte una

Nu este nevoie să modificați toate setările pe rând. Stabiliți mai întâi o bază de comparație și alegeți doar verificările potrivite simptomului. Înainte de a modifica setări sau de a vă reconecta, salvați-vă lucrul și notați valorile inițiale și modul de revenire. Dacă nu aveți permisiunile sau funcțiile necesare, nu le activați forțat, ci predați investigația administratorului.

Operarea locală și operarea prin RDP nu au neapărat aceleași condiții. Faptul că lucrul este rapid pe ecranul fizic al computerului la distanță este un indiciu util, dar sesiunea și condițiile de randare pot diferi. Folosiți același utilizator, aceleași date și aceeași stare a aplicației și nu restrângeți cauza la conexiune doar pentru că „pe ecranul fizic merge repede”.

Compararea aceleiași operații

Pregătiți același utilizator, aceleași date și aceeași operație. Pe o gazdă partajată, verificați-vă propria sesiune și nu opriți aplicațiile sau procesele altor utilizatori. Folosiți alt dispozitiv sau alt traseu numai în limitele permise de administrator.

1. Reproduceți operația lentă cu setările inițiale și notați ora și simptomul.

   În aceeași sesiune la distanță cu aplicația problematică, tastați în Notepad un text de lungime asemănătoare. Distingeți dacă este vorba doar de o aplicație sau de întreaga sesiune.

2. Verificați în același interval sarcina computerului la distanță și a dispozitivului local.

   În Managerul de activități, urmăriți pe computerul la distanță utilizarea CPU, a memoriei și a discului de către aplicația vizată, iar pe dispozitivul local sarcina clientului RDP. Nu vă uitați doar la valoarea totală a CPU, ci verificați procesul vizat. Consultați: Ce trebuie verificat la sarcină.

3. Dintre alt dispozitiv, alt traseu permis și condițiile de afișare, schimbați o singură condiție și repetați aceeași operație.

   Dacă în comparație se schimbă și starea computerului la distanță sau a aplicației, notați și această diferență. Nu considerați rezultatul schimbării mai multor condiții drept efectul unei singure condiții.

4. Reveniți la condițiile inițiale și verificați din nou aceeași operație.

   Dacă rămâne rapid și după revenire, poate fi vorba și de o schimbare temporară a sarcinii sau de altceva. Nu presupuneți că modificarea a avut efect, ci notați condițiile în care simptomul se reproduce.

Având rezultatele pentru starea inițială, după modificare și după revenire, puteți compara ce condiție corespunde cărui simptom. O condiție care a adus ameliorarea este un indiciu pentru investigație, dar nu dovedește singură cauza principală.

flowchart TB
    accTitle: Limitați condițiile schimbate deodată
    accDescr: Fluxul în care stabiliți operația care se reproduce în starea inițială, comparați schimbând o singură condiție și verificați și rezultatul după revenire.
    A["Aceeași operație, setări inițiale"] --> B["Schimbați o singură condiție"]
    B --> C["Repetați aceeași operație"]
    C --> D["Reveniți și reverificați"]
    D --> E["Notați condiția care a ajutat"]

Figura 10: Repetați aceeași operație în starea inițială, după modificare și după revenire și notați condiția care s-a schimbat.

Compararea rezoluției pe partea la distanță

Faceți această comparație când actualizările ecranului, de exemplu la derulare, sunt greoaie. Notați rezoluția și numărul de monitoare dinainte de modificare, salvați-vă lucrul și apoi reconectați-vă. Nu folosiți permanent setări care afectează spațiul de ecran necesar pentru lucru sau lizibilitatea textului.

1. Schimbați doar numărul de monitoare sau doar rezoluția.

   În mstsc, puteți compara folosind setările din fila „Afișare” dinainte de conectare sau specificând lățimea și înălțimea. Consultați: Setările de afișare din mstsc.

2. Verificați că dimensiunea reală a desktopului la distanță s-a schimbat, apoi derulați aceeași pagină.

   Dacă doar micșorați fereastra locală, este posibil să vedeți un desktop mare afișat micșorat. Distingeți rezoluția dinamică de smart sizing și verificați condițiile în care clientul folosit le acceptă. Consultați: Rezoluția desktopului și scalarea afișării.

3. Reveniți la setarea inițială, repetați aceeași operație și comparați sarcina de la cele două capete și mișcarea imaginii.

   Dacă ați trecut deodată la o rezoluție mică și la un singur monitor, comparația rămâne aproximativă. Dacă situația se ameliorează, reveniți pe rând la fiecare setare și separați efectele.

Dacă situația se ameliorează, indiciul se află în zona procesării grafice și a transferului ecranului. 3840×2160 are de patru ori mai mulți pixeli decât 1920×1080, dar traficul nu devine întotdeauna de patru ori mai mare. Depinde de părțile modificate și de comprimare, iar schimbarea rezoluției influențează și procesarea de la cele două capete. Consultați: Relația dintre numărul de pixeli și trafic, Verificarea procesării grafice.

flowchart TB
    accTitle: Ce arată comparația cu rezoluție redusă
    accDescr: Reducerea rezoluției pe partea la distanță poate schimba sarcina atât a procesării grafice, cât și a transferului, așa că o ameliorare nu este suficientă pentru a restrânge cauza la conexiune.
    A["Reduceți rezoluția la distanță"] --> S
    subgraph S["Procesări care se schimbă"]
    direction TB
    B["Procesarea grafică la distanță"] ~~~ C["Volumul de date trimis"]
    C ~~~ D["Afișarea locală"]
    end

Figura 11: Schimbarea rezoluției este o comparație care influențează nu doar conexiunea, ci și procesarea grafică de pe computerul la distanță și de pe dispozitivul local.

Corelarea copierii și imprimării cu simptomele

Suspendați doar procesele pe care aveți permisiunea să le opriți, de exemplu transferurile începute de dvs. Nu opriți procesele de backup și de securitate ale companiei și nici joburile altor utilizatori. Nu dezactivați în bloc redirecționarea dispozitivelor audio și de intrare necesare pentru lucru.

1. Înainte de a începe copierea, sincronizarea în cloud sau imprimarea, precum și în timpul acestora, notați aceeași operație și sarcina.

   Prin RDP circulă, pe lângă ecran, și date ale unităților, imprimantelor și altor dispozitive. Redirecționarea care permite folosirea dispozitivelor locale pe computerul la distanță poate crește, cât timp este folosită, sarcina de comunicație și de procesare. Consultați: Efectul redirecționării dispozitivelor.

2. Suspendați transferul vizat în limitele permise și verificați din nou aceeași operație.

   Dacă puteți compara și după reluare, notați și simptomul de după reluare. Dacă încercați să renunțați la redirecționări de dispozitive inutile, schimbați-le tot pe rând și asigurați-vă că puteți reveni la setarea inițială.

Puteți aprecia dacă începutul transferului corespunde problemei, iar suspendarea corespunde revenirii. Dacă se vede o corespondență, corelați transferurile din afara ecranului și sarcina resurselor partajate cu jurnalele administratorului.

flowchart TB
    accTitle: Înainte și după problemă, pe aceeași axă a timpului
    accDescr: Notați aceeași operație și sarcina înainte de transfer, în timpul transferului și după oprire și comparați relația dintre problemă și activitate.
    A["Operație și sarcină înainte"] --> B["Operație și sarcină în timpul transferului"]
    B --> C["Operație și sarcină după oprire"]
    C --> D["Corespund problema și revenirea?"]

Figura 12: Urmăriți cum se schimbă lentoarea aceleiași operații și sarcina înainte de transfer, în timpul lui și după oprire.

Măsurarea locului în care se așteaptă

De pe dispozitivul local investigați drumul dus-întors al comunicației și conexiunea TCP, iar pe computerul la distanță, așteptarea în coada de intrare și actualizările ecranului. Fiecare valoare măsoară doar un interval limitat, așa că interpretați rezultatele comparându-le cu tabelul din „Domeniul de valabilitate al rezultatelor măsurătorilor”.

Verificarea ICMP și a conexiunii TCP

Comenzile se rulează pe dispozitivul Windows local. Sunt vizate doar configurațiile în care vă conectați direct, prin LAN-ul companiei sau printr-un VPN permis, la o gazdă RDP care folosește portul standard TCP 3389. Pentru configurațiile prin RD Gateway sau Azure Virtual Desktop ori cu port personalizat, stabiliți ținta verificării împreună cu administratorul. Nu expuneți porturi și nu modificați firewallul.

1. Introduceți computerul la distanță permis și notați rezultatul răspunsului ICMP și al conexiunii TCP.

   $target = Read-Host 'Numele sau adresa IP a gazdei RDP pe care aveți permisiunea să o investigați'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Specificați computerul la distanță.'
   }
       
   # Verificăm de mai multe ori timpul de răspuns ICMP. Un eșec nu înseamnă singur că RDP este indisponibil.
   ping.exe -n 20 $target
       
   # Verificare valabilă doar pentru configurațiile cu conexiune directă la portul standard TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Corelați rezultatele din intervalul lent și din perioada normală cu ora simptomelor și cu traseul real al conexiunii.

   Cele 20 de solicitări ping sunt o observație scurtă. Notați fluctuațiile valorilor și lipsa răspunsurilor, dar ICMP poate fi blocat. Nu excludeți opririle intermitente doar pe baza valorii medii, ci folosiți informațiile despre conexiune și jurnalele de rețea ale administratorului. Consultați: Ce măsoară ping.

TcpTestSucceeded: True înseamnă că s-a reușit o conexiune TCP la portul specificat. Nu măsoară lățimea de bandă, UDP, operarea după autentificare sau fluiditatea imaginii. Test-NetConnection nu are un comutator -UDP care să verifice UDP. Consultați: Sintaxa și rezultatele Test-NetConnection.

Evaluăm ținând cont de diferențele de traseu și de serviciu. Cu RD Gateway și soluții similare, traseul ICMP sau al conexiunii TCP directe către gazdă poate să nu coincidă cu traseul RDP real. În Azure Virtual Desktop sunt disponibile, pentru fiecare conexiune, RTT și lățimea de bandă estimată, dar această funcție de diagnostic este destinată acelui serviciu. Nu excludem opririle scurte doar pe baza valorii medii. Consultați: Jurnalele de calitate a conexiunii din Azure Virtual Desktop.

flowchart TB
    accTitle: Traseul verificat și traseul RDP real
    accDescr: În configurațiile cu RD Gateway sau soluții similare, traseul ICMP sau al conexiunii TCP directe de la dispozitivul local către gazdă poate să nu coincidă cu traseul RDP real.
    A["Dispozitiv local"] -->|"ICMP, TCP direct"| C["Gazdă RDP"]
    A -->|"RDP real"| B["RD Gateway etc."]
    B --> C

Figura 13: Traseul ICMP sau al conexiunii TCP directe către gazdă poate să nu coincidă cu cel al conexiunii RDP reale.

Măsurarea așteptării în coada de intrare

User Input Delay măsoară așteptarea de pe computerul la distanță din momentul în care intrarea intră în coadă până când un proces o preia. Nu este timpul total de la apăsarea unei taste până când caracterul devine vizibil. Consultați: Definiția User Input Delay.

Investigați în interiorul sesiunii la distanță de pe computerul la distanță. Condițiile de compatibilitate indicate de Microsoft sunt Windows 10 versiunea 1809 sau mai nouă și Windows Server 2019 sau mai nou. Pentru aceste sisteme nu este necesară adăugarea unei intrări în registry pentru activare. Verificați numele afișat, permisiunile și existența contorului, iar dacă nu este disponibil, notați acest fapt și consultați-vă cu administratorul. Consultați: Condiții de compatibilitate și configurare.

1. În PowerShell, în aceeași sesiune, notați ora și ID-ul sesiunii.

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

   Pentru a interoga sesiunile altor utilizatori pot fi necesare permisiuni suplimentare. Numele standard al instanței pentru procesul vizat este SessionID:ProcessID <Process Image>. Aveți grijă să nu amestecați, bazându-vă doar pe ID-ul sesiunii, valorile altor utilizatori sau ale proceselor cu același nume. Consultați: Permisiunile pentru query session, Identificarea instanțelor.

2. În perfmon.exe, adăugați contorul disponibil, User Input Delay per Process sau User Input Delay per Session.

   Selectați procesul sau sesiunea vizată și observați la început cu intervalul implicit de 1 secundă. Distingeți instanța agregată, care combină mai multe sesiuni, de valorile fiecărei sesiuni.

3. Reproduceți operația la care intrarea este lentă și comparați așteptarea din coadă cu ora simptomului.

   Pentru fiecare țintă măsurată vedeți timpul maxim de așteptare din intervalul de măsurare. Chiar dacă valoarea este mică, pot rămâne procesarea de după ce aplicația a preluat intrarea și întârzierea până când rezultatul revine pe dispozitivul local.

Puteți afla dacă intrarea așteaptă în coada de intrare a computerului la distanță. Este un indicator diferit de timpul perceput, care include drumul dus-întors al comunicației și afișarea locală. Consultați: Semnificația valorii maxime și a intervalului de măsurare.

flowchart TB
    accTitle: Intervalul măsurat de User Input Delay
    accDescr: Intervalul măsurat ține de la coada de intrare a computerului la distanță până când aplicația preia intrarea și nu include comunicația și afișarea de dinainte și de după.
    A["Intrarea sosește de la local"] --> B["Intră în coada de la distanță"]
    B -->|"Aici se măsoară"| C["Aplicația preia intrarea"]
    C --> D["Procesare și transfer al ecranului"]
    D --> E["Afișare pe dispozitivul local"]

Figura 14: Se măsoară așteptarea în coada de intrare a computerului la distanță. Este altceva decât timpul total până când rezultatul devine vizibil local.

Investigarea actualizărilor ecranului și a motivelor omiterii cadrelor

Pregătiți o operație cu actualizări continue ale ecranului, de exemplu derularea. Disponibilitatea și locul de măsurare ale contoarelor RemoteFX Graphics trebuie verificate în funcție de sistemul de operare, de configurația gazdei și de permisiuni. Aici doar citim contoarele disponibile. Nu este o procedură de instalare sau activare a vechii funcții RemoteFX. Consultați: Condițiile de aplicare ale contoarelor Graphics.

1. Cu query session sau qwinsta, verificați numele sesiunii vizate și alegeți instanța de contor corespunzătoare.

2. În timpul unei operații cu actualizări ale ecranului, comparați Input Frames/Second și Output Frames/Second.

   Dacă ieșirea este mai mică decât intrarea, o parte din cadre sunt omise pe parcurs. Verificați valorile Frames Skipped/Second defalcate pe lipsa de resurse a computerului la distanță, a rețelei și a clientului.

3. Corelați motivele omiterii cu sarcina de la cele două capete și a comunicației și verificați și Average Encoding Time.

   Dacă timpul de codare este lung, investigați procesarea de comprimare de pe computerul la distanță. Dacă numărul de cadre este mic încă de pe partea de intrare, este posibil și ca aplicația să nu actualizeze des ecranul. Un număr mic de cadre pe un ecran static nu este în sine o anomalie.

Pe baza cadrelor de intrare și ieșire din timpul actualizărilor, a motivelor omiterii și a timpului de codare, puteți restrânge zona de investigat. Clasificarea contoarelor este un indiciu și trebuie evaluată împreună cu sarcina reală și cu configurația conexiunii. Consultați: Cum se interpretează numărul de cadre și timpul de codare.

flowchart TB
    accTitle: Restrângerea investigației pornind de la omiterea cadrelor
    accDescr: În timpul unei operații cu actualizări ale ecranului comparați numărul de cadre de intrare și de ieșire, apoi, pornind de la contoarele care arată motivele omiterii, corelați cu sarcina procesării, a comunicației și a afișării.
    A["Comparați I/O la derulare"] --> B["Ieșire mică: verificați omiterea"]
    B --> C["Contoarele pe motive"]
    C --> D["Sarcina la distanță, rețea, local"]

Figura 15: Comparați intrarea și ieșirea în timpul derulării și corelați motivele omiterii cu sarcina computerului la distanță, a liniei și a dispozitivului local.

Nu generalizăm la toate configurațiile diagramele conceptuale ale transferului de ecran și documentația veche. Există și configurații care transferă video și audio printr-un mecanism separat. Documentația contoarelor Graphics descrie și configurații vechi, așa că nu interpretăm valorile de acolo ca pe o specificație comună de tipul „orice RDP are maximum 30 fps”. Folosim funcțiile și valorile după ce le verificăm domeniul de aplicare. Consultați: Transferul ecranului și sarcinile de lucru, Documentația contoarelor Graphics.

Domeniul de valabilitate al rezultatelor măsurătorilor

O valoare mică nu înseamnă același lucru cu o utilizare confortabilă. Domeniul fiecărui indicator poate fi verificat în documentația Microsoft indicată la pași.

Setările de rețea și GPU

Setările UDP și GPU le alegeți în funcție de ce ați aflat din comparații și măsurători. Dacă bănuiți comunicația, verificați mai întâi metoda de conectare și traseul, iar dacă bănuiți procesarea grafică, verificați mai întâi în ce etapă este folosit GPU-ul.

Verificarea TCP, UDP și a traseului conexiunii

Dacă, după comparații și măsurători, bănuiți comunicația, verificați împreună cu administratorul clientul folosit, traseul și politicile aplicate. Chiar dacă trebuie să modificați setări, faceți-o doar în limitele aprobate și notați valoarea dinainte de modificare și modul de restabilire. Nu dezactivați firewallul sau autentificarea și nu expuneți portul RDP direct pe internet.

1. Verificați TCP, UDP și traseul folosite efectiv, pe baza informațiilor despre conexiune, a jurnalelor de diagnostic ale produsului și a jurnalelor de rețea ale administratorului.

   RDP folosește TCP sau UDP în funcție de configurație și de condițiile de comunicație. În „Select RDP transport protocols” puteți alege între setarea care folosește UDP sau TCP și setarea care folosește doar TCP. Deoarece există și un comportament în care se folosește TCP dacă conexiunea UDP nu se stabilește, doar din reușita conectării nu aflați metoda. Consultați: Alegerea transportului RDP și revenirea.

2. Corelați ora simptomului cu traseul și metoda și comparați doar setările necesare, una câte una.

   Nu faceți modificări generale pornind de la ideea că „dacă dezactivăm UDP, va fi mai rapid”. Comparați în aceleași condiții de VPN și gateway, cu aceeași operație și aceleași condiții de afișare, și anulați modificările inutile.

Cunoscând metoda și traseul, puteți nota relația dintre modificare și simptom. Trecerea exclusiv pe TCP nu aduce întotdeauna o accelerare.

flowchart TB
    accTitle: Comparați setările de comunicație după ce verificați metoda de conectare
    accDescr: Distingeți conexiunea directă obișnuită de conexiunea prin gateway sau serviciu și faceți comparațiile permise după ce verificați traseul și metoda reale.
    A["Clientul și configurația conexiunii"] --> B["Traseul real, TCP sau UDP"]
    B --> C["Corelați cu ora simptomului"]
    C --> D["Doar ce e necesar, pe rând"]

Figura 16: Verificați metoda de conectare și traseul folosite, corelați-le cu simptomul și abia apoi comparați doar setările necesare.

RDP Shortpath este un mecanism al Azure Virtual Desktop. Stabilește un traseu UDP pentru acest serviciu și, în funcție de configurație, folosește un traseu direct sau un releu. Dacă traseul nu poate fi stabilit, revine la o conexiune bazată pe TCP. Nu poate fi tratat în același tabel de setări cu situația în care vă conectați direct cu mstsc la un PC din companie. Consultați: Traseele RDP Shortpath și revenirea.

flowchart TB
    accTitle: Traseele RDP Shortpath și revenirea
    accDescr: RDP Shortpath din Azure Virtual Desktop încearcă să stabilească un traseu UDP; dacă reușește, folosește un traseu direct sau un releu, în funcție de configurație, iar dacă nu reușește, revine la o conexiune bazată pe TCP.
    A["RDP Shortpath"] --> B{"Traseu UDP"}
    B -->|"Stabilit"| C["Direct sau prin releu"]
    B -->|"Nestabilit"| D["Revine la TCP"]

Figura 17: RDP Shortpath revine la o conexiune bazată pe TCP dacă nu poate stabili traseul UDP.

Verificarea utilizării GPU în procesarea grafică

Faceți această verificare dacă, după comparații și măsurători, bănuiți procesarea grafică. Verificați rezultatele măsurătorilor procesării grafice, precum și sistemul de operare, driverul, politicile și clientul compatibile. Nu schimbați setările doar pentru că există un GPU. Obțineți mai întâi aprobarea administratorului și pregătiți revenirea.

1. Separați randarea aplicației de pe computerul la distanță, codarea RDP și decodarea locală și alegeți etapa suspectă.

   Chiar dacă există un GPU, nu toate etapele îl folosesc neapărat. Și în documentația de configurare Microsoft pentru Azure Virtual Desktop, randarea sesiunii la distanță și codarea hardware a cadrelor se configurează și se verifică separat. Consultați: Configurarea și verificarea GPU pentru randare și codare.

2. Urmând procedura produsului vizat, verificați utilizarea reală și măsurați aceeași operație înainte și după modificarea necesară.

   Dacă timpul de comprimare este lung, investigați folosirea GPU pentru codare. Dacă schimbați setările de codare pentru o aplicație care așteaptă în coada de intrare, țintiți locul greșit. Pentru lizibilitatea textului și pentru fluiditatea video, și alegerea între calitatea imaginii, trafic și sarcina de procesare diferă. Consultați: Diferențele în funcție de sarcina de lucru.

Dincolo de simpla prezență a GPU-ului, puteți nota dacă GPU-ul este folosit în etapa problematică și cum s-au schimbat sarcina și răspunsul pentru aceeași operație. Modificările care nu aduc ameliorare le anulați după ce vă consultați cu administratorul.

flowchart TB
    accTitle: Verificarea utilizării GPU pe etape
    accDescr: Separați randarea aplicației de pe computerul la distanță, codarea RDP și decodarea locală și, deoarece nici în prezența unui GPU nu toate etapele îl folosesc neapărat, verificați utilizarea în etapa suspectă.
    A["Randarea aplicației la distanță"] --> B["Codarea RDP"]
    B --> C["Decodarea locală"]
    C -.- D["Verificați GPU pe etape"]

Figura 18: Chiar dacă există un GPU, randarea, codarea și decodarea nu îl folosesc neapărat toate.

Reverificarea și predarea

Confirmați ameliorarea prin faptul că, după modificare, aceeași operație se poate efectua fără probleme și, în plus, se păstrează calitatea imaginii, dispozitivele și funcțiile de business necesare. Comparați și rezultatul obținut după revenirea la condițiile inițiale. Dacă revenirea este doar de moment, nu considerați cauza stabilită, ci notați rezultatele incluzând orele aglomerate și procesările simultane.

flowchart TB
    accTitle: Ordinea verificării ameliorării
    accDescr: Arată că, după modificare, verificați dacă aceeași operație se poate efectua fără probleme și dacă se păstrează calitatea imaginii, dispozitivele și funcțiile de business necesare, comparați cu rezultatul revenirii la condițiile inițiale și nu considerați cauza stabilită pe baza unei reveniri de moment.
    A["Aceeași operație după schimbare"] --> B["Calitate, dispozitive, funcții"]
    B --> C["Comparați cu revenirea"]
    C -.- D["O revenire de moment nu e dovadă"]

Figura 19: Pe lângă rezultatul aceleiași operații, comparați funcțiile necesare și rezultatul revenirii la starea inițială.

Predarea unei probleme nerezolvate

Și situațiile în care nu există ameliorare, simptomul nu se reproduce sau contoarele nu sunt disponibile sunt rezultate utile. Separați comparațiile pe care le-ați putut face de verificările pe care nu le-ați putut face și predați investigația administratorului sau dezvoltatorului cu nota de mai jos. Din jurnalele partajate eliminați informațiile de business care nu sunt necesare investigației, precum numele de utilizator și numele computerelor la distanță.

Ora la care a apărut simptomul și fusul orar:
Sistemul de operare la distanță, clientul folosit și versiunea:
Conexiune directă / VPN / RD Gateway / Azure Virtual Desktop etc.:
Operația și aplicația lente, reacția altor aplicații în aceeași sesiune:
Rezoluția pe partea la distanță și numărul de monitoare:
Copieri, imprimări etc. care rulau în același timp:
Singura condiție schimbată și rezultatul revenirii:
Sarcina și contoarele observate la distanță și local:

Adăugați și dacă ați putut verifica TCP și UDP folosite efectiv, ce elemente nu ați putut verifica, de exemplu din lipsă de permisiuni, și ce setări sunt acceptabile din punctul de vedere al activității. În loc să spuneți „conexiunea este lentă”, dacă spuneți „în Notepad pot tasta normal, dar se blochează când derulez fotografii”, următorul responsabil poate investiga în aceleași condiții.

Utilizatorul notează operația care reproduce problema și rezultatele comparațiilor, iar administratorul corelează jurnalele traseului de conexiune, ale gazdei partajate și ale sesiunilor. Faptul că așteptarea are loc prin RDP nu înseamnă că și procesarea care provoacă așteptarea este RDP. Consultați: Împărțirea rolurilor între gazdă și backend.

Dezvoltatorii aplicației înregistrează separat preluarea evenimentelor de intrare, începutul și sfârșitul operațiilor cu baza de date și cu fișierele și reflectarea în interfață. Merită luată în considerare și o proiectare care nu lasă sarcinile grele să ocupe firul UI. Totuși, jurnalul de finalizare a procesării de pe computerul la distanță nu înregistrează finalizarea afișării pe dispozitivul local. Consultați: Separarea procesărilor pentru a păstra capacitatea de răspuns a interfeței.

Articole conexe

• Cum să înțelegem izolarea sesiunilor în Windows
• Cum izolați în siguranță cauza unui disc la 100% în Windows
• De ce nu se mai termină „1 secundă rămasă”?

Referințe

Acestea sunt surse primare de pe Microsoft Learn. Am verificat conținutul consultat pe 17 septembrie 2026. Citiți-le distingând condițiile de aplicare pentru fiecare produs și ținând cont că nu sunt măsurători efectuate în cadrul acestui articol.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Diferența dintre RTT și întârzierea de la capturarea ecranului pe computerul la distanță până la afișarea locală. Funcția de diagnostic în sine este destinată Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Relația dintre conținutul ecranului, rezoluție, actualizarea cadrelor, comprimare, cache și volumul de trafic.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Cum verificați cadrele de intrare și de ieșire ale ecranului, motivele omiterii și timpul de codare. Deoarece include descrieri ale unor configurații vechi, limitele numerice nu sunt generalizate la orice RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Sarcina gazdei partajate, comunicația de la computerul la distanță către backend, efectul redirecționării dispozitivelor.
• Microsoft Learn, Threading model. Firul UI și Dispatcher în WPF, separarea procesărilor pentru a păstra capacitatea de răspuns.
• Microsoft Learn, mstsc. Specificarea lățimii și înălțimii desktopului la distanță și a mai multor monitoare.
• Microsoft Learn, Supported RDP properties. Diferența dintre rezoluția desktopului, rezoluția dinamică și smart sizing. Verificați clienții compatibili și condițiile de aplicare pentru fiecare produs.
• Microsoft Learn, ping. Verificarea răspunsului prin ICMP Echo și opțiunile comenzii.
• Microsoft Learn, Test-NetConnection. Verificarea conexiunii TCP și semnificația rezultatelor.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Intervalul măsurat de User Input Delay, sistemele de operare vizate, instanțele și semnificația valorii maxime.
• Microsoft Learn, query session. Informațiile despre sesiuni și permisiunile necesare pentru interogarea altor sesiuni.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Alegerea între TCP și UDP folosite de RDP și revenirea.
• Microsoft Learn, RDP Shortpath. Traseul UDP pentru Azure Virtual Desktop și comportamentul atunci când acesta nu poate fi stabilit.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Configurarea și verificarea GPU separat pentru randare și pentru codarea cadrelor.

Articole conexe

Cele mai recente articole care au aceleași etichete. Aprofundați cunoștințele prin subiecte apropiate.

Subiecte conexe

Pagini de subiect apropiate de această temă. Pornind de la articol, puteți ajunge la servicii conexe și la alte articole.

Servicii legate de această temă

Acest articol se leagă de paginile de servicii de mai jos. Alegeți punctul de intrare cel mai apropiat de nevoia dumneavoastră.

Întrebări frecvente

Întrebările pe care le primim cel mai des în consultanță pe tema acestui articol.

De ce tastarea în RDP este lentă, deși testul de viteză arată sute de Mbps?

Viteza cu care se transportă volume mari de date și timpul până când o acțiune primește răspuns sunt lucruri diferite. Contează trimiterea intrării, procesarea în aplicația de pe computerul la distanță, comprimarea ecranului, transferul și afișarea locală. În plus, traseul de rețea către serverul testului de viteză diferă de cel către computerul la care vă conectați prin RDP.

Dacă tastarea merge normal, dar doar derularea este sacadată, problema ține de conexiune?

Cauza nu poate fi restrânsă doar la conexiune. Când actualizările ecranului se înmulțesc, este posibil ca randarea și comprimarea pe computerul la distanță, comunicația sau decodarea și afișarea locală să nu țină pasul. Schimbați pe rând rezoluția pe partea la distanță sau numărul de monitoare și comparați, iar dacă este nevoie, examinați contoarele legate de randare.

Dacă ping-ul este rapid, comunicația RDP este în regulă?

Doar pe baza lui nu se poate trage o concluzie. Ping măsoară răspunsul la ICMP, nu transferul ecranului prin RDP și nici procesarea aplicației. În configurațiile cu RD Gateway sau soluții similare, nici traseul nu coincide neapărat. Chiar și atunci când nu primiți răspuns, distingeți între blocarea ICMP și indisponibilitatea RDP în sine.

User Input Delay este timpul de la apăsarea unei taste până la apariția caracterului?

Nu. Este un contor care măsoară timpul de așteptare de pe computerul la distanță, din momentul în care intrarea intră în coadă până când procesul o preia. Nu este latența percepută, care ar include drumul dus-întors prin rețea, procesarea aplicației după preluare și comprimarea, decodarea și afișarea ecranului.

Ar trebui să dezactivez UDP când RDP este lent?

Nu recomandăm acest lucru în mod general. Verificați mai întâi metoda reală de conectare, traseul și politicile aplicate. Se poate ca UDP să nu fie disponibil și conexiunea să fi revenit la TCP, iar trecerea exclusiv pe TCP nu aduce întotdeauna o accelerare. Comparați în aceleași condiții, cu permisiunea administratorului, și anulați modificările inutile.

Profilul autorului

Pagina de profil a autorului articolului.

Go Komura

Reprezentant al KomuraSoft LLC

Specializat în dezvoltarea de software Windows, consultanță tehnică și investigarea defectelor, cu puncte forte în proiectele care pornesc de la resurse software existente și în investigarea avariilor ale căror cauze sunt greu de identificat.