KomuraSoft LLC
Consultateci
Menu

Perché RDP è lento su una connessione veloce? — Esaminare separatamente input, rendering e rete

· · Windows, RDP, Desktop remoto, Prestazioni, Risoluzione dei problemi

Pubblica su X

Il test di velocità segna centinaia di Mbit/s, eppure in Desktop remoto i caratteri compaiono con un leggero ritardo. Scorrendo una pagina piena di foto, lo schermo si inceppa. Solo quando si preme il pulsante di ricerca di un’applicazione aziendale tutto si ferma per qualche secondo. Da dove conviene partire per indagare su una situazione del genere, in cui «la connessione è veloce, ma RDP è lento»?

La reattività di RDP ai comandi non dipende soltanto dalla velocità di trasferimento della connessione. Anche con un test di velocità rapido, l’attesa può trovarsi nel giro di andata e ritorno della comunicazione, nell’attesa dell’input da parte dell’applicazione sull’host remoto, nella codifica dello schermo oppure nella decodifica e visualizzazione sul computer locale. Per prima cosa distinguete «quale operazione è lenta», poi confrontate la stessa operazione cambiando una sola condizione alla volta. Confronti e misure servono a restringere il campo d’indagine, e le impostazioni di UDP o GPU si scelgono in base ai loro risultati. Vedi: Tratti misurati della qualità di connessione, Fattori che influiscono sulle prestazioni dell’host di sessione.

Restringere il campo d’indagine, però, non significa aver accertato la causa radice. Anche se abbassare la risoluzione migliora la situazione, cambiano non solo la comunicazione ma anche l’elaborazione dello schermo ai due capi, quindi non si conclude che «la causa era la connessione». Registrate i risultati tenendo separati i tratti misurati da quelli non misurati.

Questo articolo circoscrive le cause di lentezza dell’input, dello scorrimento e della risposta delle applicazioni a connessione già stabilita. Anche se i sintomi si somigliano, la causa non è necessariamente una sola. I casi in cui «la schermata di accesso tarda a comparire» o «tutto si ferma all’autenticazione» vanno trattati come un problema diverso, da indagare partendo dai registri di instaurazione della connessione e di autenticazione.

Si rivolge soprattutto a utenti e amministratori che si connettono a Windows 11 o Windows Server dall’applicazione di Windows «Connessione Desktop remoto» (mstsc). Gli esempi di comandi sono pensati per Windows PowerShell 5.1. Si presuppone di poter riprodurre la stessa operazione in una sessione già connessa.

Connessione diretta, VPN, RD Gateway e Azure Virtual Desktop differiscono per percorso, informazioni diagnostiche disponibili e destinazione a cui si applicano le impostazioni. L’esempio di verifica di TCP 3389 vale solo per connessioni dirette autorizzate verso un host RDP che usa la porta standard. Le funzioni diagnostiche e le impostazioni GPU descritte nella documentazione per Azure Virtual Desktop non si applicano così come sono ai normali PC aziendali.

Sui computer aziendali si indaga entro i limiti autorizzati dall’amministratore. Su un host condiviso identificate la vostra sessione e il processo interessato e, se vi servono i dati di altri utenti, chiedeteli all’amministratore. Disponibilità dei contatori delle prestazioni, nomi visualizzati e autorizzazioni necessarie vanno verificati in ogni ambiente.

I metodi di verifica presentati qui si basano sulla documentazione ufficiale. Non si tratta di un resoconto di misure in cui un guasto è stato riprodotto e risolto su un computer specifico. Gli esempi numerici sono indicati come ipotesi a scopo illustrativo.

Per capire il meccanismo potete leggere in ordine a partire dalla sezione successiva, «Velocità di trasferimento e tempo di andata e ritorno». Se volete partire dal sintomo, passate a «Il primo confronto in base al sintomo». Le procedure operative si trovano in «Confrontare una condizione alla volta» e «Misurare dove si attende».

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

Velocità di trasferimento e tempo di andata e ritorno

RDP (Remote Desktop Protocol) è il protocollo che scambia input, informazioni sullo schermo e altri dati tra il computer locale e l’host remoto. Oltre a schermo e input, gestisce anche le informazioni del reindirizzamento dei dispositivi, della stampa e così via. Vedi: Informazioni trasferite da RDP.

La velocità di trasferimento di una connessione indica quanti dati può trasportare in un secondo. I «500 Mbit/s» di un test di velocità sono un valore che riguarda questa quantità. Non è un valore che indica il tempo che passa tra un comando e l’arrivo della risposta. Vedi: Requisiti di larghezza di banda di RDP.

Che cosa rappresenta il valore del test di velocitàMostra che i 500 Mbit/s del test di velocità rappresentano la quantità di dati trasportabile in un secondo, un valore diverso dal tempo che passa tra un comando e l'arrivo della risposta.Un altro valoreTest di velocità: 500 Mbit/sDati trasportabili in 1 secondoTempo di arrivo della risposta

Figura 1: Il valore del test di velocità rappresenta la quantità trasportabile, non il tempo che impiega la risposta ad arrivare.

Il tempo di andata e ritorno (RTT) è il tempo che una comunicazione impiega per raggiungere l’altra parte e tornare indietro. Aumentare la velocità di trasferimento e ridurre il tempo di andata e ritorno somiglia alla differenza tra aggiungere corsie a una strada e accorciare la distanza dalla destinazione. Anche se cresce la capacità di trasportare grandi quantità di file, l’attesa della risposta ai comandi resta finché il tempo di andata e ritorno non cambia. Vedi: RTT e ritardo di visualizzazione dello schermo.

Velocità di trasferimento e tempo di andata e ritorno paragonati a una stradaParagona l'aumento della velocità di trasferimento all'aggiunta di corsie a una strada e la riduzione del tempo di andata e ritorno all'accorciamento della distanza dalla destinazione.Per una stradaPer una stradaAumentare la velocità di trasferimentoAggiungere corsieRidurre il tempo di andata e ritornoAccorciare la distanza

Figura 2: Aggiungere corsie non accorcia la distanza dalla destinazione.

Il ritorno di un carattere digitato

Consideriamo il caso in cui si digita un carattere nel Blocco note remoto. Il Blocco note è in esecuzione sull’host remoto. Se, a scopo illustrativo, si ipotizzano 50 millisecondi perché il comando arrivi e 50 millisecondi perché tornino le informazioni sullo schermo risultante, il tempo speso nella comunicazione è in totale di 100 millisecondi, cioè 0,1 secondi. Questo esempio esclude il tempo di elaborazione ai due capi.

Esempio di tempo di comunicazione per il ritorno di un carattereEsempio che ipotizza, a scopo illustrativo, 50 millisecondi all'andata e 50 millisecondi al ritorno. Non include l'elaborazione ai due capi e non rappresenta nemmeno il numero di pacchetti per tasto.Andata: 50 msRitorno: 50 msDigitare un carattere in localeL'host riceve l'inputInviare lo schermo aggiornatoIl risultato arriva in locale

Figura 3: Ipotizzando 50 millisecondi all’andata e 50 al ritorno, la sola comunicazione richiede 0,1 secondi. Non sono valori misurati.

Anche se la quantità che la connessione può trasportare aumenta, questi 0,1 secondi restano finché il tempo di andata e ritorno non cambia. La figura 3 è uno schema concettuale per capire l’elaborazione. Non significa che per ogni tasto venga inviato un giro di pacchetti indipendente. Il server del test di velocità e l’host RDP, inoltre, si raggiungono per percorsi diversi: bisogna considerare anche la VPN, il gateway, la banda in uscita lato host e la congestione lungo il tragitto. Vedi: Come interpretare l’RTT, Prestazioni della rete e dell’host.

Generare lo schermo e consegnarlo

Il ritardo di risposta ai comandi di cui si parla qui è l’attesa tra un’azione sul computer locale e il momento in cui se ne vede il risultato. Non dipende solo dall’RTT, ma anche dall’elaborazione dell’applicazione e dal lavoro che genera lo schermo e lo consegna. Va distinto anche dal ritardo del solo tratto di trasferimento dello schermo. Vedi: Tratto misurato dall’acquisizione dello schermo alla visualizzazione.

Quando l’input arriva dal computer locale all’host remoto, l’applicazione dell’host lo elabora e aggiorna lo schermo, le informazioni sullo schermo codificate viaggiano sulla connessione e il computer locale le decodifica e le visualizza. Anche prima e dopo la comunicazione c’è lavoro, svolto da PC diversi. Vedi: Elaborazioni dall’acquisizione dello schermo alla visualizzazione.

L'elaborazione dello schermo prima e dopo la connessioneFlusso in cui l'input locale arriva all'host, l'applicazione dell'host lo elabora, genera lo schermo e lo comprime, e le informazioni sullo schermo trasportate dalla connessione vengono riportate in locale in una forma visualizzabile e mostrate.Locale: inserire un comandoConnessione: trasporta l'inputHost: l'applicazione elaboraHost: genera e comprime lo schermoConnessione: trasporta lo schermoLocale: riporta in forma visualizzabileVisualizzazione sullo schermo locale

Figura 4: Elaborazione e compressione sull’host, trasporto sulla connessione, ritorno a una forma visualizzabile in locale: ognuno di questi lavori si svolge in un punto diverso.

In questo articolo, per codifica si intende l’elaborazione che sull’host remoto converte e comprime lo schermo in una forma facile da inviare. Oltre al trasferimento sulla connessione, richiede tempo di elaborazione sull’host. Vedi: Tempo di codifica sull’host.

In questo articolo, per decodifica si intende l’elaborazione che riporta le informazioni sullo schermo ricevute in una forma visualizzabile sul computer locale. Va distinta dalla decrittografia, intesa come rimozione della cifratura. Vedi: Tempo di decodifica e visualizzazione in locale.

Se la compressione sull’host richiede tempo, l’invio aspetta di essere pronto anche quando la connessione è libera. Anche se le informazioni sono arrivate, l’aggiornamento resta indietro se la decodifica o la visualizzazione in locale non tengono il passo. Non è detto che «siccome il PC aziendale è potente, il computer locale possa essere qualsiasi». Il margine della connessione e il margine di elaborazione ai suoi due capi sono cose distinte. Vedi: Contatori delle prestazioni per l’elaborazione dello schermo.

Ritardi quando i due capi non tengono il passoMostra che se la compressione sull'host richiede tempo l'invio aspetta anche con la connessione libera, e che se la decodifica o la visualizzazione locale non tengono il passo l'aggiornamento resta indietro anche se le informazioni sono arrivate.Compressione lenta sull'hostL'invio attende anche a rete liberaLa decodifica locale non reggeArrivato, ma aggiornato in ritardo

Figura 5: Anche se la connessione ha margine, l’aggiornamento dello schermo resta indietro se i due capi non tengono il passo.

Differenza tra digitazione e scorrimento

Aggiungere un carattere nel Blocco note cambia solo una piccola parte dello schermo. Scorrendo una pagina piena di foto, invece, la visualizzazione di un’area ampia cambia in continuazione. RDP contiene il volume di traffico trasferendo le parti modificate e usando compressione e cache adatte al contenuto. Non invia ogni volta l’intero schermo senza compressione. La quantità di lavoro cambia in base al contenuto dello schermo e alla frequenza degli aggiornamenti. Vedi: Relazione tra contenuto dello schermo e larghezza di banda.

Lavoro sullo schermo con digitazione e scorrimentoUna piccola modifica del testo e l'aggiornamento continuo di un'area ampia richiedono un lavoro di natura diversa per generare e inviare lo schermo.Aggiunta di un carattereScorrimentoModifica dello schermoArea piccolaArea ampia, di continuoCompressione e invio in base alla modifica

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

Anche se un documento fermo è leggero, durante lo scorrimento il trasferimento dello schermo può restare senza margine. Aumentando la risoluzione o il numero di monitor lato remoto cresce anche lo schermo da elaborare. Il confronto che abbassa la risoluzione è un esperimento: serve a vedere se la fluidità torna riducendo il lavoro di generazione e invio dello schermo. Non è un calcolo che ricava il volume di traffico dal solo numero di pixel. Vedi: Effetti di risoluzione, aggiornamenti dello schermo e compressione.

Le attese dell’applicazione

Se solo la ricerca di un’applicazione aziendale si blocca per qualche secondo, mentre nel Blocco note della stessa sessione si digita normalmente, verificate che cosa sta aspettando quell’applicazione. L’applicazione sull’host può a sua volta inviare una ricerca a un altro database o leggere un file da una cartella condivisa, e restare in attesa della risposta. Si tratta di un percorso distinto dalla comunicazione RDP che collega il computer locale all’host. Vedi: Comunicazione dall’host al back-end.

Oltre RDP ci sono altri interlocutoriMostra il caso in cui, oltre alla comunicazione tra il computer locale e l'host, l'applicazione sull'host attende la risposta di un server aziendale.RDPRicerca, richiesta di fileRisposta attesaComputer localeApplicazione aziendale sull'hostDatabase, cartella condivisa

Figura 7: L’applicazione aziendale che sta oltre RDP può a sua volta attendere la risposta di un altro server.

Quando l’elaborazione che gestisce lo schermo e l’input è occupata da un lavoro lungo, l’input successivo e l’aggiornamento dello schermo restano indietro. In WPF, per esempio, la reattività peggiora se il thread dell’interfaccia resta occupato a lungo. Un uso complessivo della CPU basso non basta a escludere un’attesa su uno specifico thread dell’interfaccia. Vedi: Dispatcher e thread dell’interfaccia.

L'elaborazione di schermo e input si bloccaMostra che se l'elaborazione che gestisce schermo e input è occupata da un lavoro lungo l'input successivo e l'aggiornamento dello schermo restano indietro, e che un uso complessivo della CPU basso non basta a escludere questa attesa.Elaborazione di schermo e inputOccupata da un lavoro lungoInput e aggiornamento successivi in ritardoNon esclusa da una CPU poco carica

Figura 8: Un uso complessivo della CPU basso non basta a escludere un’attesa sul thread dell’interfaccia.

Il primo confronto in base al sintomo

La quantità trasportabile, il tempo di attesa della risposta e il tempo per generare e visualizzare lo schermo sono cose distinte. Mantenendo questa distinzione non si riduce «RDP è lento» a una sola causa e si può partire dall’operazione che è lenta in quel momento.

Separare i tre aspetti prima di indagareMostra che, invece di ridurre «RDP è lento» a una sola causa, si separano quantità trasportabile, tempo di attesa della risposta e tempo per generare e visualizzare lo schermo, partendo dall'operazione lenta in quel momento.Esaminare separatamenteTempo di attesa della rispostaQuantità trasportabileTempo per generare e mostrare lo schermo«RDP è lento»Partire dall'operazione lenta

Figura 9: Separando quantità trasportabile, tempo di attesa della risposta e tempo per generare e visualizzare lo schermo, si può partire dall’operazione lenta in quel momento.

Lo scopo del circoscrivere è limitare i punti in cui cercare la lentezza. Non si punta a rendere tutto più veloce per caso cambiando le impostazioni in blocco. Sfruttando differenze come «il Blocco note risponde, ma la ricerca si blocca» o «la digitazione è normale, ma solo lo scorrimento è pesante», si può scegliere da dove iniziare l’indagine anche prima di toccare le impostazioni di rete.

La tabella seguente è un punto di partenza per l’indagine. Non è una tabella che stabilisce la causa. Confrontate prima le operazioni nella stessa sessione, poi cambiate computer, percorso o condizioni di visualizzazione secondo necessità.

Sintomo osservato Primo confronto Dove guardare dopo
In più applicazioni ogni carattere compare in ritardo Un altro computer o un altro percorso autorizzato verso lo stesso host Tempo di andata e ritorno, attesa dell’input, carico complessivo dell’host
La digitazione è normale, ma lo scorrimento va a scatti Risoluzione o numero di monitor lato remoto Compressione sull’host, trasferimento dello schermo, decodifica in locale
Si blocca una sola applicazione Il Blocco note o un’altra applicazione della stessa sessione risponde? Elaborazione di quell’applicazione, disco, comunicazione oltre l’host
Tutti sono lenti solo nelle ore in cui aumentano gli utenti Le altre sessioni sono lente nella stessa fascia oraria? CPU, memoria e storage dell’host condiviso, connessione condivisa
Rallenta quando si avvia una copia o una stampa Sospendendo il vostro trasferimento la situazione torna normale? Competizione tra trasferimenti o reindirizzamento dei dispositivi e traffico dello schermo

Caratteri in ritardo in più applicazioni

Se in più applicazioni della stessa sessione ogni carattere compare in ritardo, confrontate la stessa operazione anche da un altro computer o attraverso un altro percorso autorizzato. Mettete a confronto tempo di andata e ritorno, attesa dell’input sull’host e carico complessivo dell’host, senza stabilire la causa in base a un solo valore.

Solo lo scorrimento va a scatti

Anche se la digitazione è normale, scorrendo una pagina piena di foto gli aggiornamenti dello schermo su un’area ampia si susseguono. Cambiate la risoluzione o il numero di monitor lato remoto, uno alla volta, e confrontate sulla stessa pagina. Se la situazione migliora, i prossimi oggetti d’indagine sono la compressione sull’host, il trasferimento dello schermo e la decodifica in locale. La sola risoluzione non dice quale dei tre sia la causa. Vedi: Carico in base a contenuto dello schermo e risoluzione.

Una sola applicazione si blocca

Se si blocca solo l’applicazione aziendale in cui avete premuto il pulsante di ricerca, verificate per confronto se il Blocco note o un’altra applicazione della stessa sessione risponde. Se le altre applicazioni funzionano, esaminate prima l’elaborazione dell’applicazione interessata, il disco e le richieste verso il database o la cartella condivisa. Lavorare tramite RDP e avere la comunicazione RDP come causa dell’attesa sono due cose diverse. Vedi: Fattori di prestazioni dell’applicazione e del back-end.

Tutti lenti quando aumentano gli utenti

Se più utenti rallentano nella stessa fascia oraria, chiedete all’amministratore la situazione delle altre sessioni. Mettete in relazione il carico di CPU, memoria e storage dell’host condiviso e quello della connessione condivisa con l’orario dei sintomi. Non si accede senza autorizzazione ai dati o alle elaborazioni di altri utenti e non se ne interrompono i processi. Vedi: Risorse dell’host condiviso e numero di utenti.

Rallentamenti durante copia o stampa

Se il momento in cui avete avviato una copia o una stampa coincide con il malfunzionamento, sospendete soltanto i trasferimenti che siete autorizzati a interrompere e confrontate. Annotate se la situazione torna normale dopo la sospensione e se peggiora alla ripresa, quindi esaminate la competizione con i trasferimenti diversi dallo schermo e con il reindirizzamento dei dispositivi. Non si fanno confronti che disattivano in blocco i dispositivi necessari al lavoro. Vedi: Effetti del reindirizzamento dei dispositivi.

Confrontare una condizione alla volta

Non è necessario cambiare tutte le impostazioni una dopo l’altra. Prima si stabilisce una base di confronto, poi si scelgono solo le verifiche adatte al sintomo. Prima di modificare un’impostazione o riconnettervi, salvate il lavoro e annotate il valore originale e il modo per ripristinarlo. Se mancano le autorizzazioni o le funzioni necessarie, non si forza l’attivazione e si passa la questione all’amministratore.

Un’operazione locale e un’operazione via RDP non avvengono necessariamente nelle stesse condizioni. Che l’operazione sia veloce sullo schermo fisico dell’host è un’indicazione utile, ma la sessione e le condizioni di rendering possono cambiare. Allineate utente, dati e stato dell’applicazione, e non limitate la causa alla connessione solo perché «sullo schermo fisico è veloce».

Confrontare la stessa operazione

Si preparano lo stesso utente, gli stessi dati e la stessa operazione. Su un host condiviso si verifica la propria sessione e non si interrompono applicazioni o elaborazioni di altri utenti. Anche l’uso di un altro computer o di un altro percorso resta entro i limiti autorizzati dall’amministratore.

  1. Riproducete l’operazione lenta con le impostazioni originali e annotate l’ora e il sintomo.

    Nel Blocco note della stessa sessione remota dell’applicazione problematica, digitate più o meno la stessa quantità di caratteri. Così distinguete se il problema riguarda una sola applicazione o l’intera sessione.

  2. Verificate il carico dell’host e quello del computer locale nella stessa fascia oraria.

    In Gestione attività osservate sull’host CPU, memoria e disco dell’applicazione interessata e sul computer locale il carico del client RDP. Controllate il processo interessato, non solo il valore complessivo della CPU. Vedi: Che cosa esaminare per il carico.

  3. Cambiate una sola condizione tra un altro computer, un altro percorso autorizzato e le condizioni di visualizzazione, poi ripetete la stessa operazione.

    Se il confronto cambia nello stesso momento anche lo stato dell’host o dell’applicazione, annotate anche questa differenza. Non si considera il risultato di più condizioni cambiate come l’effetto di una sola.

  4. Tornate alle condizioni originali e verificate di nuovo la stessa operazione.

    Se tutto resta veloce anche dopo il ripristino, si può pensare tra l’altro a una variazione temporanea del carico. Non date per scontato che la modifica abbia funzionato: annotate le condizioni in cui il sintomo si ripresenta.

Avendo i risultati dello stato originale, dello stato modificato e dello stato ripristinato, potete confrontare quali condizioni corrispondono al sintomo. Una condizione che ha migliorato la situazione è un indizio per l’indagine; da sola non prova la causa radice.

Limitare le condizioni cambiate alla voltaFlusso che fissa l'operazione da riprodurre nello stato originale, cambia una sola condizione per confrontare e verifica anche il risultato dopo il ripristino.Stessa operazione, impostazioni originaliCambiare una sola condizioneRipetere la stessa operazioneRipristinare e verificare di nuovoAnnotare la condizione che migliora

Figura 10: Si ripete la stessa operazione nello stato originale, dopo la modifica e dopo il ripristino, e si annota la condizione che ha cambiato il risultato.

Confrontare la risoluzione remota

Questo confronto serve quando gli aggiornamenti dello schermo sono pesanti, per esempio durante lo scorrimento. Annotate risoluzione e numero di monitor prima della modifica, salvate il lavoro e poi riconnettetevi. Non si mantiene come impostazione abituale una configurazione che compromette lo schermo necessario al lavoro o la leggibilità del testo.

  1. Cambiate solo uno dei due: il numero di monitor o la risoluzione.

    Con mstsc potete confrontare tramite le impostazioni della scheda «Schermo» prima della connessione oppure indicando larghezza e altezza. Vedi: Opzioni di schermo di mstsc.

  2. Verificate che la dimensione effettiva del desktop dell’host sia cambiata, poi scorrete la stessa pagina.

    Se vi limitate a rimpicciolire la finestra locale, può darsi che un desktop grande venga solo mostrato ridotto. Distinguete la risoluzione dinamica dallo smart sizing e verificate le condizioni di supporto del client che usate. Vedi: Risoluzione del desktop e fattore di scala.

  3. Tornate all’impostazione originale, ripetete la stessa operazione e confrontate il carico ai due capi e il movimento dello schermo.

    Se siete passati in un colpo solo a una bassa risoluzione e a un unico monitor, il confronto resta approssimativo. Se la situazione migliora, ripristinate un’impostazione alla volta per separarne gli effetti.

Se la situazione migliora, gli indizi riguardano l’elaborazione e il trasferimento dello schermo. Una risoluzione di 3840×2160 ha quattro volte i pixel di 1920×1080, ma il volume di traffico non diventa sempre quattro volte maggiore. Varia in base alle parti modificate e alla compressione, e il cambio di risoluzione influisce anche sull’elaborazione ai due capi. Vedi: Relazione tra numero di pixel e volume di traffico, Verifica dell’elaborazione dello schermo.

Che cosa rivela il confronto a risoluzione ridottaAbbassare la risoluzione remota può cambiare il carico sia dell'elaborazione dello schermo sia del trasferimento, quindi un miglioramento da solo non permette di limitare la causa alla connessione.Elaborazioni che cambianoQuantità di informazioni inviateElaborazione dello schermo sull'hostVisualizzazione in localeAbbassare la risoluzione remota

Figura 11: Cambiare la risoluzione è un confronto che influisce non solo sulla connessione, ma anche sull’elaborazione dello schermo sull’host e in locale.

Mettere in relazione copia, stampa e sintomi

Si sospendono solo le elaborazioni che si è autorizzati a interrompere, come i trasferimenti avviati da sé. Non si interrompono i backup e le elaborazioni di sicurezza dell’azienda né i processi di altri utenti. Non si disattiva in blocco il reindirizzamento dei dispositivi audio e di input necessari al lavoro.

  1. Prima e durante una copia, una sincronizzazione cloud o una stampa, annotate il comportamento della stessa operazione e il carico.

    Oltre allo schermo, in RDP passano anche informazioni su unità, stampanti e altro. Il reindirizzamento, che permette di usare sull’host i dispositivi del computer locale, può aumentare il carico di rete e di elaborazione mentre è in uso. Vedi: Effetti del reindirizzamento dei dispositivi.

  2. Sospendete il trasferimento interessato entro i limiti autorizzati e verificate di nuovo la stessa operazione.

    Se potete riprendere il trasferimento per confrontare, annotate anche il sintomo dopo la ripresa. Anche quando fate prove sui reindirizzamenti di dispositivi non necessari, cambiateli uno alla volta in modo da poter tornare alle impostazioni originali.

Potete valutare se l’avvio del trasferimento corrisponde al malfunzionamento e la sospensione al ripristino. Se emerge una corrispondenza, confrontate i trasferimenti diversi dallo schermo e il carico delle risorse condivise con i registri dell’amministratore.

Collocare il malfunzionamento sulla stessa linea temporaleSi annotano la stessa operazione e il carico prima, durante e dopo il trasferimento, e si confronta il rapporto tra il malfunzionamento e il lavoro in corso.Operazione e carico prima del trasferimentoOperazione e carico durante il trasferimentoOperazione e carico dopo l'arrestoMalfunzionamento e ripresa coincidono?

Figura 12: Si osserva come cambiano la lentezza della stessa operazione e il carico prima, durante e dopo il trasferimento.

Misurare dove si attende

Dal computer locale si esaminano il giro di andata e ritorno della comunicazione e la connessione TCP; sull’host, l’attesa nella coda di input e gli aggiornamenti dello schermo. Ogni valore misura solo un tratto limitato, quindi leggete i risultati alla luce della tabella in «Portata dei risultati di misura».

Verificare ICMP e connessione TCP

I comandi si eseguono sul computer Windows locale. Riguardano solo le configurazioni in cui ci si connette direttamente, dalla LAN aziendale o da una VPN autorizzata, a un host RDP che usa la porta standard TCP 3389. Nelle configurazioni che passano per RD Gateway o Azure Virtual Desktop, o che usano una porta personalizzata, stabilite con l’amministratore che cosa verificare. Non si aprono porte e non si modifica il firewall.

  1. Inserite l’host autorizzato e annotate i risultati della risposta ICMP e della connessione TCP.

    $target = Read-Host 'Nome o indirizzo IP del computer RDP autorizzato per questa indagine'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Specificare il computer a cui connettersi.'
}
    
# Osservare più volte il tempo di risposta ICMP. Un errore da solo non dimostra che RDP sia irraggiungibile.
ping.exe -n 20 $target
    
# Verifica valida solo per connessioni dirette alla porta TCP 3389 standard.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

  2. Mettete in relazione i risultati delle ore lente e quelli normali con l’orario dei sintomi e con il percorso di connessione effettivo.

    Venti esecuzioni di ping sono un’osservazione breve. Annotate le oscillazioni dei valori e le mancate risposte, tenendo presente che ICMP può essere bloccato. Non escludete interruzioni intermittenti in base alla sola media: usate le informazioni di connessione e i registri di rete dell’amministratore. Vedi: Che cosa misura ping.

TcpTestSucceeded: True significa che la connessione TCP alla porta indicata è riuscita. Larghezza di banda, UDP, operazioni dopo l’autenticazione e fluidità dello schermo non vengono misurate. Test-NetConnection non ha uno switch -UDP per esaminare UDP. Vedi: Sintassi e risultati di Test-NetConnection.

Si giudica tenendo presenti le differenze di percorso e di servizio. Con RD Gateway e soluzioni simili, il percorso di ICMP o della connessione TCP diretta verso l’host può non coincidere con il percorso RDP effettivo. In Azure Virtual Desktop sono disponibili l’RTT e una stima della larghezza di banda per ogni connessione, ma queste funzioni diagnostiche sono specifiche di quel servizio. Non si escludono brevi interruzioni in base alla sola media. Vedi: Log della qualità di connessione di Azure Virtual Desktop.

Percorso verificato e percorso RDP effettivoNelle configurazioni che usano RD Gateway o soluzioni simili, il percorso di ICMP o della connessione TCP diretta dal computer locale all'host può non coincidere con il percorso RDP effettivo.ICMP, TCP direttoRDP effettivoComputer localeHost RDPRD Gateway o simili

Figura 13: ICMP o la connessione TCP diretta verso l’host e l’RDP effettivo non sempre seguono lo stesso percorso.

Misurare l’attesa nella coda di input

User Input Delay misura l’attesa tra il momento in cui un input entra nella coda sull’host e quello in cui il processo lo preleva. Non è il tempo totale tra la pressione di un tasto e la comparsa del carattere. Vedi: Definizione di User Input Delay.

La verifica si fa all’interno della sessione remota sull’host. Secondo Microsoft il contatore è supportato da Windows 10 versione 1809 e da Windows Server 2019 in poi. Su questi sistemi non serve aggiungere voci al Registro di sistema per attivarlo. Verificate nome visualizzato, autorizzazioni e presenza del contatore; se non è disponibile, annotatelo e consultate l’amministratore. Vedi: Requisiti di supporto e configurazione.

  1. In PowerShell, nella stessa sessione, annotate l’ora e l’ID di sessione.

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

    Per interrogare le sessioni di altri utenti possono servire autorizzazioni aggiuntive. Il nome di istanza standard del processo interessato è SessionID:ProcessID <Process Image>. Evitate di mescolare, basandovi sul solo ID di sessione, i valori di altri utenti o di processi con lo stesso nome. Vedi: Autorizzazioni di query session, Identificazione delle istanze.

  2. In perfmon.exe aggiungete User Input Delay per Process oppure User Input Delay per Session, a seconda di quale sia disponibile.

    Selezionate il processo o la sessione interessati e osservate inizialmente con l’intervallo predefinito di 1 secondo. Distinguete l’istanza aggregata, che riunisce più sessioni, dai valori delle singole sessioni.

  3. Riproducete l’operazione con l’input lento e confrontate l’attesa in coda con l’orario del sintomo.

    Per un singolo oggetto di misura si osserva il tempo di attesa massimo nell’intervallo di misura. Anche se il valore è basso, restano l’elaborazione dopo che l’applicazione ha prelevato l’input e il ritardo con cui il risultato torna al computer locale.

Potete così verificare se l’attesa avviene nella coda di input dell’host. È un indicatore diverso dal tempo percepito, che include il giro di andata e ritorno della comunicazione e la visualizzazione in locale. Vedi: Significato del valore massimo e dell’intervallo di misura.

Il tratto misurato da User Input DelayIl tratto misurato va dalla coda di input dell'host al prelievo da parte dell'applicazione; la comunicazione e la visualizzazione dello schermo prima e dopo non sono incluse.Si misura quiL'input arriva dal computer localeEntra nella coda di input dell'hostL'applicazione preleva l'inputElaborazione e invio dello schermoVisualizzazione in locale

Figura 14: Si misura l’attesa nella coda di input dell’host. Non è il tempo totale fino a quando il risultato è visibile in locale.

Esaminare aggiornamenti dello schermo e motivi dei frame saltati

Preparate un’operazione che produca aggiornamenti continui dello schermo, come lo scorrimento. La disponibilità dei contatori RemoteFX Graphics e il punto in cui misurano vanno verificati in base a sistema operativo, configurazione dell’host e autorizzazioni. Qui ci si limita a leggere i contatori disponibili. Non è una procedura per installare o attivare la vecchia funzionalità RemoteFX. Vedi: Condizioni di applicabilità dei contatori Graphics.

  1. Verificate il nome della sessione interessata con query session o qwinsta e selezionate l’istanza di contatore corrispondente.

  2. Durante un’operazione che aggiorna lo schermo, confrontate Input Frames/Second e Output Frames/Second.

    Se l’output è inferiore all’input, alcuni frame dello schermo vengono saltati lungo il percorso. Controllate i valori di Frames Skipped/Second suddivisi per mancanza di risorse: host, rete o client.

  3. Mettete in relazione i motivi dei frame saltati con il carico ai due capi e sulla rete, e controllate anche Average Encoding Time.

    Se il tempo di codifica è lungo, esaminate la compressione sull’host. Se il numero di frame è basso già sul lato input, è possibile anche che l’applicazione non aggiorni spesso lo schermo. Un numero di frame basso con lo schermo fermo non è di per sé un’anomalia.

Gli input e output durante gli aggiornamenti dello schermo, i motivi dei frame saltati e il tempo di codifica permettono di restringere il campo d’indagine. La classificazione dei contatori è un indizio: si giudica insieme al carico effettivo e alla configurazione di connessione. Vedi: Come leggere numero di frame e tempo di codifica.

Restringere l'indagine partendo dai frame saltatiDurante un'operazione che aggiorna lo schermo si confronta il numero di frame in input e in output e, basandosi sui contatori dei motivi dei frame saltati, si mettono in relazione i risultati con il carico di elaborazione, rete e visualizzazione.Confrontare input e output scorrendoOutput basso: verificare i frame saltatiGuardare i contatori per motivoConfronto con carico host, rete, locale

Figura 15: Si confrontano input e output durante lo scorrimento e si mettono in relazione i motivi dei frame saltati con il carico dell’host, della connessione e del computer locale.

Non si generalizzano a tutte le configurazioni lo schema concettuale del trasferimento dello schermo né la documentazione datata. Esistono configurazioni che trasferiscono video e audio con un meccanismo separato. La documentazione dei contatori Graphics descrive anche configurazioni datate, quindi non si trasformano i valori riportati in una specifica comune del tipo «ogni RDP arriva al massimo a 30 fps». Verificate a che cosa si applicano funzionalità e valori prima di usarli. Vedi: Trasferimento dello schermo e carichi di lavoro, Documentazione dei contatori Graphics.

Portata dei risultati di misura

Non si identifica un valore basso con un’operatività confortevole. La portata di ogni indicatore si può verificare nella documentazione Microsoft indicata nelle procedure.

Risultato osservato Che cosa si sa Che cosa non si sa ancora
La risposta del ping è breve Il tempo di risposta ICMP verso quella destinazione Il corretto funzionamento dell’intero percorso RDP effettivo, dell’elaborazione dell’applicazione e della visualizzazione dello schermo
TcpTestSucceeded è True La riuscita della connessione TCP verso la destinazione e la porta indicate UDP, larghezza di banda, risposta dopo l’autenticazione
User Input Delay è alto L’attesa nella coda di input dell’host interessato L’elaborazione dopo il prelievo dell’input e il ritardo totale fino al computer locale
Pochi frame in output durante gli aggiornamenti I frame saltati e un indizio per cercarne il motivo Un’unica causa radice; serve il confronto con i registri dei due capi e della rete
Abbassare la risoluzione migliora la situazione Una possibile corrispondenza tra condizioni di visualizzazione e sintomo Quale sia la causa tra connessione, codifica e decodifica

Impostazioni di rete e GPU

Le impostazioni di UDP e GPU si scelgono in base a quanto emerso da confronti e misure. Se si sospetta la comunicazione, verificate prima tipo di connessione e percorso; se si sospetta l’elaborazione dello schermo, verificate prima in quali fasi viene usata la GPU.

Verificare TCP/UDP e percorso di connessione

Quando confronti e misure fanno sospettare la comunicazione, si verificano con l’amministratore il client in uso, il percorso e i criteri applicati. Anche quando serve modificare un’impostazione, lo si fa solo entro i limiti approvati, annotando il valore precedente e le modalità di ripristino. Non si disattivano firewall o autenticazione e non si espone la porta RDP direttamente su Internet.

  1. Con le informazioni di connessione, i log diagnostici del prodotto e i registri di rete dell’amministratore, verificate il TCP o UDP effettivamente usato e il percorso.

    RDP usa TCP o UDP in base alla configurazione e alle condizioni di rete. Con «Select RDP transport protocols» si può scegliere tra un’impostazione che usa UDP o TCP e un’impostazione solo TCP. Poiché RDP può anche ripiegare su TCP quando la connessione UDP non si stabilisce, la sola riuscita della connessione non rivela il trasporto usato. Vedi: Scelta del trasporto RDP e ripiego.

  2. Mettete in relazione l’orario dei sintomi con percorso e trasporto, poi confrontate solo le impostazioni necessarie, una alla volta.

    Non si cambia nulla in modo indiscriminato pensando che «disattivare UDP renda tutto più veloce». Confrontate a parità di condizioni di VPN o gateway, operazione e visualizzazione, e annullate le modifiche inutili.

Conoscendo trasporto e percorso, potete registrare il rapporto tra modifiche e sintomi. Passare al solo TCP non rende sempre tutto più veloce.

Verificare il tipo di connessione prima di confrontare le impostazioni di reteSi distingue la normale connessione diretta da quella tramite gateway o servizio, si verificano percorso e trasporto effettivi e poi si eseguono i confronti autorizzati.Client in uso e configurazioneVerificare percorso reale, TCP o UDPConfronto con l'orario del sintomoConfrontare un'impostazione alla volta

Figura 16: Si verificano il tipo di connessione e il percorso in uso, si mettono in relazione con il sintomo e poi si confrontano solo le impostazioni necessarie.

RDP Shortpath è un meccanismo di Azure Virtual Desktop. Stabilisce un percorso UDP proprio di quel servizio e, a seconda della configurazione, usa un percorso diretto o un relay. Se non riesce a stabilirlo, torna a una connessione basata su TCP. Non lo si può trattare nella stessa tabella di impostazioni della connessione diretta a un PC aziendale con mstsc. Vedi: Percorsi e ripiego di RDP Shortpath.

Percorsi e ripiego di RDP ShortpathRDP Shortpath di Azure Virtual Desktop prova a stabilire un percorso UDP; se ci riesce usa un percorso diretto o un relay a seconda della configurazione, altrimenti torna a una connessione basata su TCP.StabilitoNon riuscitoRDP ShortpathPercorso UDPDiretto o relayRitorno a TCP

Figura 17: Se RDP Shortpath non riesce a stabilire un percorso UDP, torna a una connessione basata su TCP.

Verificare l’uso della GPU nell’elaborazione dello schermo

Questa verifica serve quando confronti e misure fanno sospettare l’elaborazione dello schermo. Controllate i risultati di misura dell’elaborazione dello schermo e i sistemi operativi, driver, criteri e client supportati. Non si cambiano le impostazioni solo perché è presente una GPU. Prima si ottiene l’approvazione dell’amministratore e si prepara il ripristino.

  1. Separate il rendering dell’applicazione sull’host, la codifica RDP e la decodifica in locale, e scegliete la fase sospetta.

    Anche se c’è una GPU, non è detto che tutte le fasi la usino. Anche nella documentazione di configurazione di Microsoft per Azure Virtual Desktop, il rendering della sessione remota e la codifica hardware dei frame si configurano e si verificano separatamente. Vedi: Configurazione e verifica della GPU per rendering e codifica.

  2. Verificate l’uso effettivo seguendo la procedura del prodotto interessato e misurate la stessa operazione prima e dopo le modifiche necessarie.

    Se il tempo di compressione è lungo, esaminate l’uso della GPU per la codifica. Cambiare le impostazioni di codifica per un’applicazione che attende nella coda di input significa intervenire nel punto sbagliato. Leggibilità del testo e fluidità del video richiedono inoltre scelte diverse tra qualità dell’immagine, volume di traffico e carico di elaborazione. Vedi: Differenze in base al carico di lavoro.

Andando oltre la semplice presenza della GPU, potete registrare se la GPU viene usata nella fase problematica e come sono cambiati carico e risposta della stessa operazione. Le modifiche che non portano miglioramenti si annullano dopo averne parlato con l’amministratore.

Verificare l'uso della GPU fase per faseSi separano il rendering dell'applicazione sull'host, la codifica RDP e la decodifica in locale; poiché anche con una GPU non tutte le fasi la usano, se ne verifica l'uso nella fase sospetta.Rendering dell'applicazione sull'hostCodifica RDPDecodifica in localeVerificare la GPU per ogni fase

Figura 18: Anche con una GPU, non è detto che rendering, codifica e decodifica la usino tutti.

Nuova verifica e passaggio di consegne

Un miglioramento si conferma quando, dopo la modifica, la stessa operazione si svolge senza problemi e restano garantite la qualità dell’immagine, i dispositivi e le funzioni aziendali necessari. Confrontate anche il risultato ottenuto tornando alle condizioni originali. Se il recupero è solo momentaneo, non si considera accertata la causa e si registrano anche le fasce orarie di congestione e le elaborazioni simultanee.

L'ordine per confermare un miglioramentoDopo la modifica si verifica che la stessa operazione si svolga senza problemi e che qualità dell'immagine, dispositivi e funzioni aziendali necessari restino garantiti, si confronta con il risultato del ripristino delle condizioni originali, e un recupero momentaneo non basta a stabilire la causa.Provare la stessa operazione dopo la modificaVerificare immagine, dispositivi, funzioniConfronto con il ripristinoUn recupero momentaneo non basta

Figura 19: Oltre al risultato della stessa operazione, si verificano le funzioni necessarie e il risultato del ripristino.

Passaggio di consegne se il problema resta irrisolto

Anche quando non c’è miglioramento, il sintomo non si riproduce o i contatori non sono disponibili, il risultato è utile. Separate i confronti che siete riusciti a fare dalle verifiche che non è stato possibile eseguire e passate le informazioni ad amministratori e sviluppatori con la nota seguente. Eliminate dai log condivisi le informazioni aziendali non necessarie all’indagine, come nomi utente o host.

Ora in cui si è presentato il sintomo e fuso orario:
Sistema operativo dell'host, client usato e versione:
Connessione diretta / VPN / RD Gateway / Azure Virtual Desktop ecc.:
Operazione e applicazione lente, risposta di altre applicazioni nella stessa sessione:
Risoluzione e numero di monitor lato remoto:
Copie, stampe ecc. in corso nello stesso momento:
Unica condizione cambiata e risultato dopo il ripristino:
Carico e contatori osservati sull'host e in locale:

Aggiungete anche se è stato possibile verificare il TCP o UDP effettivo, le voci che non si sono potute verificare per mancanza di autorizzazioni o altro, e le impostazioni accettabili per il lavoro. Dire «nel Blocco note si digita normalmente, ma scorrendo le foto si blocca» invece di «la connessione è lenta» permette a chi segue di indagare nelle stesse condizioni.

Gli utenti registrano l’operazione che riproduce il problema e i risultati dei confronti, gli amministratori mettono in relazione i registri del percorso di connessione, dell’host condiviso e delle sessioni. Il solo fatto che si attenda in RDP non significa che anche l’elaborazione che fa attendere dipenda da RDP. Vedi: Divisione dei compiti tra host e back-end.

Gli sviluppatori dell’applicazione registrano separatamente la ricezione degli eventi di input, l’inizio e la fine delle elaborazioni su database e file e l’aggiornamento dell’interfaccia. Valutano anche una progettazione che non lasci i lavori pesanti a occupare il thread dell’interfaccia. Tuttavia, un log di fine elaborazione sull’host non registra la fine della visualizzazione sul computer locale. Vedi: Separare le elaborazioni per mantenere reattiva l’interfaccia.

Articoli correlati

Riferimenti

Si tratta di fonti primarie di Microsoft Learn. Il contenuto consultato è stato verificato il 17 settembre 2026. Leggetele distinguendo le condizioni di applicabilità di ciascun prodotto e tenendo presente che non si tratta di misure eseguite per questo articolo.

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste sono pagine di argomenti vicini a questo tema. A partire dall'articolo, potete passare ai servizi correlati e ad altri articoli.

Servizi collegati all’argomento

Questo articolo si collega alle pagine dei servizi seguenti. Partite da un ingresso vicino alla vostra situazione.

Domande frequenti

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

Il test di velocità segna centinaia di Mbit/s: perché l'input in RDP è lento?
La velocità con cui si trasportano grandi quantità di dati e il tempo che serve perché un comando produca una reazione sono due cose diverse. Entrano in gioco l'invio dell'input, l'elaborazione dell'applicazione sull'host, la compressione dello schermo, il trasferimento e la visualizzazione sul computer locale. Inoltre il server del test di velocità e l'host RDP si raggiungono attraverso percorsi di rete diversi.
La digitazione è normale, solo lo scorrimento va a scatti: è un problema della connessione?
Non si può restringere la causa alla sola connessione. Quando gli aggiornamenti dello schermo aumentano, il rendering e la compressione sull'host, la comunicazione oppure la decodifica e la visualizzazione in locale potrebbero non stare al passo. Cambiate la risoluzione o il numero di monitor lato remoto uno alla volta per confrontare e, se serve, esaminate i contatori legati al rendering.
Se il ping è veloce, la comunicazione RDP è normale?
Questo da solo non basta per giudicare. Il ping misura la risposta a ICMP e non misura né il trasferimento dello schermo di RDP né l'elaborazione delle applicazioni. Nelle configurazioni che usano RD Gateway o soluzioni simili, inoltre, il percorso potrebbe non coincidere. Anche in assenza di risposta, distinguete un blocco di ICMP da un'interruzione di RDP stesso.
User Input Delay è il tempo tra la pressione di un tasto e la comparsa del carattere?
No. È un contatore che misura il tempo di attesa tra l'ingresso di un input nella coda dell'host e il suo prelievo da parte del processo. Non è il ritardo percepito, che comprende il giro di andata e ritorno in rete, l'elaborazione dell'applicazione dopo il prelievo e la compressione, la decodifica e la visualizzazione dello schermo.
Quando RDP è lento conviene disattivare UDP?
Non lo consigliamo come regola generale. Verificate prima il tipo di connessione effettivo, il percorso e i criteri applicati. Può darsi che UDP non sia utilizzabile e che la connessione abbia già ripiegato su TCP, quindi passare al solo TCP non rende sempre tutto più veloce. Confrontate a parità di condizioni con il permesso dell'amministratore e annullate le modifiche inutili.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Si occupa soprattutto di sviluppo di software Windows, consulenza tecnica e indagine sui malfunzionamenti, con punti di forza nei progetti in cui restano risorse esistenti e nelle indagini su guasti dalla causa difficile da individuare.

Contattaci
Torna al blog