Perché RDP è lento su una connessione veloce? — Separare input, disegno dello schermo e rete

Un test di velocità segna centinaia di Mbit/s, eppure in Desktop remoto i caratteri compaiono con un battito di ritardo. Scorrete una pagina piena di foto e lo schermo scatta ancora di più.

La chiave per dare senso a questa discrepanza è: poter trasportare molti dati e ottenere una risposta rapida a un’azione sono due cose diverse. Inoltre lo schermo che torna indietro come risposta viene prodotto sul PC host e mostrato sul PC davanti a voi. Non è un lavoro che il collegamento di rete svolge da solo.¹

Sullo stesso schermo remoto, seguiamo che cosa cambia passando dalla digitazione allo scorrimento e poi a una ricerca in un’applicazione gestionale. Le sezioni da 1 a 4 spiegano il meccanismo, e dalla sezione 5 in poi c’è la parte di analisi, per esaminare davvero il problema.

1. Un collegamento più veloce non accorcia necessariamente l’attesa di una risposta

Supponiamo che digitiate un carattere nel Blocco note della macchina remota. Ciò che vedete è lo schermo proprio davanti a voi, ma il Blocco note è in esecuzione sul PC host. La vostra azione viene inviata là, l’informazione sullo schermo modificato torna qui e il carattere compare.

Quale parte di questo giro rappresentano allora i «500 Mbit/s» di un test di velocità?

È una cifra che indica quanti dati possono essere trasportati in un secondo. Quella capacità conta quando il file che state scaricando è grande. Ciò che notate digitando un solo carattere, invece, è il tempo che intercorre dalla pressione del tasto al ritorno del risultato. È come la differenza fra allargare una strada e accorciare la distanza fino a destinazione.¹

Per amore di spiegazione, ammettiamo che l’azione impieghi 50 millisecondi a raggiungere l’host e che l’informazione di schermo risultante impieghi 50 millisecondi a tornare. In tal caso il tempo speso sulla sola rete somma 100 millisecondi, cioè 0,1 secondi. Il tempo di elaborazione sui PC alle due estremità è per ora messo da parte.

flowchart TB
    accTitle: Esempio del tempo di rete prima che torni il risultato di un carattere
    accDescr: Un esempio che ipotizza 50 millisecondi per direzione a scopo di spiegazione. Esclude il tempo di elaborazione alle due estremità e non rappresenta un conteggio di pacchetti per tasto.
    A["Digitare un carattere in locale"] -->|"Andata, 50 ms"| B["L'host riceve l'input"]
    B --> C["Inviare lo schermo con l'input applicato"]
    C -->|"Ritorno, 50 ms"| D["Il risultato arriva sulla vostra macchina"]

Figura 1: Se l’andata impiega 50 millisecondi e il ritorno 50 millisecondi, la sola rete conta per 0,1 secondi. Non sono valori misurati.

Questo tempo per attraversare la rete e tornare si chiama tempo di andata e ritorno (RTT). Anche se passate a un collegamento capace di trasportare di più, l’attesa di una risposta della figura 1 resta la stessa finché il tempo di andata e ritorno resta uguale.¹

Ecco perché i download possono essere veloci mentre la digitazione continua ad arrivare con un battito di ritardo. Consideriamo ora il caso in cui, sulla stessa connessione, la digitazione non dà problemi ma lo scorrimento diventa fiacco.

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 7, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Lo scorrimento aumenta il lavoro di invio dello schermo

Quando aggiungete un carattere nel Blocco note, solo una piccola parte dello schermo cambia visivamente. Scorrete invece una pagina fitta di foto e un’ampia area del display cambia un fotogramma dopo l’altro.

RDP non invia ogni volta l’intero schermo non compresso. Invia le regioni che sono cambiate e contiene il traffico con compressione e memorizzazione nella cache adatte al contenuto. La quantità di lavoro necessaria per aggiornare e inviare è diversa fra l’aggiunta di un carattere e foto che continuano a muoversi.²

flowchart TB
    accTitle: Come cambia il carico dello schermo fra digitazione e scorrimento
    accDescr: Un piccolo cambiamento di carattere e un aggiornamento continuo su un'area ampia differiscono per natura del lavoro di produzione e invio dello schermo.
    A["Aggiungere un carattere nel Blocco note"] --> B["Cambia una piccola regione"]
    C["Scorrere uno schermo pieno di foto"] --> D["Un'ampia area cambia di continuo"]
    B --> E["Comprimere e trasferire in base al cambiamento"]
    D --> E

Figura 2: Sulla stessa connessione, la quantità di lavoro è diversa fra l’aggiunta di un carattere e un’ampia area che continua a muoversi.

Ne consegue che tutto può sembrare leggero mentre leggete un documento statico e che invece il trasferimento grafico resti senza margine appena iniziate a scorrere. Anche alzare la risoluzione sul lato remoto o aggiungere monitor ingrandisce ciò che va prodotto e inviato.²

Solo ora diventa chiaro perché valga la pena abbassare la risoluzione e confrontare. Non è una formula magica per rendere RDP più veloce, ma un esperimento per vedere se la reattività torna una volta ridotto il lavoro di produzione e invio dello schermo. La sezione 5 spiega nel dettaglio come provarlo.

Se la digitazione va bene ma solo lo scorrimento è fiacco, può essere perché lo stesso collegamento sta gestendo molti più aggiornamenti dello schermo. E che dire allora del caso in cui il collegamento ha ancora margine ma lo schermo non riesce a stare al passo?

3. Anche con il collegamento scarico, il PC che produce lo schermo può farvi attendere

Lo schermo viene elaborato sia prima dell’invio sia dopo la ricezione

Quando scorrete una pagina di foto, il PC host aggiorna il display e converte e comprime l’informazione di schermo in una forma più facile da inviare. Questa è la codifica. Il PC davanti a voi riconverte l’informazione che arriva in una forma visualizzabile. Quel lato si chiama decodifica.¹

flowchart TB
    accTitle: L'elaborazione dello schermo avviene su entrambi i lati del collegamento
    accDescr: La compressione sull'host, il trasferimento in rete e la decodifica e visualizzazione sulla vostra macchina sono passaggi distinti, e gli aggiornamenti dello schermo restano indietro se uno solo di essi non sta al passo.
    A["L'host produce e comprime lo schermo"] --> B["Il collegamento trasporta l'informazione di schermo"]
    B --> C["La macchina locale la riconverte in forma visualizzabile"]
    C --> D["Mostrato sullo schermo locale"]

Figura 3: Comprimere sull’host, trasportare sul collegamento, riconvertire in visualizzazione sulla macchina locale. Ciascuno è lavoro svolto in un luogo diverso.

Supponiamo, per esempio, che comprimere lo schermo sull’host richieda tempo. Anche con il collegamento scarico, attendete che l’informazione da inviare sia pronta. Viceversa, anche quando l’informazione è arrivata, l’aggiornamento dello schermo è in ritardo se il PC locale non sta al passo con decodifica e visualizzazione.³

Il riflesso è pensare che il PC dell’ufficio sia potente e che sul lato locale vada bene qualsiasi cosa, ma il PC locale ha comunque il compito di mostrare lo schermo che riceve. Il margine sul collegamento e il margine nell’elaborazione alle due estremità sono due cose diverse.

Se si blocca una sola applicazione, potreste star aspettando la sua risposta

Consideriamo ora un caso in cui, sullo stesso schermo remoto, premere Cerca in un’applicazione gestionale la blocca per diversi secondi. Nel frattempo, supponiamo che possiate digitare normalmente in una finestra del Blocco note aperta accanto.

In tal caso volete vedere che cosa stia aspettando l’applicazione gestionale. L’applicazione sull’host potrebbe chiedere a un database separato di eseguire la ricerca, e la risposta potrebbe tardare a tornare. Leggere un file da una cartella condivisa produce lo stesso tipo di attesa.⁴

flowchart TB
    accTitle: Oltre RDP c'è un altro interlocutore
    accDescr: Mostra il caso in cui, oltre al traffico che collega il client locale e l'host, l'applicazione sull'host attende una risposta da un server gestionale.
    A["Client locale"] -->|"RDP"| B["Applicazione gestionale sull'host"]
    B -->|"Richiesta di ricerca o di file"| C["Database e cartelle condivise"]
    C -->|"La risposta che l'applicazione attende"| B

Figura 4: L’applicazione gestionale oltre la connessione RDP può a sua volta attendere una risposta da un altro server ancora.

Inoltre, quando il codice responsabile dello schermo e dell’input di un’applicazione si assume un compito lungo, non riesce a passare all’input o all’aggiornamento di schermo successivo. Un thread di interfaccia WPF che resta occupato a lungo produce esattamente questo tipo di risposta ritardata. Guardare solo l’utilizzo complessivo della CPU può lasciarvi ciechi davanti a un’attesa nel codice che gestisce lo schermo.⁵

Il fatto che stiate aspettando davanti a uno schermo RDP non significa che sia RDP a farvi aspettare. Quella differenza fra «il Blocco note funziona ma si blocca solo la ricerca» è un indizio che potete trovare prima di modificare qualunque impostazione di rete.

4. Bilancio provvisorio: la velocità del collegamento è solo una parte della reattività

Torniamo alla domanda iniziale: perché è lento se il collegamento è veloce?

Nel caso della digitazione c’era un’attesa di risposta fra l’invio dell’azione e la ricezione del risultato. Nel caso dello scorrimento è aumentata la quantità di schermo da aggiornare e inviare. E l’applicazione che produce quello schermo, insieme all’elaborazione grafica sui PC alle due estremità, richiede anch’essa tempo.

Un numero grande in un test di velocità non vi dice da solo se questi tre elementi siano in buono stato. Per di più, il server del test di velocità e l’host RDP che sta oltre una VPN o un gateway si raggiungono attraverso percorsi diversi. Concorrono anche la direzione in uscita sull’host che spinge fuori lo schermo e la congestione lungo il tragitto.¹⁴

Quanto RDP risulti confortevole è deciso non solo da quanto si può trasportare, ma da quanto rapidamente il risultato di un’azione diventa visibile. Qui finisce la spiegazione del meccanismo. Quando indagate davvero sulla lentezza, usate le sezioni di analisi qui sotto per scegliere il confronto adatto al vostro sintomo.

5. Analisi: per prima cosa confrontate la stessa azione, una condizione alla volta

Gli esempi di analisi presuppongono il client Connessione Desktop remoto di Windows e un host con Windows 11 o Windows Server. Gli esempi di comandi sono rivolti a Windows PowerShell 5.1. Su un dispositivo aziendale, mantenete i confronti entro l’ambito consentito dalla vostra amministrazione e salvate il lavoro prima di modificare impostazioni e riconnettervi.

Usate i tre casi precedenti come punto d’ingresso per scegliere un confronto. La tabella non è un verdetto sulla causa ma un punto di partenza per l’analisi.

Se la schermata di accesso impiega molto a comparire, o se tutto si blocca alla sola autenticazione, cominciate esaminando le registrazioni relative all’instaurazione della connessione e all’autenticazione. Il punto d’ingresso di quell’analisi è diverso dall’input e dallo scorrimento dopo la connessione trattati qui.

Un’altra applicazione è ritardata allo stesso modo?

Digitate all’incirca la stessa quantità di testo nell’applicazione problematica e nel Blocco note. Confrontare prima all’interno della stessa sessione remota vi permette di vedere la differenza fra applicazioni senza cambiare host o collegamento. In Gestione attività, controllate CPU, memoria e disco dell’applicazione interessata sull’host, e il carico del client RDP sulla vostra macchina.⁴

Quando confrontate su un altro client o su un altro percorso consentito, ripetete lì la stessa azione e registrate anche il risultato dopo aver annullato. Su un host usato da più utenti, assicuratevi di guardare la vostra sessione e i vostri processi.

flowchart TB
    accTitle: Limitate le condizioni che cambiate in una volta
    accDescr: Un flusso che fissa un'azione che riproduce il problema nello stato iniziale, cambia una sola condizione e confronta, poi verifica anche il risultato dopo l'annullamento.
    A["Stessa azione con le impostazioni originali"] --> B["Cambiare una sola condizione"]
    B --> C["Ripetere la stessa azione"]
    C --> D["Annullare e verificare di nuovo"]
    D --> E["Registrare la condizione che ha migliorato le cose"]

Figura 5: Ripetete la stessa azione nello stato iniziale, dopo la modifica e dopo l’annullamento, e registrate quale condizione ha fatto la differenza.

Anche confrontare lavorando allo schermo fisico dell’host è istruttivo. Notate però che sessione e condizioni di disegno possono differire fra il lavoro locale e RDP. Allineate utente, dati e stato dell’applicazione, e non attribuite la causa al collegamento solo perché «allo schermo fisico è veloce».

Quando lo scorrimento è fiacco, abbassate la risoluzione sul lato remoto

Cambiate prima o il numero di monitor o la risoluzione, poi scorrete la stessa pagina. Con mstsc su Windows potete confrontare tramite le impostazioni di visualizzazione prima di connettervi oppure specificando larghezza e altezza. Verificate che il desktop dell’host abbia davvero cambiato dimensione, non che sia soltanto rimpicciolita la finestra sulla vostra macchina. A volte uno schermo grande viene semplicemente mostrato in scala ridotta.⁶⁷

3840 × 2160 ha quattro volte i pixel di 1920 × 1080, ma ciò non significa che il traffico sia sempre quadruplo. Varia con le regioni che cambiano e con quanto bene funziona la compressione. Abbassare la risoluzione cambia anche l’elaborazione grafica alle due estremità, non solo il traffico, quindi se migliora le cose prendetelo come l’ambito in cui si trova l’indizio.²³

flowchart TB
    accTitle: Che cosa può dire un confronto a risoluzione ridotta
    accDescr: Abbassare la risoluzione sul lato remoto può cambiare sia l'elaborazione grafica sia il carico di trasferimento, quindi un miglioramento da solo non può attribuire la causa al collegamento.
    A["Abbassare la risoluzione sul lato remoto"] --> B["L'elaborazione grafica sull'host cambia"]
    A --> C["La quantità di informazioni inviate cambia"]
    A --> D["L'elaborazione di visualizzazione sulla vostra macchina cambia"]

Figura 6: Cambiare la risoluzione è un confronto che riguarda non solo il collegamento ma anche l’elaborazione grafica sull’host e sulla vostra macchina.

Cambiare più condizioni in una volta, per esempio passare a un solo schermo a bassa risoluzione, dà solo un confronto grossolano. Dopo il miglioramento, annullate una alla volta per separare gli effetti, e scegliete le impostazioni di tutti i giorni tenendo conto anche della leggibilità del testo.

Rallenta appena parte una copia o una stampa?

Su RDP scorre più dello schermo: viaggiano anche le informazioni per unità, stampanti e altri dispositivi. Il reindirizzamento, che rende utilizzabili i vostri dispositivi locali sul lato remoto, può aumentare il carico di rete e di elaborazione mentre è in uso. Sospendete copie, sincronizzazioni cloud e stampe che avete avviato voi, entro i limiti di quanto vi è consentito, e confrontate.⁴

flowchart TB
    accTitle: Guardare su un'unica cronologia il periodo prima e dopo il disturbo
    accDescr: Registrare la stessa azione e il carico prima di un trasferimento, durante e dopo averlo fermato, e confrontare come il disturbo si leghi a quel lavoro.
    A["Azione e carico prima del trasferimento"] --> B["Azione e carico durante il trasferimento"]
    B --> C["Azione e carico dopo averlo fermato"]
    C --> D["Se disturbo e ritorno alla normalità coincidono"]

Figura 7: Osservate come cambiano la lentezza della stessa azione e il carico prima del trasferimento, durante e dopo averlo fermato.

Potete anche confrontare uno alla volta il reindirizzamento dei dispositivi non necessari. Non è una procedura per disattivare in blocco i dispositivi audio e di input di cui l’attività ha bisogno, né per fermare di vostra iniziativa i processi aziendali di backup o di sicurezza.

6. Analisi: confermate con i numeri dove si trova l’attesa

Confermate con misurazioni i confronti della sezione 5. Per la digitazione guardate i numeri della rete e dell’attesa dell’input; per lo scorrimento, quelli dell’elaborazione grafica.

Dalla vostra macchina: esaminate il giro di rete e la connessione TCP

Quello che segue è un esempio sul vostro client Windows. Presuppone che vi connettiate direttamente all’host RDP tramite la LAN aziendale o una VPN consentita, e che l’host usi la porta TCP standard 3389. Passare per un gateway RD o per Azure Virtual Desktop cambia sia ciò che verificate sia il percorso seguito. Non esponete porte e non modificate le impostazioni del firewall.

$target = Read-Host 'Nome o indirizzo IP di un host RDP che vi è consentito analizzare'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Indicare l''host a cui connettersi.'
}

# Guardare più volte il tempo di risposta ICMP. Un solo fallimento non prova che RDP sia irraggiungibile.
ping.exe -n 20 $target

# Una verifica limitata alle configurazioni che si connettono direttamente alla porta TCP standard 3389.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

ping esamina il tempo di risposta a ICMP. Se i valori oscillano molto nella fascia oraria lenta, registratelo. ICMP può anche essere bloccato, e in tal caso non risponde nulla. Viceversa, una serie di valori piccoli non significa che abbiate esaminato il trasferimento grafico di RDP o l’elaborazione dell’applicazione.⁸

TcpTestSucceeded: True è un risultato che dice che la connessione TCP a quella porta è riuscita. Non misura né la banda, né UDP, né quanto siano fluidi l’uso e lo schermo dopo l’autenticazione. Test-NetConnection non ha un’opzione -UDP per esaminare UDP.⁹

Venti sonde ping sono un’osservazione breve. Per disturbi intermittenti, confrontate l’orario del sintomo con le informazioni di connessione. Azure Virtual Desktop rende disponibili anche RTT e banda stimata per singola connessione, ma non escludete brevi blocchi sulla sola base delle medie.¹

Sull’host: esaminate l’attesa finché l’applicazione preleva l’input

Aprite perfmon.exe all’interno della sessione remota sull’host e, dove l’ambiente lo supporta, aggiungete User Input Delay per Process o User Input Delay per Session. Selezionare la sessione e il processo interessati vi permette di osservare l’attesa fra l’accodamento dell’input e il suo prelievo da parte dell’applicazione.¹⁰

flowchart TB
    accTitle: L'intervallo che misura User Input Delay
    accDescr: L'intervallo misurato va dalla coda di input sull'host fino al prelievo dell'input da parte dell'applicazione, e non comprende né la rete né la visualizzazione dello schermo prima e dopo.
    A["L'input arriva dalla vostra macchina"] --> B["Entra nella coda di input sull'host"]
    B -->|"Questo è ciò che si misura"| C["L'applicazione preleva l'input"]
    C --> D["Elaborazione dell'applicazione e trasferimento grafico"]
    D --> E["Visualizzato sulla vostra macchina"]

Figura 8: Ciò che si misura è l’attesa nella coda di input sull’host. Non è il tempo complessivo finché il risultato diventa visibile sulla vostra macchina.

Il valore è l’attesa più lunga entro l’intervallo di misura. È supportato da Windows 10 versione 1809 in poi e da Windows Server 2019 in poi, e su quei bersagli non serve alcuna voce di registro per abilitarlo. Osservate per cominciare con l’intervallo predefinito di un secondo. Verificate i nomi visualizzati, i contatori disponibili e le autorizzazioni necessarie rispetto al vostro ambiente.¹⁰

Il nome di istanza standard per processo è SessionID:ProcessID <Process Image>. Da PowerShell nella stessa sessione, annotate l’orario e l’ID di sessione.¹⁰¹¹

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

Visualizzare le sessioni di altri utenti può richiedere autorizzazioni aggiuntive. Confrontate con le registrazioni dell’amministrazione se necessario, e togliete dai log che condividete i nomi utente e le informazioni sull’host di cui l’attività non ha bisogno.¹¹

Anche quando questo valore è basso, restano sia l’elaborazione successiva al prelievo dell’input da parte dell’applicazione sia il ritardo finché lo schermo risultante torna indietro. L’intervallo che misura è diverso dal tempo di andata e ritorno della sezione 1 e dal tempo percepito fra la pressione di un tasto e la comparsa del carattere.

Sull’host: esaminate se gli aggiornamenti dello schermo vengono inviati per intero

Per gli scatti durante lo scorrimento, usate i contatori RemoteFX Graphics dove sono disponibili. Verificate il nome della sessione interessata con query session o qwinsta e selezionate l’istanza corrispondente. Dove un contatore misura e se sia disponibile vanno confermati rispetto al sistema operativo, alla configurazione dell’host e alle vostre autorizzazioni.³

Durante un’operazione che aggiorna lo schermo, confrontate Input Frames/Second con Output Frames/Second. Se l’uscita è inferiore all’ingresso, lungo il percorso si perdono fotogrammi. Guardare i valori di Frames Skipped/Second suddivisi per risorse insufficienti di host, rete e client vi dà un indizio per circoscrivere dove indagare.³

flowchart TB
    accTitle: Circoscrivere dove indagare a partire dai fotogrammi persi
    accDescr: Confrontare il numero di fotogrammi in ingresso e in uscita durante un'operazione che aggiorna lo schermo e, usando come indizio i contatori del motivo della perdita, confrontare con il carico di elaborazione, di rete e di visualizzazione.
    A["Confrontare ingresso e uscita durante lo scorrimento"] --> B["Se l'uscita è più bassa, cercare fotogrammi persi"]
    B --> C["Guardare i contatori suddivisi per motivo"]
    C --> D["Confrontare con il carico di host, rete e macchina locale"]

Figura 9: Confrontate ingresso e uscita durante lo scorrimento e confrontate il motivo dei fotogrammi persi con il carico sull’host, sul collegamento e sulla vostra macchina.

Quando il numero di fotogrammi è basso già in ingresso, può darsi semplicemente che l’applicazione non aggiorni spesso lo schermo. Un numero basso di fotogrammi su uno schermo statico non è anomalo. Se ci sono aggiornamenti ed è comunque lento, guardate anche Average Encoding Time per vedere se la compressione sull’host richiede tempo.³

Una nota sulla lettura della documentazione di misura. Il diagramma della sezione 1 è concettuale, per capire un normale trasferimento grafico, non l’affermazione che venga inviato un pacchetto di andata e ritorno indipendente per ogni tasto. Alcune configurazioni trasferiscono video e audio tramite un meccanismo separato. Usate i log sulla qualità della connessione di Azure Virtual Desktop, e la documentazione dei contatori Graphics che copre ancora configurazioni più vecchie, solo dopo aver confermato a che cosa si applichi la funzione. Non leggete i numeri di tale documentazione come una specifica comune del tipo «tutto RDP è limitato a 30 fps».²¹³

7. Analisi: scegliete le impostazioni UDP e GPU in base a ciò che avete trovato

Se la rete è sospetta, confermate prima il percorso e il trasporto effettivi

RDP usa TCP o UDP a seconda della configurazione e delle condizioni di rete. Il criterio «Seleziona protocolli di trasporto RDP» consente di scegliere fra un’impostazione che usa UDP o TCP e una che usa solo TCP. Poiché esiste anche un comportamento che usa TCP quando non è possibile stabilire una connessione UDP, il fatto che vi siate connessi non dice nulla sul trasporto. Confermatelo dalle informazioni di connessione del client, dai log diagnostici del prodotto e dalle registrazioni di rete dell’amministrazione.¹²

flowchart TB
    accTitle: Confermare il trasporto prima di confrontare le impostazioni di rete
    accDescr: Distinguere una normale connessione diretta da una che passa per un gateway o un servizio, confermare il percorso e il trasporto effettivi e solo allora eseguire i confronti consentiti.
    A["Il client in uso e la configurazione di connessione"] --> B["Confermare il percorso effettivo e se sia TCP o UDP"]
    B --> C["Confrontare con l'orario del sintomo"]
    C --> D["Confrontare una alla volta solo le impostazioni necessarie"]

Figura 10: Confermate trasporto e percorso in uso, confrontateli con il sintomo e solo allora confrontate le impostazioni necessarie.

RDP Shortpath in Azure Virtual Desktop è il meccanismo che stabilisce un percorso UDP per quel servizio. Compreso il modo in cui vengono usati percorsi diretti e inoltri, non può essere messo nella stessa tabella di impostazioni della connessione diretta a un PC interno con mstsc. Quando Shortpath non può essere stabilito, la connessione ricade su una basata su TCP.¹³

Non modificate le cose in blocco partendo dall’idea che disattivare UDP renda più veloce. Allineate il trasporto in uso, i criteri e le condizioni di VPN o gateway, poi confrontate. Disattivare il firewall o l’autenticazione, o esporre la porta RDP direttamente su Internet, non sono rimedi da applicare.

Se l’elaborazione grafica è sospetta, verificate se la GPU venga usata per quello

Anche quando è presente una GPU, non ne segue che il disegno dell’applicazione host, la codifica di RDP e la decodifica sulla vostra macchina la usino tutti. Anche la documentazione Microsoft sulla configurazione della GPU configura e verifica separatamente il disegno nella sessione remota e la codifica hardware dei fotogrammi. Esaminate le versioni di sistema operativo supportate, i driver, i criteri e i requisiti del client.¹⁴

Se la sezione 6 ha mostrato che il tempo di compressione è lungo, è quello il punto in cui verificare l’uso della GPU per la codifica. Modificare le impostazioni di codifica per un’applicazione che attende nella coda di input mira al posto sbagliato. Un lavoro in cui volete testo leggibile e uno in cui volete video fluido richiedono inoltre scelte diverse fra qualità dell’immagine, traffico e carico di elaborazione.¹⁴²

Chi sviluppa applicazioni gestionali può ricostruire le attese interne a un’applicazione registrando separatamente l’orario di ricezione di un evento di input, l’inizio e la fine delle elaborazioni su database e file, e il momento in cui il risultato ha raggiunto l’interfaccia. Conta anche una progettazione che eviti che il lavoro pesante si depositi sul thread di interfaccia. Notate che un log di «elaborazione completata» sull’host non è una registrazione del completamento della visualizzazione sul vostro schermo.⁵

8. Appunti che vale la pena lasciare quando passate l’analisi ad altri

Descrivete l’azione lenta in modo concreto, come «digitare nel Blocco note è normale, ma scorrere le foto si inceppa». Lasciate anche le condizioni provate e i risultati.

Orario in cui si è verificato il sintomo, con fuso orario:
Sistema operativo dell'host, client in uso e versioni:
Connessione diretta / VPN / gateway RD / Azure Virtual Desktop e così via:
L'azione e l'applicazione lente, e come rispondono le altre applicazioni nella stessa sessione:
Risoluzione e numero di monitor sul lato remoto:
Copie, stampe e simili in corso nello stesso momento:
L'unica condizione cambiata e il risultato dopo l'annullamento:
Carico e contatori osservati sull'host e sulla vostra macchina:

Quanto si può trasportare, quanto si attende una risposta e quanto ci vuole per produrre e mostrare lo schermo. Una volta chiara questa distinzione, si smette di ricondurre «RDP è lento» a una causa unica e si può partire dall’azione che è lenta adesso.

Articoli correlati

• Come ragionare sull’isolamento delle sessioni di Windows
• Circoscrivere in sicurezza un disco Windows al 100%
• Perché «manca 1 secondo» dura così tanto?

Link di riferimento

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Un test di velocità segna centinaia di Mbit/s: perché l'input in RDP è lento?

Quanto velocemente si spostano grandi quantità di dati e quanto tempo impiega un'azione a tornare indietro sono due cose diverse. L'invio dell'input, l'elaborazione dell'applicazione sull'host, la compressione dello schermo, il trasferimento e la visualizzazione sulla vostra macchina concorrono tutti. Inoltre il server del test di velocità e l'host RDP si raggiungono attraverso percorsi di rete diversi.

La digitazione va bene, solo lo scorrimento è a scatti. È un problema di rete?

Non lo si può ricondurre alla sola rete. Quando gli aggiornamenti dello schermo aumentano, il disegno e la compressione sull'host, il trasferimento oppure la decodifica e la visualizzazione sulla vostra macchina potrebbero non stare al passo. Cambiate risoluzione e numero di monitor sul lato remoto uno alla volta e confrontate, poi guardate i contatori grafici se serve.

Se il ping è veloce, la comunicazione RDP è sana?

Questo da solo non lo stabilisce. Il ping misura la risposta a ICMP e non misura né il trasferimento grafico di RDP né l'elaborazione dell'applicazione. Nelle configurazioni che passano per un gateway RD e simili, anche il percorso potrebbe non coincidere. In assenza di risposta, distinguete un ICMP bloccato dal fatto che RDP stesso sia irraggiungibile.

User Input Delay è il tempo fra la pressione di un tasto e la comparsa del carattere?

No. È un contatore che misura quanto a lungo un input attende sull'host, dopo essere stato accodato, prima che il processo lo prelevi. Non è il ritardo percepito, che comprende il giro di andata e ritorno in rete, l'elaborazione dell'applicazione dopo il prelievo dell'input e la compressione, decodifica e visualizzazione dello schermo.

Devo disattivare UDP quando RDP sembra lento?

Non come raccomandazione generale. Verificate prima il trasporto effettivamente in uso, il percorso e i criteri applicati. UDP potrebbe non essere disponibile e la connessione essere ricaduta su TCP, quindi passare al solo TCP non rende sempre le cose più rapide. Confrontate in condizioni equivalenti con il permesso della vostra amministrazione e annullate le modifiche che si rivelano inutili.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.