AVD/W365 + RDP Multipath = 😍

Excellente nouvelle pour celles et ceux rencontrant des soucis de connexion à Azure Virtual Desktop ou Windows 365 ! Disponible en préversion depuis début 2025, le RDP Multipath vient d’être annoncé il y a peu en disponibilité générale par Microsoft. Nous allons justement voir comment en bénéficier, et qu’est-ce que cela apporte par rapport à du TCP ou à l’UDP simple-path.

Comment fonctionne la connexion d’un utilisateur à une VM AVD ?

Azure Virtual Desktop héberge des sessions client sur des hôtes de session s’exécutant sur Azure. Microsoft gère des parties des services au nom du client et fournit des points de terminaison sécurisés pour la connexion des clients et des hôtes de session.

Le diagramme suivant fournit une vue d’ensemble générale des connexions réseau utilisées par Azure Virtual Desktop.

Microsoft Learn

Azure Virtual Desktop (AVD) utilise le protocole RDP pour établir et acheminer vos sessions vers les machines virtuelles ; voici comment la connexion se déroule :

Découverte du feed (Feed Discovery)
- L’utilisateur s’authentifie auprès de Microsoft Entra ID et obtient un jeton OAuth.
- Le client envoie ce jeton au service de feed AVD, qui retourne la liste des desktops et applications disponibles sous forme de fichiers .rdp signés numériquement Microsoft Learn.
Connexion au gateway AVD
- Quand l’utilisateur lance l’un des fichiers .rdp, le client se connecte via TLS 1.2 (HTTPS) à Azure Front Door, qui redirige vers l’instance du Remote Connection Gateway la plus proche (latence minimale et charge équilibrée) Microsoft Learn.
- Le gateway valide la requête et fait appel au Connection Broker pour orchestrer la suite.
Établissement du canal de contrôle
- L’hôte de session (VM AVD) maintient en permanence un canal de communication sortant chiffré (TLS) vers le broker AVD, géré par le service Reverse Connect Transport plutôt qu’un listener TCP classique Microsoft Learn.
- Le broker utilise ce canal pour indiquer au session host de joindre le même gateway que le client.
Ouverture du canal de données (RDP data channel)
- Reverse connect transport (TCP via le gateway) : le trafic RDP transite en TCP chiffré sur 443 via le gateway, idéal si UDP est bloqué ou non configuré.
- RDP Shortpath (UDP direct) : le client et le session host créent un canal UDP direct (STUN/TURN + ICE), évitant le relay du gateway pour réduire latence et jitter Microsoft Learn.
- Le basculement entre TCP et UDP Shortpath est transparent et contrôlé par le client selon la configuration et la qualité réseau.
Session active et résilience
- Une fois le canal de données établi, RDP gère l’envoi d’affichage, d’audio, de redirections périphériques, etc.
- En mode Shortpath, chaque paquet voyage de façon indépendante : en cas de perte ou de réordonnancement, RDP multi‑path ou le TCP se chargent des retransmissions, tandis que le reverse connect TCP reprend toujours – garantissant la continuité de la session même sur des réseaux instables.

Le bon vieux duel TCP vs UDP ?

Voici un tableau comparatif des principaux aspects de TCP et UDP :

Critère	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
Type de connexion	Orienté connexion (handshake en trois temps)	Sans connexion (pas de handshake)
Fiabilité	Fiable : accusés de réception et retransmissions automatiques	Non fiable : pas d’accusés de réception ni retransmissions
Ordonnancement	Garantit l’ordre des paquets	Pas d’ordre garanti
Contrôle de flux	Oui (fenêtre glissante)	Non
Contrôle de congestion	Oui (algorithmes AIMD, slow start, etc.)	Non
Taille de l’en‑tête	Au moins 20 octets	8 octets
Vitesse (latence)	Plus lente (overhead de contrôle)	Plus rapide (faible overhead)
Utilisations courantes	HTTP, HTTPS, FTP, SMTP, SSH, bases de données	DNS, VoIP, streaming vidéo, jeux en temps réel
Gestion des erreurs	Vérification de somme de contrôle + retransmission	Vérification de somme de contrôle uniquement
Transmission multiple	Flux unique, multiplexé par port	Datagrammes indépendants par port
Connection keep‑alive	Oui (optionnel)	Non
Adapté pour…	Applications nécessitant intégrité et fiabilité	Applications temps réel et tolérantes à la perte

Dans quels cas ne pas utiliser l’UDP pour AVD ?

Certains utilisateurs ont ressenti des difficultés lors de session Azure Virtual Desktop lorsque on passe systématiquement à l’UDP. On évitera d’activer le transport UDP sur Azure Virtual Desktop dans les cas suivants :

Réseaux d’entreprise très « verrouillés » :
- Pare‑feu ou appliance de sécurité qui ne laissent passer que le trafic HTTPS/TCP sur le port 443.
- Proxies ou load‑balancers interdisant ou foreçant l’inspection de flux UDP.
- Absence d’ouvrages STUN/TURN nécessaires au Shortpath UDP.
Topologies NAT ou VPN problématiques :
- NAT très restrictif (symmetric NAT) qui empêche la découverte de chemin direct STUN.
- VPN d’entreprise qui n’autorise que le protocole TCP encapsulé (SSLVPN, SSTP…), rendant l’UDP inopérant.
Contraintes de conformité ou d’audit :
- Politiques de sécurité interne imposant que tout le trafic soit chiffré/TLS sur TCP pour centraliser la journalisation et l’inspection.
- Nécessité de passer via des IDS/IPS qui ne gèrent que le TCP.
Scénarios de diagnostic ou de troubleshooting :
- Pour isoler un problème de connectivité ou comparer les performances TCP vs UDP : on désactive l’UDP pour forcer le fallback TCP.
- Lorsque vous suspectez que le UDP est la source de coupures intempestives (perte, réordonnancement).
Clients legacy ou plateformes non supportées :
- Certains clients RDP anciens ou intégrés (HTML5 via RemoteApp) ne gèrent pas le Shortpath UDP.

Un article écrit sur ce blog montre comment justement rester sur du TCP via une configuration depuis la machine AVD ou le poste local.

Qu’est-ce que le RDP Multipath ?

Le RDP Multipath (ou « UDP Multi‑Path ») est une évolution du transport RDP Shortpath qui évite les coupures et micro‑latences en :

Ouvrant plusieurs sous‑canaux UDP simultanément entre le client et l’hôte de session, au lieu d’un seul.
Surveillant en continu la qualité (latence, perte, gigue) de chacun de ces chemins via ICE/STUN/TURN.
Bascule instantanée du trafic sur le ou les sous‑canaux les plus sains dès qu’un chemin se dégrade, sans interrompre la session.

Concrètement, si l’un des liens subit une perte de paquets élevée, un pic de gigue ou tombe complètement, Multipath redirige automatiquement les paquets vers un autre sous‑chemin en quelques dizaines de millisecondes, assurant une expérience fluide et sans reconnexion visible pour l’utilisateur.

Comment fonctionne le RDP Multipath pour Azure Virtual Desktop ?

RDP Multipath pour Azure Virtual Desktop établit plusieurs sous‑canaux UDP simultanés (via ICE, STUN et TURN) et mesure en continu leur qualité (latence, perte, gigue).

Dès qu’un lien se dégrade, il bascule automatiquement en quelques dizaines de millisecondes vers le canal le plus performant, sans interrompre la session.
Si tous les canaux UDP tombent, Multipath retombe de façon transparente sur TCP, garantissant ainsi une expérience AVD quasi ininterrompue et nettement plus stable sur des réseaux instables.

L’excellente vidéo de Dean Cefola depuis sa chaîne YouTube Azure Academy nous permet d’en savoir un peu plus :

Le diagramme suivant illustre le fonctionnement de RDP Multipath avec Azure Virtual Desktop. Dans ce scénario, le principal chemin actif est la connexion UDP via STUN, complétée par deux connexions UDP redondantes via un serveur TURN :

Microsoft Learn

Comment en bénéficier ?

RDP Multipath fonctionne automatiquement lorsque les conditions suivantes sont remplies :

Assurez-vous que RDP Shortpath est configuré comme protocole de transport principal. Pour plus d’informations, voir Configurer RDP Shortpath. Nous ne prenons pas actuellement en charge les connexions WebSocket (basées sur le protocole TCP) et ces utilisateurs n’en tirent aucun avantage pour le moment.

Les connexions doivent être établies à partir d’un appareil Windows local utilisant Windows App, version 2.0.366.0 ou ultérieure, ou le client Remote Desktop, version 1.2.6074 ou ultérieure. Les autres plateformes ne sont pas prises en charge actuellement.

Afin de comprendre mieux le fonctionnement et l’impact entre les 3 protocoles disponibles pour Azure Virtual Desktop, j’ai préparé un environnement dédié.

Voici les différentes étapes que j’ai suivies :

Maintenant, il nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

Une abonnement Azure valide
Un tenant Microsoft

Etape I – Création de l’environnement AVD

J’ai créé un nouvel environnement Azure Virtual Desktop composé de 3 machines virtuelles et placées dans un même pool d’hôtes :

Comme le recommandait Microsoft avant la fin de la préversion, mon pool d’hôtes est encore être configuré en tant qu’environnement de validation :

Enfin j’ai laissé par défaut la configuration de la fonctionnalité RDP shortpath afin de gérer le protocole utilisé de façon individuelle sur chacune des 3 machines virtuelles AVD :

Commençons par configurer la première machine virtuelle AVD afin que celle-ci n’accepte que les connexions RDP en TCP.

Etape II – VM1 Forcer le flux TCP côté serveur :

Il est possible de forcer le serveur à n’accepter que des connexions TCP, ce qui est particulièrement utile dans des environnements où la stabilité prime. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.

Avant modification, le serveur accepte par défaut les connexions en UDP. Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SelectTransport /t REG_DWORD /d 1 /f

Après avoir mis à jour la clé de registre, il est nécessaire de redémarrer la machine AVD pour que la modification prenne effet.

Après modification, la connexion se fait exclusivement en TCP. Cette commande force le serveur à utiliser uniquement TCP pour les connexions RDP.

Continuons par configurer la seconde machine virtuelle AVD pour que celle-ci n’accepte que les connexions RDP en UDP simple-path.

Etape III – VM2 Forcer le flux UDP simple-path côté serveur :

Avant modification, le configuration par défaut de mon AVD accepte les connexions en UDP Multipath si cela est possible.

Mais il est possible de forcer le serveur à n’accepter que des connexions UDP sans Multipath. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 0 /f

Après avoir mis à jour la clé de registre, les utilisateurs doivent se déconnecter et se reconnecter à l’hôte de la session pour que la modification prenne effet.

Après la modification, la connexion AVD se fait exclusivement en UDP simple-path :

Terminons de préparer notre environnement par la configuration de la dernière machine virtuelle AVD pour que celle-ci accepte les connexions RDP en UDP Multipath.

Etape IV – VM3 Forcer le flux UDP Multipath côté serveur :

Compte tenu de la configuration de notre nouvel environnement Azure Virtual Desktop, il n’y a rien à faire. La connexion de notre utilisateur de test nous le prouve :

Nos machines virtuelles AVD sont prêtes. Continuons maintenant sur la préparation de notre protocole de test.

Etape V – Préparation de l’environnement de test :

J’ai utilisé la version d’essai gratuite de Connection Emulator.

Connection Emulator est un outil qui vous permet de simuler des conditions réseau dégradées (latence, perte, gigue, réordonnancement, duplication, corruption).

Voici le lien pour le télécharger en version d’essai, cliquez-ici pour télécharger et installer la version Windows :

Caractéristiques principales de l’outil

Limite la vitesse de connexion
Imite une latence fixe ou variable
Simule la perte, la corruption, la duplication et la réorganisation de paquets individuels et séquentiels.
Affiche un graphique de simulation de paquets en direct
Prend en charge plusieurs profils de simulation

Etape VI – Réalisation des 2 tests :

J’ai réalisé deux scénarios d’émulation réseau avec Connection Emulator :

Test 1 : latence 100 ms, perte 8 %, duplication 5 %, réordonnancement 30 %, corruption 2 %
Test 2 : latence 200 ms, perte 16 %, duplication 10 %, réordonnancement 40 %, corruption 4 %

Pour chaque scénario, j’ai démarré simultanément trois VM AVD configurées en TCP, UDP simple-path et UDP Multipath, puis lancé la même vidéo sur chacune.

Cette méthode met en évidence, de manière visuelle, la dégradation de la qualité pour TCP et UDP mono-chemin et la résilience supérieure de l’UDP Multipath face aux pires conditions réseau.

Voici ma vidéo de comparaison des 3 protocoles de connexion :

Etape VII – Configuration sur Windows 365 :

Finissons cette dernière étape par la configuration sur Windows 365. Voici les informations de connection sur un poste Windows 365 avant la modification de registre :

Pour activer RDP Multipath avant le déploiement complet, définissez la valeur de la clé de registre suivante sur 100, puis relancez la session de votre utilisateur

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 100 /f

Voici les informations de connection sur un poste Windows 365 après la modification de registre :

Si vous préférez désactiver RDP Multipath jusqu’à ce que le déploiement soit terminé, définissez la valeur de la clé de registre sur 0 :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 0 /f

Conclusion

En synthèse, RDP Multipath représente une véritable avancée pour Azure Virtual Desktop : il combine la rapidité et la légèreté du transport UDP avec robustesse et la redondance.

Grâce à la création et à la surveillance en continu de plusieurs sous‑canaux UDP, vos sessions basculent en quelques dizaines de millisecondes vers le chemin le plus sain, tout en retombant de façon transparente sur TCP si nécessaire.

Le résultat ?

Une expérience utilisateur fluide, sans micro‑coupure ni latence excessive, même sur des réseaux fortement dégradés.

N’attendez plus pour activer RDP Multipath sur vos environnements AVD : testez-le dès aujourd’hui et constatez par vous‑même l’amélioration significative de la résilience et de la qualité de vos connexions distantes.

AVD/W365 + RDP Multipath = 😍

Publié par Jean-Loup Orgitello

Laisser un commentaire Annuler la réponse