• Cloud, Guide
• 6 Luglio 2026

Oltre il mito del “Terminal Server col vestito nuovo”

Nell’immaginario collettivo di molti amministratori di sistema, il Remote Desktop Protocol (RDP) è rimasto ancorato all’esperienza dei vecchi server aziendali: un protocollo solido ma rigido, indissolubilmente legato alla porta TCP 3389 e vulnerabile ai minimi sbalzi di rete. Per questo motivo, quando approcciano Azure Virtual Desktop (AVD), l’errore più comune è pensare di trovarsi davanti a una semplice riedizione estetica del passato, un “Terminal Server spostato nel cloud” che soffre degli stessi storici limiti di latenza. In realtà, dietro la familiarità dell’interfaccia si nasconde una rivoluzione architetturale profonda: Microsoft ha completamente riscritto le fondamenta del trasporto dati, scardinando i vincoli tradizionali del modello OSI per adattare il protocollo alle sfide delle reti moderne.

Quali sono quindi queste “sfide moderne”?

Le reti moderne non sono più i perimetri stabili e cablati degli uffici di un tempo, ma connessioni Wi-Fi domestiche, reti 4G/5G in mobilità e tunnel VPN, tutte intrinsecamente soggette a pacchetti persi e micro-interruzioni. In questo scenario instabile, il limite strutturale dell’RDP classico emerge con violenza: affidandosi al TCP puro, il protocollo cade vittima del famigerato Head-of-Line Blocking, un meccanismo per cui la perdita di un singolo bit costringe l’intera sessione a congelarsi in attesa della ritrasmissione. Di conseguenza, mentre l’utente sperimenta lo schermo bloccato e il puntatore del mouse a scatti, l’infrastruttura si scontra con l’impossibilità di garantire fluidità multimediale e trasferimenti file efficienti su canali che non offrono più una larghezza di banda prevedibile.

La svolta ingegneristica di RDP Shortpath

Figura 1: RDP Shortpath – Connection Diagram

Figura 2: Collegamento tramite gli AVD Gateway Services

La risposta di Microsoft a questi limiti strutturali si chiama RDP Shortpath, una tecnologia che scardina il flusso di connessione tradizionale di Azure Virtual Desktop. Normalmente, AVD utilizza il meccanismo di Reverse Connect: il client dell’utente e l’Host nel cloud non si parlano mai direttamente, ma stabiliscono entrambi una connessione TCP in uscita verso i Gateway di Azure, che fanno da intermediari sicuri.

Shortpath supera questo collo di bottiglia: pur mantenendo il Gateway per la fase iniziale di autenticazione, stabilisce una corsia preferenziale parallela basata su un flusso UDP diretto tra il dispositivo dell’utente e la macchina virtuale. I benefici pratici sono immediati e drastici: la latenza di rete si abbatte poiché i pacchetti non devono più compiere deviazioni geografiche verso i nodi di Azure, traducendosi in una reattività del puntatore e delle applicazioni identica a quella locale.

Se siete curiosi su come abilitarlo, Nicola Ferrini ha scritto una guida molto puntuale che vi invito a riprendere # RDP Shortpath per Azure Virtual Desktop e Windows 365 Cloud PC

La domanda da un milione di dollari: Se passiamo a UDP, i dati si perdono?

L’introduzione di questa corsia diretta in UDP risolve istantaneamente il problema del lag, ma spalanca le porte a un enorme paradosso ingegneristico: UDP è per sua natura un protocollo lossy e inaffidabile, che spara pacchetti sulla rete senza curarsi se arriveranno a destinazione. Se questo approccio è ideale per lo streaming video, dove un frame perso non compromette l’esperienza, cosa succede quando un utente avvia un trasferimento file pesante o copia dei dati testuali sensibili tramite gli appunti?

Per evitare questo disastro senza rinunciare alla velocità del canale diretto, Shortpath smette di essere una semplice configurazione di rete e si affida a un capolavoro software sottostante: il motore URCP.

Dal cavo LAN al Cloud: L’evoluzione genetica di RDP

Per apprezzare a pieno la rivoluzione di RDP Shortpath, dobbiamo sfatare il mito secondo cui il protocollo RDP sia un blocco di codice statico rimasto invariato nel tempo. Al contrario, l’architettura di remotizzazione di Microsoft ha subito una vera e propria selezione naturale durata oltre vent’anni, mossa dal costante bisogno di adattarsi a reti sempre più veloci ma intrinsecamente più instabili.

Tuttavia, per capire come il protocollo sia mutato nel tempo, dobbiamo prima comprendere un concetto base della sua anatomia: i Virtual Channels.

Il concetto cardine: RDP come un’autostrada multiplexed

RDP non invia i dati dello schermo, del mouse e dei file come un unico blocco indistinto. Agisce invece come un’autostrada a più corsie parallele e indipendenti, chiamate Virtual Channels (Canali Virtuali). Esiste una corsia per l’input di mouse e tastiera, una per l’audio, una per il flusso video dello schermo e una per lo scambio di file. Questa scomposizione chirurgica è fondamentale: permette allo stack di RDP di “etichettare” ogni singolo pacchetto prima di inviarlo, sapendo esattamente cosa contiene.

Compreso questo meccanismo di scomposizione (consiglio anche la visione di Explain Like I’m 5: Remote Desktop Protocol (RDP)) possiamo analizzare come Microsoft abbia cambiato la natura di queste corsie e il loro modo di viaggiare sulla rete attraverso quattro grandi ere storiche:

1. L’Era della LAN e del limite dei 31 Canali Statici (1998 – RDP 4.0/5.x)

Alle sue origini, su Windows NT 4.0 Terminal Server Edition, RDP incanalava tutte le sue corsie dentro un unico, rigido tubo: il protocollo TCP (sulla storica porta 3389). In questa fase iniziale, descritta nel documento core MS-RDPBCGR: Remote Desktop Protocol Basic Connectivity and General Requirements, i canali erano Static Virtual Channels (SVC). L’architettura originaria prevedeva un limite massimo invalicabile di soli 31 canali statici totali per sessione. Ogni canale doveva essere registrato rigidamente all’avvio e occupava uno slot fisso nell’header del pacchetto. Se un’applicazione di terze parti o un nuovo componente di sistema voleva creare una nuova funzionalità di re-indirizzamento, rischiava di non trovare slot liberi. Inoltre, se la corsia di un file si intasava, l’intero tubo TCP si bloccava, congelando anche il mouse.

Figura 3: RDP 4.0 – Single TCP Connection

2. La svolta dell’estensibilità: I Canali Virtuali Dinamici (2006 – RDP 6.0)

Con il rilascio di Windows Vista e Windows Server 2008, Microsoft si rende conto che il limite dei 31 canali statici è un collo di bottiglia asfissiante per lo sviluppo futuro. Introduce così la specifica dei Dynamic Virtual Channels (DVC)
MS-RDPEDYC: Remote Desktop Protocol: Dynamic Channel Virtual Channel Extension. Per non rompere la retrocompatibilità, Microsoft compie un colpo di genio: utilizza uno dei vecchi canali statici rimasti liberi (chiamato drdynvc) e lo trasforma in un “incubatore”. Da quel momento in poi, la sessione apre solo quel canale statico, il quale ha l’unico compito di generare al suo interno infiniti sotto-canali dinamici che possono essere creati, distrutti e scalati “al volo” a seconda delle esigenze dell’utente (come l’inserimento di una chiavetta USB o l’apertura degli appunti). RDP diventa ufficialmente un protocollo modulare ed estensibile.

Figura 4: TCP 6.0 – Dynamic Virtual Channel

3. L’Era del Multi-Transport (2012 – RDP 8.0 e l’introduzione di MS-RDPEMT)

Ora che i canali sono diventati dinamici e flessibili, Microsoft può fare il passo successivo: separarli non solo logicamente, ma anche fisicamente a livello di rete per combattere il famigerato Head-of-Line Blocking su Internet. Con Windows 8 arriva la specifica MS-RDPEMT: Remote Desktop Protocol Multitransport Extension e la sua sussidiaria UDP MS-RDPEUDP: Remote Desktop Protocol: UDP Transport Extension . Sfruttando l’architettura DVC, lo stack decide di dividere le strade: le corsie sensibili ai pacchetti persi (come la Clipboard cliprdr) continuano a viaggiare sul tunnel sicuro TCP, mentre le corsie puramente grafiche (rdpgfx) vengono deviate sul nuovo canale parallelo UDP per garantire la massima fluidità visiva dei pixel.

Figura 5: RDP 8.0 – TCP/UDP Multitransport

4. L’Era della Convergenza Cloud (Oggi – AVD e URCP)

Il modello Multi-Transport, per quanto innovativo, richiedeva la gestione simultanea e coordinata di due socket diversi (uno TCP e uno UDP), uno scenario complesso da digerire per i moderni firewall e i Gateway Cloud di Azure Virtual Desktop.

Con l’avvento di AVD Shortpath assistiamo al “colpo di stato” architetturale definitivo: la connessione TCP iniziale viene utilizzata esclusivamente per l’handshake e l’autenticazione, per poi cedere immediatamente il passo. Il vecchio approccio frammentato viene superato dalla nascita di una nuova specifica di trasporto unificata: MS-RDPEUDP2: Remote Desktop Protocol: UDP Transport Extension Version 2

Questo protocollo di seconda generazione implementa nativamente sotto il cofano il motore URCP (Universal Rate Control Protocol) di Microsoft Research. L’UDP cessa di essere un mero assistente grafico e diventa l’unico, assoluto padrone del trasporto sulla porta 3390.

Come fa però un unico protocollo inaffidabile per natura a gestire contemporaneamente canali dinamici che pretendono l’integrità assoluta (i file) e canali che vogliono solo la velocità (il video)?

Figura 6: RDP 10.X RDP on URCP

Per capirlo, addentriamoci ulteriormente nel motore URCP!

Il motore sotto il cofano: URCP (Universal Rate Control Protocol)

All’interno dell’architettura di Azure Virtual Desktop (AVD), è necessario scindere il concetto di connettività infrastrutturale dall’algoritmo che ne governa i flussi. Se RDP Shortpath rappresenta la “strada” diretta aperta tra client e host via UDP, la specifica MS-RDPEUDP2 rappresenta il binario normativo, mentre l’URCP (Universal Rate Control Protocol) è il pilota intelligente che decide come, quanto e a quale velocità inviare i dati lungo quella via.

L’URCP non nasce come una banale patch software correttiva di Windows. Al contrario, esso affonda le proprie radici nelle pubblicazioni scientifiche e nei brevetti di Microsoft Research. L’obiettivo iniziale del team di ricerca era sviluppare un protocollo di trasporto universale, snello e operante interamente a livello applicativo, capace di superare i limiti storici dei controlli di congestione integrati nei vari kernel dei sistemi operativo. Con il consolidamento di AVD, questo impianto teorico è diventato il cuore pulsante del protocollo di trasporto Shortpath, integrandosi direttamente nello stack di rete dei sistemi operativi Windows a partire da Windows 10 (versione 2004) e Windows Server 2022

A livello concettuale, l’URCP si posiziona esattamente al Layer Applicativo (Layer 7 dello stack OSI), pur ereditando e orchestrando logiche tipiche del Layer di Trasporto (Layer 4). Esso agisce come una camera di compensazione intelligente: riceve i dati dai vari Canali Virtuali Dinamici (DVC), valuta lo stato di salute della tratta di rete in tempo reale e confeziona i pacchetti secondo la specifica MS-RDPEUDP2 prima di consegnarli al socket UDP nativo del sistema operativo.

Il trucco del Payload Encapsulation (UDP Tunneling)

Una delle principali sfide ingegneristiche nel controllo di un flusso personalizzato su UDP riguarda la struttura fisica del pacchetto di rete. Lo standard UDP è per definizione privo di stato (stateless) e il suo header è ridotto al minimo: appena 8 byte totali, rigidamente suddivisi in quattro campi da 2 byte ciascuno: Source Port, Destination Port (la porta 3390 nel nostro scenario), Length e Checksum.

In questi 8 byte standard non esistono bit liberi. Non c’è alcuno spazio per inserire metadati complessi come i numeri di sequenza per l’ordinamento dei pacchetti, i flag di controllo o i numeri di ACK (conferma di ricezione) necessari per garantire l’affidabilità dei dati.

Per aggirare questo limite fisico, lo stack applicativo adotta la tecnica del Payload Encapsulation, dando vita a una struttura a “Matrioska”.

Figura 7 :URCP – Reliable Packet vs Unreliable Packet

Quando lo stack RDP deve spedire un’informazione, non modifica l’header UDP standard. Al contrario, inserisce i propri metadati operativi all’inizio dell’area dati (Payload) del pacchetto UDP. A seconda della natura del canale DVC originario, l’interfaccia genera due diverse tipologie di sotto-header:

1. RELIABLE (GUARANTEED) PACKET: Utilizzato per flussi critici come la Clipboard o il File Transfer. Nell’area dati del pacchetto UDP viene iniettato un header contenente campi fondamentali come il SEQUENCE NUMBER (SEQ), l’ACKNOWLEDGEMENT (ACK) e la RETENTION WINDOW. Questo permette al destinatario di riordinare la coda di pacchetti (P1, P2, P3, P4) e confermarne la ricezione.
2. UNRELIABLE (LOSSY) PACKET: Utilizzato per i pixel grafici (rdpgfx) generati in H.264/AV1 e per l’audio streaming. In questo caso, l’header applicativo contiene il SEQUENCE NUMBER per permettere al client di scartare pacchetti obsoleti arrivati fuori tempo massimo, ma i campi di ACK e la RETENTION WINDOW vengono completamente bypassati ([X] NULL). Viene così implementata la filosofia Send-and-Forget: se si crea un vuoto nella coda ([EMPTY GAP] tra P202 e P203), il sistema non richiede la ritrasmissione, preservando la fluidità visiva a scapito di un frame intermedio perduto.

Per gli apparati di rete e i firewall intermedi, quel pacchetto rimane un normale flusso UDP diretto alla porta 3390; per gli endpoint, la lettura di quell’header applicativo rivela la natura e la priorità del transito.

Gestione intelligente della congestione

Se il Payload Encapsulation rappresenta il corpo del protocollo, l’algoritmo di Delay-based rate control (controllo della velocità basato sul ritardo) ne è il cervello. Si tratta di una logica radicalmente opposta rispetto al classico controllo della congestione basato sulle perdite (Loss-based) tipico del TCP tradizionale.

I protocolli tradizionali aumentano il flusso di dati finché non iniziano a subire la perdita fisica dei pacchetti causata dalla saturazione dei buffer dei router intermedi (Bufferbloat). Solo in quel momento interpretano la perdita come un segnale di saturazione e tagliano drasticamente la banda (Window Halving). Questo approccio è fallimentare in un ambiente desktop remoto in cloud, poiché la perdita di pacchetti si traduce istantaneamente in frame congelati, artefatti visivi e un inaccettabile lag del cursore del mouse.

L’URCP risolve il problema monitorando continuamente, su base millisecondimetrica, l’Inter-arrival Jitter e il Round Trip Time (RTT). L’algoritmo non aspetta che la rete collassi; calcola il gradiente di variazione dell’RTT secondo una logica predittiva:

ΔRTT = RTT_current – RTT_baseline

Se l’URCP rileva che il valore ΔRTT sta aumentando in modo costante (ad esempio, l’RTT della sessione sale linearmente da 20ms a 55ms), l’algoritmo comprende che i buffer dei nodi di rete lungo il percorso si stanno riempiendo e che la linea dell’utente sta entrando in congestione, ancora prima che si verifichi la perdita di un singolo bit.

A questo punto, l’URCP non agisce in modo cieco riducendo l’intera sessione, ma sfrutta il profondo legame con la specifica MS-RDPEUDP2 per operare un freno selettivo e asimmetrico sui canali dinamici (DVC):

• Saturazione del canale affidabile (Backpressure): L’URCP restringe immediatamente la finestra di trasmissione (Retention Window) dei canali pesanti e asincroni. Il trasferimento di un file o il reindirizzamento di una stampante in background vengono istantaneamente rallentati, riducendo l’iniezione di pacchetti Reliable nel tunnel UDP.
• Preservazione del canale inaffidabile (Prioritizzazione dell’Input): Mentre il trasferimento file viene frenato, l’URCP mantiene intatta la reattività e la priorità dei pacchetti legati ai movimenti del mouse, della tastiera e dello stream grafico a bassa latenza. Se la banda complessiva non è sufficiente, l’URCP comunica direttamente con il motore grafico MS-RDPEGFX, ordinandogli di abbassare dinamicamente il bitrate di campionamento dei pixel o il frame rate dei codec H.264/AV1.

Il risultato pratico di questa gestione predittiva è un’esperienza d’uso eccezionalmente fluida. Anche se l’utente si trova su una connessione Wi-Fi d’albergo altamente instabile o congestionata, l’URCP eviterà il congelamento della sessione: il download del file rallenterà in modo impercettibile e silenzioso, la nitidezza dello schermo calerà temporaneamente di qualche punto percentuale, ma l’interattività e l’istantaneità del mouse rimarranno ancorate allo zero-lag.

Figura 8: Remote processing and feedback schema (From Microsoft URCP official paperwork)

Conclusioni

L’evoluzione di RDP è una vera e propria parabola tecnologica: siamo partiti da un rigido binario TCP nato per le LAN dell’era Windows NT, passati per i tentativi di coesistenza del Multi-Transport, fino ad arrivare a un singolo flusso UDP capace di auto-regolarsi nel cloud con la precisione di un orologio svizzero. E’ l’affascinante dimostrazione di come il software sia riuscito a domare l’instabilità congenita delle reti moderne. Un’architettura così sofisticata che, dopotutto, ha un unico grande obiettivo nobile: fare in modo che anche dal Wi-Fi più incerto di un aeroporto, la vostra sessione rimanga perfettamente fluida… lasciandovi liberi di dare la colpa al lag solo quando mancherete un clic durante una presentazione importante.

Enea