Pourquoi RDP est-il lent sur une connexion rapide ? — Séparer la saisie, l'affichage et le réseau

Un test de débit annonce des centaines de Mbit/s, et pourtant, dans le Bureau à distance, les caractères apparaissent avec un temps de retard. Faites défiler une page remplie de photos et l’écran saccade encore davantage.

La clé pour comprendre cet écart est la suivante : pouvoir transporter beaucoup de données et obtenir une réponse rapide à une action sont deux choses distinctes. De plus, l’écran qui revient en guise de réponse est produit sur le PC hôte et affiché sur le PC devant vous. Ce n’est pas un travail que la liaison réseau accomplit à elle seule.¹

Sur le même écran distant, suivons ce qui change lorsque l’on passe de la frappe au défilement, puis à une recherche dans une application métier. Les sections 1 à 4 expliquent le mécanisme, et la section 5 et les suivantes constituent la partie investigation, pour examiner concrètement le problème.

1. Une liaison plus rapide ne raccourcit pas nécessairement l’attente d’une réponse

Supposons que vous tapiez un caractère dans le Bloc-notes de la machine distante. Ce que vous voyez, c’est l’écran juste devant vous, mais le Bloc-notes s’exécute sur le PC hôte. Votre action est envoyée là-bas, l’information sur l’écran modifié revient ici, et le caractère apparaît.

Quelle partie de cet aller-retour les « 500 Mbit/s » d’un test de débit représentent-ils donc ?

C’est un chiffre indiquant quelle quantité de données peut être transportée en une seconde. Cette capacité compte quand le fichier que vous téléchargez est volumineux. Ce que vous remarquez en tapant un seul caractère, en revanche, c’est le temps écoulé entre l’appui sur la touche et le retour du résultat. C’est comme la différence entre élargir une route et raccourcir la distance jusqu’à destination.¹

Pour les besoins de l’explication, admettons que l’action mette 50 millisecondes à atteindre l’hôte et que l’information d’écran qui en résulte mette 50 millisecondes à revenir. Dans ce cas, le temps passé sur le seul réseau totalise 100 millisecondes, soit 0,1 seconde. Le temps de traitement sur les PC aux deux extrémités est laissé de côté pour l’instant.

flowchart TB
    accTitle: Exemple du temps réseau avant le retour du résultat d'un caractère
    accDescr: Un exemple supposant 50 millisecondes dans chaque sens pour les besoins de l'explication. Il exclut le temps de traitement aux deux extrémités et ne représente pas un nombre de paquets par touche.
    A["Taper un caractère en local"] -->|"Aller, 50 ms"| B["L'hôte reçoit la saisie"]
    B --> C["Envoyer l'écran avec la saisie appliquée"]
    C -->|"Retour, 50 ms"| D["Le résultat arrive sur votre machine"]

Figure 1 : Si l’aller prend 50 millisecondes et le retour 50 millisecondes, le réseau seul représente 0,1 seconde. Ce ne sont pas des valeurs mesurées.

Ce temps pour traverser le réseau et revenir s’appelle le temps d’aller-retour (RTT). Même si vous passez à une liaison capable de transporter davantage, l’attente d’une réponse de la figure 1 reste identique tant que le temps d’aller-retour reste le même.¹

C’est pourquoi les téléchargements peuvent être rapides alors que la frappe accuse toujours un temps de retard. Considérons ensuite le cas où, sur la même connexion, la frappe ne pose aucun problème mais le défilement devient poussif.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (7 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Le défilement augmente le travail d’envoi de l’écran

Quand vous ajoutez un caractère dans le Bloc-notes, seule une petite partie de l’écran change visuellement. Faites défiler une page garnie de photos, en revanche, et une large zone de l’affichage change d’une image à l’autre.

RDP n’envoie pas l’écran entier non compressé à chaque fois. Il envoie les régions qui ont changé et limite le trafic par une compression et une mise en cache adaptées au contenu. La quantité de travail nécessaire à la mise à jour et à l’envoi diffère entre l’ajout d’un caractère et des photos qui défilent sans cesse.²

flowchart TB
    accTitle: Comment la charge d'écran change entre la frappe et le défilement
    accDescr: Un petit changement de caractère et une mise à jour continue sur une large zone diffèrent par la nature du travail de production et d'envoi de l'écran.
    A["Ajouter un caractère dans le Bloc-notes"] --> B["Une petite région change"]
    C["Faire défiler un écran plein de photos"] --> D["Une large zone change en continu"]
    B --> E["Compresser et transférer selon le changement"]
    D --> E

Figure 2 : Sur la même connexion, la quantité de travail diffère entre l’ajout d’un caractère et une large zone en mouvement continu.

Il en résulte que tout peut sembler léger pendant la lecture d’un document statique, tandis que le transfert graphique se retrouve à court de marge dès que vous commencez à faire défiler. Augmenter la résolution du côté distant ou ajouter des écrans accroît également ce qui doit être produit et envoyé.²

C’est seulement maintenant qu’apparaît la raison pour laquelle baisser la résolution et comparer vaut la peine. Ce n’est pas une formule magique pour accélérer RDP, mais une expérience visant à voir si la réactivité revient une fois réduit le travail de production et d’envoi de l’écran. La section 5 explique comment l’essayer en détail.

Si la frappe va bien mais que seul le défilement est poussif, c’est peut-être parce que la même liaison prend en charge bien plus de mises à jour d’écran. Qu’en est-il alors du cas où la liaison a encore de la marge mais où l’écran ne suit pas ?

3. Même avec une liaison inoccupée, le PC qui produit l’écran peut vous faire attendre

L’écran est traité avant d’être envoyé et après avoir été reçu

Quand vous faites défiler une page de photos, le PC hôte met à jour l’affichage et convertit puis compresse l’information d’écran en une forme plus facile à envoyer. C’est l’encodage. Le PC devant vous reconvertit l’information qui arrive en une forme qu’il peut afficher. Ce côté-là s’appelle le décodage.¹

flowchart TB
    accTitle: Le traitement de l'écran a lieu des deux côtés de la liaison
    accDescr: La compression sur l'hôte, le transfert sur le réseau, puis le décodage et l'affichage sur votre machine sont des étapes distinctes, et les mises à jour d'écran prennent du retard si l'une d'elles ne suit pas.
    A["L'hôte produit et compresse l'écran"] --> B["La liaison transporte l'information d'écran"]
    B --> C["La machine locale la reconvertit en forme affichable"]
    C --> D["Affiché sur l'écran local"]

Figure 3 : Compresser sur l’hôte, transporter sur la liaison, reconvertir en affichage sur la machine locale. Chaque étape est un travail effectué à un endroit différent.

Supposons par exemple que la compression de l’écran sur l’hôte prenne du temps. Même avec une liaison inoccupée, vous attendez que l’information à envoyer soit prête. À l’inverse, même lorsque l’information est arrivée, la mise à jour de l’écran est tardive si le PC local ne suit pas au décodage et à l’affichage.³

Le réflexe est de se dire que le PC du bureau est puissant et que n’importe quoi fera l’affaire côté local, mais le PC local a toujours pour tâche d’afficher l’écran qu’il reçoit. La marge sur la liaison et la marge dans le traitement aux deux extrémités sont deux choses distinctes.

Si une seule application se fige, c’est peut-être sa réponse que vous attendez

Considérons maintenant un cas où, sur le même écran distant, appuyer sur Rechercher dans une application métier la fige plusieurs secondes. Supposons en parallèle que vous puissiez taper normalement dans une fenêtre du Bloc-notes ouverte à côté.

Dans ce cas, vous voulez voir ce que l’application métier attend. L’application sur l’hôte demande peut-être à une base de données distincte d’exécuter la recherche, et la réponse tarde à revenir. Lire un fichier depuis un dossier partagé produit le même type d’attente.⁴

flowchart TB
    accTitle: Il y a un autre interlocuteur au-delà de RDP
    accDescr: Montre le cas où, en dehors du trafic reliant le client local et l'hôte, l'application sur l'hôte attend une réponse d'un serveur métier.
    A["Client local"] -->|"RDP"| B["Application métier sur l'hôte"]
    B -->|"Requête de recherche ou de fichier"| C["Base de données et dossiers partagés"]
    C -->|"La réponse que l'application attend"| B

Figure 4 : L’application métier au-delà de la connexion RDP attend peut-être à son tour une réponse d’un autre serveur encore.

De plus, lorsque le code responsable de l’écran et de la saisie d’une application se charge d’une longue tâche, il ne peut pas passer à la saisie ou à la mise à jour d’écran suivante. Un thread d’interface WPF occupé longtemps produit exactement ce type de réponse retardée. Ne regarder que l’utilisation globale du processeur peut vous rendre aveugle à une attente dans le code qui gère l’écran.⁵

Attendre devant un écran RDP ne signifie pas que c’est RDP qui vous fait attendre. Cette différence — « le Bloc-notes fonctionne mais seule la recherche se fige » — est un indice que vous pouvez trouver avant de modifier le moindre paramètre réseau.

4. Bilan intermédiaire : la vitesse de la liaison n’est qu’une partie de la réactivité

Revenons à la question initiale : pourquoi est-ce lent quand la liaison est rapide ?

Dans le cas de la frappe, il y avait une attente de réponse entre l’envoi de l’action et la réception du résultat. Dans le cas du défilement, la quantité d’écran à mettre à jour et à envoyer a augmenté. Et l’application qui produit cet écran, ainsi que le traitement graphique sur les PC aux deux extrémités, prennent également du temps.

Un grand chiffre issu d’un test de débit ne vous dit pas à lui seul si ces trois éléments se portent bien. Qui plus est, le serveur de test de débit et l’hôte RDP situé au-delà d’un VPN ou d’une passerelle sont atteints par des chemins différents. Le sens montant sur l’hôte qui pousse l’écran, et la congestion en chemin, interviennent aussi.¹⁴

Le confort d’utilisation de RDP est déterminé non seulement par ce qui peut être transporté, mais par la rapidité avec laquelle le résultat d’une action devient visible. Ainsi s’achève l’explication du mécanisme. Lorsque vous enquêtez réellement sur la lenteur, servez-vous des sections d’investigation ci-dessous pour choisir la comparaison adaptée à votre symptôme.

5. Investigation : commencez par comparer la même action, une condition à la fois

Les exemples d’investigation supposent le client Connexion Bureau à distance de Windows et un hôte sous Windows 11 ou Windows Server. Les exemples de commandes visent Windows PowerShell 5.1. Sur un appareil d’entreprise, limitez les comparaisons au périmètre autorisé par votre administrateur, et sauvegardez votre travail avant de modifier des paramètres et de vous reconnecter.

Utilisez les trois cas ci-dessus comme point d’entrée pour choisir une comparaison. Le tableau n’est pas un verdict sur la cause mais un point de départ pour l’investigation.

Si l’écran de connexion met longtemps à apparaître, ou si tout bloque à l’authentification seule, commencez par examiner les enregistrements relatifs à l’établissement de la connexion et à l’authentification. Le point d’entrée de cette investigation diffère de la saisie et du défilement après connexion traités ici.

Une autre application est-elle retardée de la même façon ?

Tapez à peu près la même quantité de texte dans l’application problématique et dans le Bloc-notes. Comparer d’abord au sein de la même session distante vous permet de voir la différence entre applications sans changer l’hôte ni la liaison. Dans le Gestionnaire des tâches, vérifiez le processeur, la mémoire et le disque de l’application visée sur l’hôte, ainsi que la charge du client RDP sur votre propre machine.⁴

Lorsque vous comparez sur un autre client ou un autre chemin autorisé, répétez-y la même action et consignez également le résultat après retour en arrière. Sur un hôte utilisé par plusieurs utilisateurs, assurez-vous de regarder votre propre session et vos propres processus.

flowchart TB
    accTitle: Limitez les conditions changées à la fois
    accDescr: Un flux qui fixe une action reproduisant le problème dans l'état initial, ne change qu'une condition et compare, puis vérifie aussi le résultat après retour en arrière.
    A["Même action avec les paramètres d'origine"] --> B["Changer une seule condition"]
    B --> C["Répéter la même action"]
    C --> D["Revenir en arrière et vérifier de nouveau"]
    D --> E["Consigner la condition qui a amélioré les choses"]

Figure 5 : Répétez la même action dans l’état initial, après le changement et après retour en arrière, et notez quelle condition a fait la différence.

Comparer en travaillant sur l’écran physique de l’hôte est également instructif. Notez toutefois que la session et les conditions d’affichage peuvent différer entre le travail local et RDP. Alignez l’utilisateur, les données et l’état de l’application, et n’imputez pas la cause à la liaison au seul motif que « c’est rapide sur l’écran physique ».

Quand le défilement est poussif, baissez la résolution côté distant

Changez d’abord soit le nombre d’écrans, soit la résolution, puis faites défiler la même page. Avec mstsc sous Windows, vous pouvez comparer via les paramètres d’affichage avant connexion ou en spécifiant une largeur et une hauteur. Vérifiez que le bureau de l’hôte a réellement changé de taille, et pas seulement que la fenêtre sur votre machine a rapetissé. Il arrive qu’un grand écran soit simplement affiché en réduction.⁶⁷

3840 × 2160 compte quatre fois plus de pixels que 1920 × 1080, mais cela ne signifie pas que le trafic est toujours quadruplé. Cela varie selon les régions modifiées et selon l’efficacité de la compression. Baisser la résolution change aussi le traitement graphique aux deux extrémités, pas seulement le trafic : si cela améliore les choses, prenez-le comme la zone où se trouve l’indice.²³

flowchart TB
    accTitle: Ce qu'une comparaison à résolution réduite peut vous apprendre
    accDescr: Baisser la résolution côté distant peut modifier à la fois le traitement graphique et la charge de transfert, si bien qu'une amélioration seule ne permet pas d'imputer la cause à la liaison.
    A["Baisser la résolution côté distant"] --> B["Le traitement graphique sur l'hôte change"]
    A --> C["La quantité d'informations envoyées change"]
    A --> D["Le traitement d'affichage sur votre machine change"]

Figure 6 : Changer la résolution est une comparaison qui affecte non seulement la liaison mais aussi le traitement graphique sur l’hôte et sur votre propre machine.

Changer plusieurs conditions à la fois, par exemple passer à un seul écran en basse résolution, ne donne qu’une comparaison grossière. Après amélioration, revenez en arrière une condition à la fois pour séparer les effets, et choisissez les paramètres du quotidien en tenant compte aussi de la lisibilité du texte.

Est-ce que ça ralentit dès qu’une copie ou une impression démarre ?

Plus que l’écran circule sur RDP : les informations pour les lecteurs, les imprimantes et d’autres périphériques voyagent aussi. La redirection, qui rend vos périphériques locaux utilisables côté distant, peut augmenter la charge réseau et de traitement pendant son utilisation. Suspendez les copies, la synchronisation cloud et les impressions que vous avez vous-même lancées, dans la limite de ce qui vous est permis, puis comparez.⁴

flowchart TB
    accTitle: Voir la période avant et après l'incident sur une seule chronologie
    accDescr: Consigner la même action et la charge avant un transfert, pendant celui-ci et après son arrêt, et comparer la façon dont l'incident se rattache à ce travail.
    A["Action et charge avant le transfert"] --> B["Action et charge pendant le transfert"]
    B --> C["Action et charge après l'arrêt"]
    C --> D["Si l'incident et le retour à la normale concordent"]

Figure 7 : Observez comment la lenteur de la même action et la charge évoluent avant le transfert, pendant celui-ci et après son arrêt.

Vous pouvez aussi comparer la redirection des périphériques inutiles un à un. Ce n’est pas une procédure pour désactiver d’un bloc les périphériques audio et de saisie dont l’activité a besoin, ni pour arrêter de votre propre initiative les processus de sauvegarde ou de sécurité de l’entreprise.

6. Investigation : confirmez par des chiffres où se situe l’attente

Confirmez les comparaisons de la section 5 par des mesures. Pour la frappe, regardez les chiffres du réseau et de l’attente de saisie ; pour le défilement, ceux du traitement graphique.

Depuis votre machine : examinez l’aller-retour réseau et la connexion TCP

Ce qui suit est un exemple sur votre propre client Windows. Il suppose que vous vous connectez directement à l’hôte RDP via le réseau local d’entreprise ou un VPN autorisé, et que l’hôte utilise le port TCP standard 3389. Passer par une passerelle RD ou par Azure Virtual Desktop change à la fois ce que vous vérifiez et le chemin emprunté. N’exposez pas de ports et ne modifiez pas les paramètres du pare-feu.

$target = Read-Host 'Nom ou adresse IP d''un hôte RDP que vous êtes autorisé à examiner'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Indiquez l''hôte auquel se connecter.'
}

# Regarder plusieurs fois le temps de réponse ICMP. Un échec seul ne prouve pas que RDP est injoignable.
ping.exe -n 20 $target

# Une vérification limitée aux configurations se connectant directement au port TCP standard 3389.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

ping examine le temps de réponse à ICMP. Si les valeurs oscillent fortement pendant la plage horaire lente, consignez-le. ICMP peut aussi être bloqué, auquel cas rien ne répond. Inversement, une série de petites valeurs ne signifie pas que vous ayez examiné le transfert graphique RDP ou le traitement applicatif.⁸

TcpTestSucceeded: True est un résultat indiquant que la connexion TCP à ce port a réussi. Il ne mesure ni la bande passante, ni UDP, ni la fluidité de l’utilisation et de l’écran après authentification. Test-NetConnection ne possède pas de commutateur -UDP permettant d’examiner UDP.⁹

Vingt sondes ping constituent une observation courte. Pour un incident intermittent, recoupez l’heure du symptôme avec les informations de connexion. Azure Virtual Desktop met aussi à disposition le RTT et la bande passante estimée par connexion, mais n’écartez pas de brefs blocages sur la seule foi des moyennes.¹

Sur l’hôte : examinez l’attente avant que l’application ne récupère la saisie

Ouvrez perfmon.exe à l’intérieur de la session distante sur l’hôte et, là où l’environnement le prend en charge, ajoutez User Input Delay per Process ou User Input Delay per Session. Sélectionner la session et le processus visés permet d’observer l’attente entre la mise en file de la saisie et sa récupération par l’application.¹⁰

flowchart TB
    accTitle: L'intervalle que mesure User Input Delay
    accDescr: L'intervalle mesuré va de la file d'attente de saisie sur l'hôte jusqu'à la récupération de la saisie par l'application, et il n'inclut ni le réseau ni l'affichage de l'écran en amont et en aval.
    A["La saisie arrive de votre machine"] --> B["Entre dans la file d'attente de saisie sur l'hôte"]
    B -->|"C'est ce qui est mesuré"| C["L'application récupère la saisie"]
    C --> D["Traitement applicatif et transfert graphique"]
    D --> E["Affiché sur votre machine"]

Figure 8 : Ce qui est mesuré, c’est l’attente dans la file de saisie sur l’hôte. Ce n’est pas le temps total avant que le résultat ne devienne visible sur votre machine.

La valeur est la plus longue attente au sein de l’intervalle de mesure. Elle est prise en charge à partir de Windows 10 version 1809 et de Windows Server 2019, et sur ces cibles aucune entrée de registre n’est nécessaire pour l’activer. Observez d’abord à l’intervalle par défaut d’une seconde. Vérifiez les noms affichés, les compteurs disponibles et les autorisations requises par rapport à votre propre environnement.¹⁰

Le nom d’instance standard par processus est SessionID:ProcessID <Process Image>. Depuis PowerShell dans la même session, notez l’heure et l’identifiant de session.¹⁰¹¹

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

Afficher les sessions d’autres utilisateurs peut exiger des autorisations supplémentaires. Recoupez avec les enregistrements de l’administrateur si nécessaire, et retirez des journaux que vous partagez les noms d’utilisateur et informations d’hôte dont l’activité n’a pas besoin.¹¹

Même quand cette valeur est faible, le traitement après récupération de la saisie par l’application et le délai jusqu’au retour de l’écran résultant subsistent tous deux. L’intervalle mesuré diffère du temps d’aller-retour de la section 1 et du temps perçu entre l’appui sur une touche et l’apparition du caractère.

Sur l’hôte : examinez si les mises à jour d’écran sont envoyées intégralement

Pour les saccades pendant le défilement, utilisez les compteurs RemoteFX Graphics là où ils sont disponibles. Vérifiez le nom de la session visée avec query session ou qwinsta et sélectionnez l’instance correspondante. Ce qu’un compteur mesure et sa disponibilité doivent être confirmés au regard du système d’exploitation, de la configuration de l’hôte et de vos autorisations.³

Pendant une opération qui met l’écran à jour, comparez Input Frames/Second et Output Frames/Second. Si la sortie est inférieure à l’entrée, des images sont perdues en chemin. Regarder les valeurs de Frames Skipped/Second ventilées par ressources insuffisantes côté hôte, réseau et client vous donne un indice pour circonscrire où chercher.³

flowchart TB
    accTitle: Circonscrire où chercher à partir des images perdues
    accDescr: Comparer le nombre d'images en entrée et en sortie pendant une opération qui met l'écran à jour et, en s'aidant des compteurs indiquant la raison des pertes, recouper avec la charge de traitement, de réseau et d'affichage.
    A["Comparer entrée et sortie pendant le défilement"] --> B["Si la sortie est plus basse, chercher des images perdues"]
    B --> C["Regarder les compteurs ventilés par raison"]
    C --> D["Recouper avec la charge hôte, réseau et locale"]

Figure 9 : Comparez entrée et sortie pendant le défilement, et recoupez la raison des images perdues avec la charge sur l’hôte, la liaison et votre propre machine.

Lorsque le nombre d’images est déjà faible du côté entrée, il se peut simplement que l’application ne mette pas souvent l’écran à jour. Un faible nombre d’images sur un écran statique n’est pas anormal. S’il y a des mises à jour et que c’est tout de même lent, regardez aussi Average Encoding Time pour voir si la compression sur l’hôte prend du temps.³

Une remarque sur la lecture de la documentation de mesure. Le schéma de la section 1 est conceptuel, destiné à comprendre un transfert graphique ordinaire, et non une affirmation qu’un paquet d’aller-retour indépendant est envoyé par touche. Certaines configurations transfèrent la vidéo et l’audio par un mécanisme distinct. N’utilisez les journaux de qualité de connexion d’Azure Virtual Desktop, et la documentation des compteurs Graphics qui couvre encore d’anciennes configurations, qu’après avoir confirmé à quoi la fonctionnalité s’applique. Ne lisez pas les chiffres d’une telle documentation comme une spécification commune du type « tout RDP est plafonné à 30 images par seconde ».²¹³

7. Investigation : choisissez les paramètres UDP et GPU en fonction de ce que vous avez trouvé

Si le réseau est suspect, confirmez d’abord le chemin et le transport réels

RDP utilise TCP ou UDP selon la configuration et les conditions réseau. La stratégie « Sélectionner les protocoles de transport RDP » permet de choisir entre un réglage utilisant UDP ou TCP et un réglage utilisant TCP uniquement. Comme il existe aussi un comportement qui utilise TCP lorsqu’une connexion UDP ne peut pas être établie, le fait que vous soyez connecté ne vous dit rien du transport. Confirmez-le à partir des informations de connexion du client, des journaux de diagnostic du produit et des enregistrements réseau de l’administrateur.¹²

flowchart TB
    accTitle: Confirmer le transport avant de comparer les paramètres réseau
    accDescr: Distinguer une connexion directe ordinaire d'une connexion passant par une passerelle ou un service, confirmer le chemin et le transport réels, et seulement ensuite effectuer les comparaisons autorisées.
    A["Le client utilisé et la configuration de connexion"] --> B["Confirmer le chemin réel et si c'est TCP ou UDP"]
    B --> C["Recouper avec l'heure du symptôme"]
    C --> D["Comparer un à un les seuls paramètres nécessaires"]

Figure 10 : Confirmez le transport et le chemin utilisés, recoupez-les avec le symptôme, et seulement ensuite comparez les paramètres nécessaires.

RDP Shortpath dans Azure Virtual Desktop est le mécanisme qui établit un chemin UDP pour ce service. Y compris la façon dont les chemins directs et les relais sont utilisés, il ne peut pas figurer dans le même tableau de paramètres qu’une connexion directe à un PC interne avec mstsc. Lorsque Shortpath ne peut pas être établi, la connexion retombe sur une connexion fondée sur TCP.¹³

Ne modifiez pas les choses en bloc en partant de l’idée que désactiver UDP accélère. Alignez le transport utilisé, les stratégies et les conditions de VPN ou de passerelle, puis comparez. Désactiver le pare-feu ou l’authentification, ou exposer directement le port RDP sur Internet, ne sont pas des remèdes à appliquer.

Si le traitement graphique est suspect, vérifiez si le GPU est utilisé pour cela

Même lorsqu’un GPU est présent, il n’en découle pas que l’affichage de l’application hôte, l’encodage de RDP et le décodage sur votre machine l’utilisent tous. La documentation de Microsoft sur la configuration du GPU configure et vérifie de même séparément l’affichage dans la session distante et l’encodage matériel des images. Examinez les versions de système d’exploitation prises en charge, les pilotes, les stratégies et les exigences côté client.¹⁴

Si la section 6 a montré que le temps de compression est long, c’est à ce moment-là qu’il faut vérifier l’usage du GPU pour l’encodage. Modifier les paramètres d’encodage pour une application qui attend dans la file de saisie vise le mauvais endroit. Un travail où l’on veut un texte lisible et un travail où l’on veut une vidéo fluide appellent aussi des choix différents entre qualité d’image, trafic et charge de traitement.¹⁴²

Les développeurs d’applications métier peuvent retracer les attentes internes à une application en consignant séparément l’heure de réception d’un événement de saisie, le début et la fin des traitements de base de données et de fichiers, et le moment où le résultat a atteint l’interface. Une conception qui évite que les travaux lourds ne s’installent sur le thread d’interface compte aussi. Notez qu’un journal de fin de traitement sur l’hôte n’est pas un enregistrement de l’achèvement de l’affichage sur votre propre écran.⁵

8. Notes qu’il vaut la peine de laisser en transmettant l’investigation

Décrivez l’action lente de façon concrète, comme « taper dans le Bloc-notes est normal, mais faire défiler des photos bloque ». Laissez également les conditions essayées et les résultats.

Heure du symptôme, avec fuseau horaire :
Système d'exploitation de l'hôte, client utilisé et versions :
Connexion directe / VPN / passerelle RD / Azure Virtual Desktop, etc. :
L'action et l'application lentes, et la réaction des autres applications de la même session :
Résolution et nombre d'écrans côté distant :
Copies, impressions et assimilés en cours au même moment :
La condition unique changée, et le résultat après retour en arrière :
Charge et compteurs observés sur l'hôte et sur votre machine :

Ce qui peut être transporté, le temps qu’on attend une réponse, et le temps qu’il faut pour produire et afficher l’écran. Une fois cette distinction claire, on cesse d’attribuer « RDP est lent » à une cause unique et on peut partir de l’action qui est lente maintenant.

Articles liés

• Comment penser l’isolation des sessions Windows
• Circonscrire sans risque un disque Windows à 100 %
• Pourquoi « il reste 1 seconde » dure-t-il si longtemps ?

Liens de référence

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Un test de débit annonce des centaines de Mbit/s, alors pourquoi la saisie RDP est-elle lente ?

La vitesse à laquelle de grandes quantités de données circulent et le temps que met une action à revenir sont deux choses distinctes. L'envoi de la saisie, le traitement de l'application sur l'hôte, la compression de l'écran, son transfert et son affichage sur votre propre machine interviennent tous. Le serveur de test de débit et l'hôte RDP sont en outre atteints par des chemins réseau différents.

La frappe va bien, seul le défilement saccade. Est-ce un problème de réseau ?

On ne peut pas le réduire au seul réseau. Quand les mises à jour d'écran augmentent, l'affichage et la compression sur l'hôte, le transfert, ou le décodage et l'affichage sur votre machine peuvent ne pas suivre. Changez la résolution distante et le nombre d'écrans un à la fois et comparez, puis regardez les compteurs graphiques si nécessaire.

Si le ping est rapide, la communication RDP est-elle saine ?

Cela seul ne tranche pas. Le ping mesure la réponse à ICMP et ne mesure ni le transfert graphique RDP ni le traitement applicatif. Dans les configurations passant par une passerelle RD ou similaire, le chemin peut ne pas correspondre non plus. En l'absence de réponse, distinguez un ICMP bloqué du fait que RDP lui-même soit injoignable.

User Input Delay est-il le temps entre l'appui sur une touche et l'apparition du caractère ?

Non. C'est un compteur qui mesure combien de temps une saisie attend sur l'hôte, une fois mise en file, avant que le processus ne la récupère. Ce n'est pas le délai perçu, qui inclut l'aller-retour réseau, le traitement applicatif après récupération de la saisie, ainsi que la compression, le décodage et l'affichage de l'écran.

Faut-il désactiver UDP quand RDP semble lent ?

Pas en recommandation générale. Vérifiez d'abord le transport réellement utilisé, le chemin et les stratégies appliquées. UDP peut être indisponible et la connexion être retombée sur TCP : passer en TCP seul n'accélère donc pas toujours les choses. Comparez dans des conditions équivalentes avec l'autorisation de votre administrateur, et annulez les modifications qui s'avèrent inutiles.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.