Introduction
Le protocole de bureau à distance (RDP) sous-tend de nombreux déploiements d'accès à distance, des petites configurations de support informatique aux grands environnements d'entreprise. Pourtant, un facteur de performance clé est souvent négligé : si le trafic RDP circule principalement sur TCP ou UDP. Ce choix a un impact direct sur la latence, la réactivité et l'expérience utilisateur, en particulier à travers les WAN et les VPN. Dans ce guide, nous expliquons comment RDP utilise UDP et TCP, quand chaque transport fonctionne le mieux, et ce que vous pouvez ajuster dans Windows et votre réseau pour offrir des sessions à distance plus fluides et plus fiables.
Essai gratuit de TSplus Remote Access
Alternative ultime à Citrix/RDS pour l'accès aux bureaux/applications. Sécurisé, rentable, sur site/cloud
Pourquoi le choix du transport RDP est-il important pour la performance à distance ?
RDP n'est plus simplement un "extracteur d'écran". Le RDP moderne transporte des graphiques compressés, des multimédias, des événements d'entrée, des données d'impression et du contenu du presse-papiers. Chacun de ces flux réagit différemment à la latence et à la perte de paquets. Si le mauvais transport est utilisé, les utilisateurs constatent un décalage, une vidéo saccadée ou une réponse lente du clavier même lorsque la bande passante semble correcte.
Comprendre quand RDP préfère UDP par rapport à TCP aide les équipes informatiques à concevoir des passerelles, des VPN et règles de pare-feu qui soutiennent une véritable performance au lieu de simples "vérifications vertes" dans les tableaux de bord de surveillance. Cela est particulièrement important pour les environnements mixtes où certains utilisateurs se connectent via la fibre, tandis que d'autres se connectent via des concentrateurs VPN encombrés ou des points d'accès mobiles.
Quels sont les fondamentaux de TCP vs UDP pour RDP ?
- Ce que TCP garantit
- Ce que UDP optimise
Ce que TCP garantit (et pourquoi cela coûte de la latence)
Le protocole de contrôle de transmission (TCP) est orienté connexion. TCP établit une session, numéros de paquets, les reconnaît, et retransmet ceux qui sont perdus. Ce design garantit une livraison fiable et dans l'ordre, ce qui est idéal pour les transferts de fichiers, le trafic web et les e-mails. Cependant, chaque retransmission ajoute un délai, et les algorithmes de contrôle de congestion ralentissent encore le débit lorsque la perte de paquets se produit.
Pour RDP, cela signifie qu'un seul paquet perdu peut bloquer les mises à jour d'écran suivantes jusqu'à ce que la récupération soit terminée. Sur des liens à latence élevée ou avec perte de paquets, TCP peut exagérer le jitter et créer un bureau "collant" où la souris et le clavier semblent retardés, même si le lien est techniquement actif.
Ce que UDP optimise (et où cela peut échouer)
Le protocole de datagramme utilisateur (UDP) est sans connexion et léger. UDP ne suit pas l'état, n'effectue pas de poignées de main et ne garantit pas la livraison ; il envoie simplement des datagrammes et laisse l'application gérer la perte ou l'ordre. L'absence de surcharge rend UDP attrayant pour la voix, la vidéo et les jeux, où la ponctualité est plus importante que la livraison parfaite.
Lorsque RDP utilise UDP, les graphiques et les entrées peuvent être livrés avec une latence plus faible et un débit plus élevé. Si un trame est perdue, RDP peut en envoyer une nouvelle au lieu d'attendre. Cependant, si la perte de paquets ou le jitter est élevé, la session peut montrer des artefacts visibles ou des rafraîchissements "en blocs", car le protocole privilégie la fraîcheur plutôt que la reconstruction garantie.
Comment RDP moderne utilise TCP et UDP ensemble ?
- Architecture de transport dual à partir de RDP 8.0
- RemoteFX, Graphiques et Entrée sur UDP
Architecture de transport dual à partir de RDP 8.0
À l'origine, RDP reposait uniquement sur TCP. À partir de RDP 8.0 (Windows 8 et Windows Server 2012), Microsoft a introduit un modèle de transport dual qui utilise TCP et UDP ensemble. RDP commence toujours par une connexion TCP pour négocier les capacités et la sécurité, puis tente d'établir un canal UDP parallèle pour les médias et les graphiques.
Si UDP est disponible et que les politiques le permettent, RDP déplace le trafic approprié sur le canal UDP tout en conservant TCP comme chemin de contrôle et de secours. Si UDP ne peut pas être établi, RDP continue entièrement sur TCP, garantissant la compatibilité avec les anciens réseaux et les pare-feu restrictifs.
RemoteFX, Graphiques et Entrée sur UDP
Avec le modèle à double canal, RDP peut envoyer des graphiques compressés, des bitmaps et certains événements d'entrée via UDP. Cela améliore la réactivité dans des scénarios WAN typiques, en particulier lorsque les bureaux affichent des interfaces utilisateur riches, des tableaux de bord en streaming ou des vidéos. RemoteFX et les optimisations associées ont été conçus en tenant compte de ce comportement.
En pratique, les utilisateurs remarquent des déplacements de fenêtres plus rapides, un défilement plus fluide et des rafraîchissements d'écran plus rapides lorsque l'UDP est actif sur des réseaux stables. Du côté de l'administrateur, ce comportement est principalement automatique ; la tâche principale est de s'assurer que l'UDP est autorisé et que la stratégie de groupe ne le désactive pas.
Comment la performance de l'UDP se compare-t-elle à celle du TCP ?
- Tableau de comparaison côte à côte
- Scénarios pratiques : WAN, VPN et LAN
Tableau de comparaison côte à côte
| Fonctionnalité / scénario | RDP sur TCP | RDP sur UDP |
|---|---|---|
| Fiabilité | Livraison rapide et ordonnée avec retransmission | Meilleure effort, aucune garantie de livraison ou de commande |
| Latence | Plus élevé, surtout en cas de perte | Plus bas, plus tolérant au jitter |
| Débit | Réduit par des accusés de réception et le contrôle de la congestion | Plus élevé, moins de surcharge de protocole |
| Meilleures conditions réseau | Liens à forte perte, imprévisibles ou fortement façonnés | Réseaux stables, à faible perte et à faible latence |
| Compatibilité pare-feu/VPN | Excellent ; utilise TCP 3389 | Peut nécessiter des règles UDP 3391 explicites sur les pare-feu et les VPN. |
| Comportement de secours | Toujours disponible | Utilisé lorsque disponible ; revient à TCP en cas de problèmes |
| Perception de l'utilisateur | Sûr mais parfois lent | “Rapide et fluide” lorsque les conditions sont favorables |
Dans des tests en laboratoire et sur le terrain, RDP sur UDP peut offrir plusieurs fois le débit effectif de TCP sur des réseaux propres, ce qui se traduit par une résolution plus élevée, une meilleure lecture vidéo et un mouvement de curseur plus fluide. L'amélioration réelle dépend de la bande passante, de la perte et de la manière dont le réseau façonne le trafic de manière agressive.
Scénarios pratiques : WAN, VPN et LAN
Sur un réseau local câblé avec une faible latence et une perte de paquets négligeable, l'UDP est généralement le grand gagnant. Les utilisateurs bénéficient d'une réactivité quasi locale, même lorsqu'ils se connectent depuis un autre étage ou bâtiment. Sur un lien WAN ou SD-WAN géré, l'UDP a également tendance à mieux performer, tant que QoS est configuré et la perte de paquets reste modeste.
Sur des VPNs surchargés, des points d'accès mobiles ou des liaisons par satellite, le TCP peut offrir une expérience plus stable. Ses mécanismes de contrôle de congestion peuvent s'adapter à des conditions variées, tandis que le trafic UDP peut devenir saccadé ou visuellement dégradé. Dans ces scénarios, la priorité est une session prévisible, même si légèrement plus lente.
Quand préférer UDP à TCP pour les sessions RDP ?
- Conditions idéales pour RDP sur UDP
- Lorsque TCP est le paramètre par défaut le plus sûr
Conditions idéales pour RDP sur UDP
Pour la plupart des déploiements modernes, l'UDP devrait être le chemin cible chaque fois que cela est possible. L'UDP est idéal lorsque le réseau a une latence stable, une faible perte et une marge de bande passante raisonnable. Les LANs à haute vitesse, bien gérés MPLS ou des circuits SD-WAN, et les liens de centre de données à succursale correspondent généralement à ce profil.
UDP est également le meilleur choix lorsque les utilisateurs finaux travaillent avec des applications riches en médias, des tableaux de bord avec des mises à jour fréquentes ou des frameworks UI qui redessinent de grandes portions de l'écran. Pour ces charges de travail, réduire la latence a plus d'impact sur la performance perçue que de maximiser la fiabilité brute.
Lorsque TCP est le paramètre par défaut le plus sûr
TCP reste précieux dans des réseaux hostiles ou imprévisibles. Si les utilisateurs se connectent via le Wi-Fi de l'hôtel, des points d'accès publics ou des chemins avec des micro-coupures fréquentes, la fiabilité et le comportement de congestion de TCP peuvent être plus indulgents. De même, certains anciens appareils VPN, proxys ou dispositifs d'inspection gèrent mal l'UDP 3391, obligeant le RDP à utiliser TCP indépendamment de la configuration.
Si les exigences réglementaires ou d'audit nécessitent des règles réseau simples et facilement explicables, les administrateurs peuvent également choisir de se standardiser sur TCP pour certains groupes d'utilisateurs. Dans ces cas, l'objectif est la clarté et la conformité, tandis que l'UDP est réservé aux sites de confiance et aux points de terminaison gérés.
Comment régler RDP pour une utilisation optimale de l'UDP ?
- Vérifier la version et les capacités RDP
- Ouvrir et valider les ports requis
- Paramètres de stratégie de groupe pour UDP et expérience
- QoS et optimisations au niveau du réseau
- Surveiller quel transport RDP est utilisé
Vérifier la version et les capacités RDP
Le support UDP commence avec RDP 8.0. Assurez-vous que le client RDP et l'hôte exécutent des versions prises en charge telles que Windows 8 / 10 / 11 ou Windows Server 2012 et ultérieur. Selon Microsoft Learn, l'activation des nouvelles fonctionnalités RDP nécessite souvent des mises à jour spécifiques de Windows ainsi que les rôles des services de bureau à distance.
Sur un client Windows, vous pouvez vérifier la version de base de RDP dans le registre :
reg query "HKLM\SOFTWARE\Microsoft\Terminal Server Client" /v RDPCoreVersion
Dans les anciens domaines, confirmez que les stratégies de groupe ne forcent pas le RDP en modes de compatibilité qui désactivent l'UDP.
Ouvrir et valider les ports requis
RDP utilise port TCP 3389 pour la connexion de base et le port UDP 3391 pour le chemin multimédia optimisé dans les configurations standard. Les pare-feu, les routeurs et les passerelles VPN doivent autoriser ces ports dans les deux sens lorsque cela est applicable.
Document qui vérifie quels appareils effectuent le NAT ou l'inspection et s'assure que l'UDP 3391 n'est pas silencieusement abandonné ou limité en débit. Utilisez des outils simples comme
Test-NetConnection
ou des captures de paquets pour confirmer que les paquets UDP atteignent le serveur et que les réponses sont visibles du côté client.
Paramètres de stratégie de groupe pour UDP et expérience
Sur l'hôte RDP ou l'hôte de session, ouvrez la gestion des stratégies de groupe et accédez à :
Configuration de l'ordinateur > Modèles administratifs > Composants Windows > Services de bureau à distance > Hôte de session de bureau à distance > Environnement de session à distance
Les paramètres clés incluent :
- Optimiser pour l'expérience plutôt que pour le RD Gateway ou des optimisations d'expérience similaires.
- Utiliser le transport UDP → défini sur Activé.
Évitez les politiques conflictuelles qui désactivent l'UDP en même temps que vous activez les optimisations d'expérience. Après les modifications, exécutez
gpupdate /force
et reconnecter les sessions de test pour confirmer que l'UDP est maintenant utilisé.
QoS et optimisations au niveau du réseau
Dans des environnements plus vastes, les politiques de qualité de service (QoS) peuvent améliorer considérablement la réactivité de RDP. Marquez le trafic RDP, en particulier les flux UDP, avec une valeur DSCP appropriée et assurez-vous que les routeurs WAN respectent ces marquages. Envisagez de placer le trafic RDP dans une classe de priorité ou de transfert assuré plutôt que de le laisser rivaliser avec les transferts en masse.
En même temps, maintenez le MTU cohérent sur les VPN et les liens WAN pour éviter la fragmentation, ce qui peut nuire aux performances UDP. Les équipes réseau devraient également surveiller la perte et le jitter sur les chemins utilisés par le trafic de bureau à distance pour identifier les circuits problématiques.
Surveiller quel transport RDP est utilisé
Windows enregistre les choix de transport RDP dans le Visualiseur d'événements sous le journal RemoteDesktopServices-RdpCoreTS. Les événements courants incluent :
- ID d'événement 131 : session RDP établie en utilisant uniquement TCP
- ID d'événement 132 : transport UDP en cours d'utilisation
- ID d'événement 140 : UDP tenté mais est revenu à TCP
Examinez ces événements lorsque les utilisateurs signalent des bureaux "lents". Combinez-les avec des métriques réseau et des captures de paquets pour décider si la solution consiste à activer UDP, à ajuster la QoS ou à simplifier les chemins réseau.
Pourquoi RDP revient-il à TCP pour le dépannage ?
- Problèmes de connectivité et de pare-feu
- Politique, Client et Incompatibilités de Serveur
Problèmes de connectivité et de pare-feu
Si RDP utilise constamment TCP même sur des clients et serveurs modernes, commencez par des vérifications de connectivité de base. Confirmez que l'UDP 3391 est autorisé de bout en bout, pas seulement sur l'hôte Windows. Les pare-feu qui autorisent le TCP 3389 mais qui laissent tomber silencieusement l'UDP 3391 forceront RDP en mode uniquement TCP.
Pour les sites distants, vérifiez que les politiques VPN ou les appareils SD-WAN ne réécrivent pas ou ne bloquent pas l'UDP. Certaines piles de sécurité nécessitent des règles explicites ou des "définitions d'application" pour le canal UDP de RDP. Des captures de paquets des deux côtés d'un tunnel peuvent rapidement révéler si les paquets UDP effectuent le trajet aller-retour.
Politique, Client et Incompatibilités de Serveur
La stratégie de groupe peut explicitement désactiver le transport UDP, même si le réseau le permet. Vérifiez à la fois les politiques de l'ordinateur et de l'utilisateur pour les paramètres RDP et assurez-vous qu'aucun ancien modèle ne remplace les nouveaux paramètres par défaut. De même, les clients RDP hérités peuvent manquer d'un support complet de l'UDP ou peuvent être limités par la politique locale.
Validez également que la configuration des services de bureau à distance du serveur est conforme aux normes de sécurité du domaine. Les modèles de durcissement des projets précédents désactivent parfois les fonctionnalités de protocole plus récentes. En cas de doute, comparez les paramètres avec les normes et la documentation Microsoft actuelles pour votre version de Windows Server.
Améliorez votre expérience RDP avec TSplus Remote Access
Dépannage des performances RDP ou planification d'une architecture d'accès à distance plus évolutive ? TSplus Remote Access vous permet de publier des bureaux et des applications sur le web avec une passerelle légère, une sécurité TLS et une gestion RDP optimisée.
Besoin d'une publication d'application sécurisée et abordable sans la complexité de niveau Citrix ? Commencez votre essai gratuit de TSplus et voyez à quelle vitesse vous pouvez déployer des sessions distantes rapides et optimisées pour UDP.
Conclusion
Il n'y a pas de "gagnant" unique entre RDP sur UDP et TCP. UDP offre la meilleure expérience utilisateur sur des réseaux propres et bien gérés en fournissant des sessions à faible latence et à haut débit. TCP reste la colonne vertébrale pour la compatibilité et la résilience lorsque les conditions sont moins prévisibles.
Le véritable objectif est de permettre à RDP moderne d'utiliser UDP chaque fois que cela est possible, tout en préservant un retour automatique à TCP lorsque cela est nécessaire. En validant les versions, en ouvrant les bons ports, en ajustant la stratégie de groupe et en surveillant l'utilisation du transport, vous pouvez fournir des bureaux à distance rapides et fiables. TSplus Remote Access aide à transformer cet ajustement en une plateforme cohérente et sécurisée pour vos utilisateurs.
Essai gratuit de TSplus Remote Access
Alternative ultime à Citrix/RDS pour l'accès aux bureaux/applications. Sécurisé, rentable, sur site/cloud