Pourquoi RDP est-il lent alors que la connexion est rapide ? — Examiner séparément la saisie, le rendu et le réseau

Le test de débit affiche plusieurs centaines de Mbit/s, et pourtant, dans le Bureau à distance, les caractères apparaissent avec un léger retard. Faire défiler une page riche en photos fait accrocher l’écran. Seul le bouton de recherche d’une application métier fige tout pendant quelques secondes. Face à ce genre de situation, où « la connexion est rapide, mais RDP est lent », par où commencer l’enquête ?

La réactivité de RDP aux actions ne dépend pas uniquement du débit de la connexion. Même avec un test de débit rapide, l’attente peut se situer dans l’aller-retour réseau, dans l’attente d’entrée de l’application sur l’hôte distant, dans l’encodage de l’écran ou dans le décodage et l’affichage sur votre poste. Commencez par distinguer « quelle opération est lente », puis comparez la même opération en ne changeant qu’une condition à la fois. Les comparaisons et les mesures permettent de restreindre les pistes, et les réglages UDP ou GPU se choisissent en fonction de leurs résultats. Voir : Segments mesurés de la qualité de connexion, Facteurs de performances de l’hôte de session.

Toutefois, avoir restreint les pistes ne signifie pas que la cause racine est établie. Même si baisser la résolution améliore la situation, ce changement modifie non seulement la communication, mais aussi le traitement de l’écran aux deux extrémités : on ne conclut donc pas que « la connexion était en cause ». Consignez les résultats en séparant les segments mesurés de ceux qui ne l’ont pas été.

Cet article isole les causes de lenteur de la saisie, du défilement et de la réponse des applications une fois la connexion établie. Des symptômes semblables n’ont pas forcément une seule et même cause. Si « l’écran de connexion met longtemps à apparaître » ou si « tout s’arrête à l’authentification », il s’agit d’un autre problème, à examiner à partir des journaux d’établissement de la connexion et d’authentification.

Il s’adresse principalement aux utilisateurs et aux administrateurs qui se connectent à Windows 11 ou à Windows Server depuis l’application Windows « Connexion Bureau à distance » (mstsc). Les exemples de commandes visent Windows PowerShell 5.1. On suppose que la même opération peut être reproduite dans une session déjà connectée.

Connexion directe, VPN, RD Gateway et Azure Virtual Desktop diffèrent par le chemin réseau, par les informations de diagnostic disponibles et par la cible à laquelle s’appliquent les réglages. L’exemple de vérification de TCP 3389 se limite aux connexions directes autorisées vers un hôte RDP qui utilise le port standard. On ne transpose pas tels quels aux PC ordinaires de l’entreprise les fonctions de diagnostic et les réglages GPU décrits dans la documentation consacrée à Azure Virtual Desktop.

Sur les postes de l’entreprise, l’enquête reste dans les limites autorisées par l’administrateur. Sur un hôte partagé, identifiez votre propre session et le processus concerné, et si vous avez besoin des données d’autres utilisateurs, demandez-les à l’administrateur. La disponibilité des compteurs de performances, leurs noms affichés et les droits nécessaires se vérifient dans chaque environnement.

Les méthodes de vérification présentées ici s’appuient sur la documentation officielle. Il ne s’agit pas d’un compte rendu de mesures dans lequel une panne aurait été reproduite puis résolue sur un poste précis. Les exemples chiffrés sont signalés comme des hypothèses d’illustration.

Pour comprendre le mécanisme, lisez dans l’ordre à partir de la section suivante, « Débit et temps d’aller-retour ». Si vous préférez partir du symptôme, passez à « Choisir la première comparaison selon le symptôme ». Les procédures se trouvent dans « Comparer une condition à la fois » et « Mesurer où se situe l’attente ».

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

Débit et temps d’aller-retour

RDP (Remote Desktop Protocol) est le protocole qui échange notamment les saisies et les informations d’écran entre votre poste et l’hôte distant. Il ne transporte pas seulement l’écran et les saisies : il gère aussi les informations de redirection de périphériques, d’impression, etc. Voir : Informations transférées par RDP.

Le débit d’une connexion indique la quantité de données qu’elle peut transporter en une seconde. Les « 500 Mbit/s » d’un test de débit sont un chiffre relatif à cette quantité. Ce n’est pas un chiffre qui indique le temps écoulé entre une action et l’arrivée de la réponse. Voir : Besoins en bande passante de RDP.

flowchart TB
    accTitle: Ce que représente le chiffre du test de débit
    accDescr: Montre que les 500 Mbit/s du test de débit représentent la quantité de données transportable en une seconde, un chiffre distinct du temps entre une action et l'arrivée de la réponse.
    A["Test de débit : 500 Mbit/s"] --> B["Données transportables en 1 seconde"]
    B -.->|"Un autre chiffre"| C["Temps d'arrivée de la réponse"]

Figure 1 : Le chiffre du test de débit représente la quantité transportable, pas le temps que met la réponse à arriver.

Le temps d’aller-retour (RTT) est le temps que met une communication pour atteindre son destinataire et revenir. Augmenter le débit et raccourcir le temps d’aller-retour, c’est un peu la différence entre ajouter des voies à une route et rapprocher la destination. Même si la capacité à transporter de gros volumes de fichiers augmente, l’attente de la réponse à une action demeure tant que le temps d’aller-retour ne change pas. Voir : RTT et latence d’affichage de l’écran.

flowchart TB
    accTitle: Débit et temps d'aller-retour comparés à une route
    accDescr: Compare l'augmentation du débit à l'ajout de voies sur une route, et la réduction du temps d'aller-retour au raccourcissement de la distance jusqu'à la destination.
    A["Augmenter le débit"] -->|"Pour une route"| B["Ajouter des voies"]
    B ~~~ C["Réduire le temps d'aller-retour"]
    C -->|"Pour une route"| D["Raccourcir la distance"]

Figure 2 : Ajouter des voies ne raccourcit pas la distance jusqu’à la destination.

Le retour d’un caractère tapé

Prenons le cas où l’on tape un caractère dans le Bloc-notes distant. Le Bloc-notes s’exécute sur l’hôte distant. Si l’on suppose, pour l’illustration, 50 millisecondes pour que l’action arrive et 50 millisecondes pour que les informations d’écran résultantes reviennent, le temps passé en communication est de 100 millisecondes au total, soit 0,1 seconde. Le temps de traitement aux deux extrémités est exclu de cet exemple.

flowchart TB
    accTitle: Exemple de temps de communication pour le retour d'un caractère
    accDescr: Exemple qui suppose, pour l'illustration, 50 millisecondes à l'aller et 50 millisecondes au retour. Il n'inclut pas le traitement aux deux extrémités et ne représente pas non plus le 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 mis à jour"]
    C -->|"Retour : 50 ms"| D["Le résultat arrive en local"]

Figure 3 : Avec, par hypothèse, 50 millisecondes à l’aller et 50 au retour, la communication seule prend 0,1 seconde. Ce ne sont pas des valeurs mesurées.

Même si la quantité que la connexion peut transporter augmente, ces 0,1 seconde demeurent tant que le temps d’aller-retour ne change pas. La figure 3 est un schéma conceptuel destiné à comprendre le traitement. Elle ne signifie pas qu’un aller-retour de paquets indépendant est envoyé pour chaque touche. Le serveur du test de débit et l’hôte RDP sont en outre atteints par des chemins différents : il faut tenir compte du VPN, de la passerelle, du débit montant côté hôte et de la congestion en chemin. Voir : Comment interpréter le RTT, Performances du réseau et de l’hôte.

Produire l’écran et l’acheminer

Le retard de réponse aux actions dont il est question ici est l’attente entre une action sur votre poste et le moment où son résultat devient visible. Il ne dépend pas seulement du RTT, mais aussi du traitement de l’application et du travail qui produit l’écran et l’achemine. On le distingue également de la seule latence du segment de transfert de l’écran. Voir : Segment mesuré, de la capture de l’écran à son affichage.

Lorsque la saisie arrive de votre poste à l’hôte distant, l’application de l’hôte la traite et met l’écran à jour, les informations d’écran encodées traversent la connexion, puis votre poste les décode et les affiche. Avant et après la communication, il y a aussi du travail, pris en charge par des PC différents. Voir : Traitements de la capture de l’écran à l’affichage.

flowchart TB
    accTitle: Le traitement de l'écran avant et après la connexion
    accDescr: Flux dans lequel la saisie locale arrive sur l'hôte, où l'application la traite, produit l'écran et le compresse, puis les informations d'écran transportées par la connexion sont remises sous une forme affichable sur le poste local et affichées.
    I["Local : saisir une action"] --> J["Connexion : transporter la saisie"]
    J --> K["Hôte : l'application traite"]
    K --> A["Hôte : produire et compresser l'écran"]
    A --> B["Connexion : transporter l'écran"]
    B --> C["Local : remettre en forme affichable"]
    C --> D["Afficher sur l'écran local"]

Figure 4 : Traitement et compression sur l’hôte, transport par la connexion, retour à une forme affichable sur le poste local : chacune de ces tâches s’effectue à un endroit différent.

Dans cet article, l’encodage désigne le traitement qui, sur l’hôte distant, convertit et compresse l’écran sous une forme facile à envoyer. Indépendamment du transfert sur la connexion, il prend du temps de traitement sur l’hôte. Voir : Temps d’encodage sur l’hôte.

Le décodage désigne ici le traitement qui remet les informations d’écran reçues sous une forme affichable sur votre poste. On le distingue du déchiffrement, au sens de la levée d’un chiffrement. Voir : Temps de décodage et d’affichage sur le poste local.

Si la compression prend du temps sur l’hôte, l’envoi attend d’être prêt même si la connexion est libre. Même lorsque les informations sont arrivées, la mise à jour prend du retard si le décodage ou l’affichage ne suit pas sur votre poste. Il n’est pas forcément vrai que « le PC de l’entreprise est puissant, donc n’importe quel poste local fera l’affaire ». La marge de la connexion et la marge de traitement à ses deux extrémités sont deux choses distinctes. Voir : Compteurs de performances du traitement de l’écran.

flowchart TB
    accTitle: Retards quand les deux extrémités ne suivent pas
    accDescr: Montre que si la compression sur l'hôte prend du temps, l'envoi attend même si la connexion est libre, et que si le décodage ou l'affichage local ne suit pas, la mise à jour prend du retard même si les informations sont arrivées.
    A["Compression lente sur l'hôte"] --> B["Envoi en attente malgré une connexion libre"]
    B ~~~ C["Le décodage local ne suit pas"]
    C --> D["Arrivé, mais mis à jour en retard"]

Figure 5 : Même si la connexion a de la marge, la mise à jour de l’écran prend du retard si les deux extrémités ne suivent pas.

Saisie de texte et défilement

Ajouter un caractère dans le Bloc-notes ne modifie qu’une petite partie de l’écran. Faire défiler une page riche en photos change l’affichage sur une large zone, en continu. RDP limite le volume de données en transférant les parties modifiées et en recourant à une compression et à une mise en cache adaptées au contenu. Il n’envoie pas tout l’écran sans compression à chaque fois. La quantité de travail dépend du contenu de l’écran et de la fréquence des mises à jour. Voir : Relation entre contenu de l’écran et bande passante.

flowchart TB
    accTitle: Travail de l'écran selon la saisie ou le défilement
    accDescr: Un petit changement de texte et la mise à jour continue d'une large zone n'imposent pas le même type de travail pour produire et envoyer l'écran.
    A{"Changement à l'écran"} -->|"Ajout d'un caractère"| B["Petite zone"]
    A -->|"Défilement"| D["Large zone en continu"]
    B --> E["Compression et transfert selon le changement"]
    D --> E

Figure 6 : Sur une même connexion, la quantité de travail diffère entre l’ajout d’un caractère et une large zone qui ne cesse de bouger.

Un document immobile a beau être léger, le transfert de l’écran peut manquer de marge pendant le défilement. Augmenter la résolution ou le nombre d’écrans côté distant agrandit aussi l’écran à traiter. La comparaison qui consiste à baisser la résolution est une expérience : elle vérifie si la fluidité revient quand on réduit le travail de production et d’envoi de l’écran. Ce n’est pas un calcul qui déduit le volume de données du seul nombre de pixels. Voir : Effets de la résolution, des mises à jour d’écran et de la compression.

Les attentes de l’application

Si seule la recherche d’une application métier se fige pendant quelques secondes alors que le Bloc-notes de la même session accepte la saisie normalement, vérifiez ce que cette application attend. L’application de l’hôte peut à son tour adresser une requête à une autre base de données ou lire un fichier dans un dossier partagé, et attendre la réponse. Il s’agit d’un chemin distinct de la communication RDP qui relie votre poste à l’hôte. Voir : Communication de l’hôte vers le back-end.

flowchart TB
    accTitle: D'autres interlocuteurs au-delà de RDP
    accDescr: Montre le cas où, indépendamment de la communication entre le poste local et l'hôte, l'application de l'hôte attend la réponse d'un serveur métier.
    A["Poste local"] -->|"RDP"| B["Application métier sur l'hôte"]
    B -->|"Recherche, demande de fichier"| C["Base de données, dossier partagé"]
    C -->|"Réponse attendue"| B

Figure 7 : L’application métier située au-delà de RDP peut elle-même attendre la réponse d’un autre serveur.

Lorsque le traitement chargé de l’écran et des saisies est occupé par une tâche longue, la saisie suivante et la mise à jour de l’écran prennent du retard. En WPF, par exemple, la réactivité se dégrade quand le thread d’interface est monopolisé longtemps. Une faible utilisation globale du processeur ne suffit pas à exclure une attente sur un thread d’interface particulier. Voir : Dispatcher et thread d’interface.

flowchart TB
    accTitle: Le traitement de l'écran et des saisies se bloque
    accDescr: Montre que si le traitement chargé de l'écran et des saisies est occupé par une tâche longue, la saisie suivante et la mise à jour de l'écran prennent du retard, et qu'une faible utilisation globale du processeur ne suffit pas à exclure cette attente.
    A["Traitement de l'écran et des saisies"] --> B["Occupé par une tâche longue"]
    B --> C["Saisie et mise à jour suivantes en retard"]
    C -.- D["Non exclu par un CPU global faible"]

Figure 8 : Une faible utilisation globale du processeur ne suffit pas à exclure une attente sur le thread d’interface.

Choisir la première comparaison selon le symptôme

La quantité transportable, le temps d’attente de la réponse et le temps nécessaire pour produire et afficher l’écran sont trois choses distinctes. En gardant cette distinction, on ne réduit pas « RDP est lent » à une cause unique, et l’on peut partir de l’opération qui est lente maintenant.

flowchart TB
    accTitle: Séparer les trois avant d'enquêter
    accDescr: Montre qu'au lieu de réduire « RDP est lent » à une cause unique, on sépare la quantité transportable, le temps d'attente de la réponse et le temps de production et d'affichage de l'écran, pour partir de l'opération lente du moment.
    A["« RDP est lent »"] --> S
    subgraph S["Examiner séparément"]
    direction TB
    B["Quantité transportable"] ~~~ C["Temps d'attente de la réponse"]
    C ~~~ D["Temps pour produire et afficher l'écran"]
    end
    S --> E["Partir de l'opération lente"]

Figure 9 : En séparant quantité transportable, temps d’attente de la réponse et temps de production et d’affichage de l’écran, on peut partir de l’opération lente du moment.

Le but de l’isolement est de circonscrire l’endroit où chercher la lenteur. Il ne s’agit pas de modifier tous les réglages d’un coup pour obtenir par hasard un gain de vitesse. En exploitant des différences comme « le Bloc-notes répond, mais la recherche se fige » ou « la saisie est normale, mais seul le défilement est lourd », on peut choisir un point d’entrée de l’enquête avant même de toucher aux réglages réseau.

Le tableau suivant est un point de départ pour l’enquête. Ce n’est pas un tableau qui permet de déterminer la cause. Comparez d’abord les opérations dans la même session, puis changez le poste, le chemin ou les conditions d’affichage selon les besoins.

Caractères en retard dans plusieurs applications

Si, dans plusieurs applications de la même session, chaque caractère apparaît avec retard, comparez la même opération depuis un autre poste ou par un autre chemin autorisé. Rapprochez le temps d’aller-retour, l’attente d’entrée sur l’hôte et la charge globale de l’hôte, sans décider de la cause sur la foi d’un seul chiffre.

Seul le défilement saccade

Même si la saisie de texte est normale, faire défiler une page riche en photos entraîne des mises à jour continues sur une large zone de l’écran. Changez la résolution ou le nombre d’écrans côté distant, un seul à la fois, et comparez sur la même page. En cas d’amélioration, la compression sur l’hôte, le transfert de l’écran et le décodage local deviennent les prochaines pistes. La résolution seule ne permet pas de savoir lequel des trois est en cause. Voir : Charge selon le contenu de l’écran et la résolution.

Une seule application se fige

Si seule l’application métier sur laquelle vous avez lancé une recherche se fige, vérifiez par comparaison si le Bloc-notes ou une autre application de la même session répond. Si les autres applications fonctionnent, examinez d’abord le traitement de l’application concernée, le disque et les requêtes vers la base de données ou le dossier partagé. Travailler via RDP et avoir la communication RDP pour cause de l’attente sont deux choses différentes. Voir : Facteurs de performances de l’application et du back-end.

Tout le monde ralentit aux heures d’affluence

Si plusieurs utilisateurs ralentissent pendant la même plage horaire, demandez à l’administrateur l’état des autres sessions. Rapprochez de l’heure des symptômes la charge du processeur, de la mémoire et du stockage de l’hôte partagé ainsi que celle de la connexion partagée. On n’accède pas sans autorisation aux données ou aux traitements des autres utilisateurs, et l’on n’arrête pas leurs tâches. Voir : Ressources de l’hôte partagé et nombre d’utilisateurs.

Ralentissement pendant une copie ou une impression

Si le moment où vous avez lancé une copie ou une impression coïncide avec le dysfonctionnement, suspendez uniquement les transferts que vous êtes autorisé à arrêter, puis comparez. Notez si la situation revient après la suspension et si elle se dégrade à la reprise, puis examinez la concurrence avec les transferts autres que l’écran et avec la redirection de périphériques. On ne fait pas de comparaison qui désactive d’un coup les périphériques nécessaires au travail. Voir : Effets de la redirection de périphériques.

Comparer une condition à la fois

Il n’est pas nécessaire de modifier tous les réglages les uns après les autres. On commence par établir une base de comparaison, puis on ne retient que les vérifications adaptées au symptôme. Avant de modifier un réglage ou de vous reconnecter, enregistrez votre travail et notez la valeur d’origine ainsi que la manière de la rétablir. Si les droits ou les fonctions nécessaires manquent, on ne force pas leur activation et l’on passe le relais à l’administrateur.

Une opération locale et une opération via RDP ne se déroulent pas forcément dans les mêmes conditions. Qu’elle soit rapide sur l’écran physique de l’hôte est une indication utile, mais la session et les conditions de rendu peuvent différer. Alignez l’utilisateur, les données et l’état de l’application, et ne limitez pas la cause à la connexion sur le seul constat que « c’est rapide sur l’écran physique ».

Comparer la même opération

On prépare le même utilisateur, les mêmes données et la même opération. Sur un hôte partagé, on vérifie sa propre session et l’on n’arrête pas les applications ni les traitements des autres utilisateurs. L’utilisation d’un autre poste ou d’un autre chemin se limite elle aussi à ce que l’administrateur autorise.

1. Reproduisez l’opération lente avec les réglages d’origine, puis notez l’heure et le symptôme.

   Dans le Bloc-notes de la même session distante que l’application en cause, tapez à peu près autant de caractères. Distinguez ainsi si une seule application est touchée ou toute la session.

2. Vérifiez la charge de l’hôte et celle du poste local sur la même plage horaire.

   Dans le Gestionnaire des tâches, regardez sur l’hôte le processeur, la mémoire et le disque de l’application concernée, et sur le poste local la charge du client RDP. Examinez le processus concerné, et pas seulement la valeur globale du processeur. Voir : Éléments à examiner pour la charge.

3. Changez une seule condition parmi un autre poste, un autre chemin autorisé et les conditions d’affichage, puis répétez la même opération.

   Si la comparaison modifie en même temps l’état de l’hôte ou de l’application, notez aussi cette différence. On ne considère pas le résultat d’un changement de plusieurs conditions comme l’effet d’une seule.

4. Revenez aux conditions d’origine et vérifiez de nouveau la même opération.

   Si tout reste rapide après le retour à l’état initial, une variation passagère de la charge, entre autres, est envisageable. Ne concluez pas d’emblée que le changement a fait effet : notez les conditions dans lesquelles le symptôme se reproduit.

Vous disposez alors des résultats de l’état d’origine, de l’état modifié et de l’état rétabli, et pouvez comparer quelles conditions correspondent au symptôme. Une condition qui a amélioré la situation est un indice pour l’enquête ; à elle seule, elle ne prouve pas la cause racine.

flowchart TB
    accTitle: Limiter les conditions changées à la fois
    accDescr: Flux qui fixe l'opération qui reproduit le problème dans l'état d'origine, ne change qu'une condition pour comparer, puis vérifie aussi le résultat après le retour à l'état initial.
    A["Même opération, réglages d'origine"] --> B["Changer une seule condition"]
    B --> C["Répéter la même opération"]
    C --> D["Revenir à l'origine et revérifier"]
    D --> E["Noter la condition qui améliore"]

Figure 10 : On répète la même opération dans l’état d’origine, après le changement et après le retour à l’état initial, et l’on note la condition qui a changé le résultat.

Comparer la résolution côté distant

Cette comparaison s’applique lorsque les mises à jour d’écran sont lourdes, par exemple pendant le défilement. Notez la résolution et le nombre d’écrans avant le changement, enregistrez votre travail, puis reconnectez-vous. On ne conserve pas au quotidien un réglage qui nuit à l’écran dont le travail a besoin ou à la lisibilité du texte.

1. Ne changez que l’un des deux : le nombre d’écrans ou la résolution.

   Avec mstsc, vous pouvez comparer à l’aide des réglages de l’onglet « Affichage » avant la connexion ou en indiquant la largeur et la hauteur. Voir : Options d’affichage de mstsc.

2. Vérifiez que la taille réelle du bureau de l’hôte a changé, puis faites défiler la même page.

   Si vous vous contentez de réduire la fenêtre locale, il se peut qu’un grand bureau soit simplement affiché en réduction. Distinguez la résolution dynamique du smart sizing et vérifiez les conditions de prise en charge du client utilisé. Voir : Résolution du bureau et mise à l’échelle de l’affichage.

3. Revenez au réglage d’origine, répétez la même opération, et comparez la charge aux deux extrémités ainsi que le mouvement de l’écran.

   Si vous êtes passé d’un coup à une basse résolution et à un seul écran, la comparaison reste approximative. En cas d’amélioration, rétablissez les réglages un par un pour séparer leurs effets.

En cas d’amélioration, les indices se situent du côté du traitement et du transfert de l’écran. Une résolution de 3840×2160 compte quatre fois plus de pixels que 1920×1080, mais le volume de données n’est pas toujours multiplié par quatre. Il varie selon les parties modifiées et la compression, et un changement de résolution affecte aussi le traitement aux deux extrémités. Voir : Relation entre nombre de pixels et volume de données, Vérification du traitement de l’écran.

flowchart TB
    accTitle: Ce que révèle une comparaison à résolution réduite
    accDescr: Baisser la résolution distante peut modifier à la fois la charge du traitement de l'écran et celle du transfert, si bien qu'une amélioration seule ne permet pas de limiter la cause à la connexion.
    A["Baisser la résolution distante"] --> S
    subgraph S["Traitements modifiés"]
    direction TB
    B["Traitement de l'écran sur l'hôte"] ~~~ C["Quantité d'informations envoyée"]
    C ~~~ D["Affichage sur le poste local"]
    end

Figure 11 : Changer la résolution est une comparaison qui affecte non seulement la connexion, mais aussi le traitement de l’écran sur l’hôte et sur le poste local.

Rapprocher copie, impression et symptômes

On ne suspend que les traitements dont l’arrêt est autorisé, comme les transferts que l’on a soi-même lancés. On n’arrête ni les sauvegardes ni les traitements de sécurité de l’entreprise, ni les tâches des autres utilisateurs. On ne désactive pas d’un coup la redirection des périphériques audio et d’entrée nécessaires au travail.

1. Avant et pendant une copie, une synchronisation cloud ou une impression, notez le comportement d’une même opération et la charge.

   Outre l’écran, RDP fait aussi circuler des informations sur les lecteurs, les imprimantes, etc. La redirection, qui permet d’utiliser sur l’hôte les périphériques de votre poste, peut accroître la charge réseau et de traitement pendant son utilisation. Voir : Effets de la redirection de périphériques.

2. Suspendez le transfert concerné dans les limites autorisées, puis vérifiez de nouveau la même opération.

   Si vous pouvez reprendre le transfert pour comparer, notez aussi le symptôme après la reprise. Si vous faites des essais sur des redirections de périphériques inutiles, modifiez-les là aussi une par une, de façon à pouvoir revenir aux réglages d’origine.

Vous pouvez juger si le début du transfert correspond au dysfonctionnement, et la suspension au rétablissement. Si une correspondance apparaît, rapprochez les transferts autres que l’écran et la charge des ressources partagées des journaux de l’administrateur.

flowchart TB
    accTitle: Situer le dysfonctionnement sur un même axe temporel
    accDescr: On note la même opération et la charge avant, pendant et après le transfert, puis on compare la relation entre le dysfonctionnement et le travail en cours.
    A["Opération et charge avant le transfert"] --> B["Opération et charge pendant le transfert"]
    B --> C["Opération et charge après l'arrêt"]
    C --> D["Dysfonctionnement et rétablissement concordent ?"]

Figure 12 : On observe comment la lenteur de la même opération et la charge évoluent avant, pendant et après le transfert.

Mesurer où se situe l’attente

Depuis votre poste, on examine l’aller-retour réseau et la connexion TCP ; sur l’hôte, l’attente dans la file d’entrée et les mises à jour de l’écran. Chaque valeur ne mesure qu’un segment limité : lisez donc les résultats à la lumière du tableau de la section « Portée des résultats de mesure ».

Vérifier ICMP et la connexion TCP

Ces commandes s’exécutent sur votre poste Windows local. Elles ne visent que les configurations où l’on se connecte directement, via le réseau local de l’entreprise ou un VPN autorisé, à un hôte RDP qui utilise le port standard TCP 3389. Pour les configurations passant par RD Gateway ou Azure Virtual Desktop, ou utilisant un port personnalisé, définissez avec l’administrateur la cible à vérifier. On n’ouvre aucun port et l’on ne modifie pas le pare-feu.

1. Saisissez l’hôte autorisé, puis notez les résultats de la réponse ICMP et de la connexion TCP.

   $target = Read-Host 'Nom ou adresse IP de la machine RDP autorisée pour cette analyse'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Indiquez la machine à laquelle se connecter.'
   }
       
   # Observer le temps de réponse ICMP sur plusieurs essais. Un échec seul ne prouve pas que RDP est injoignable.
   ping.exe -n 20 $target
       
   # Vérification limitée aux configurations à connexion directe sur le port TCP 3389 standard.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Rapprochez les résultats obtenus aux heures lentes et en temps normal de l’heure des symptômes et du chemin de connexion réel.

   Une série de 20 ping n’est qu’une courte observation. Notez les fluctuations et les absences de réponse, en sachant que l’ICMP peut être bloqué. Ne niez pas des interruptions intermittentes sur la seule base d’une moyenne : utilisez les informations de connexion et les journaux réseau de l’administrateur. Voir : Ce que mesure ping.

TcpTestSucceeded: True signifie que la connexion TCP au port indiqué a réussi. La bande passante, UDP, les opérations après authentification et la fluidité de l’écran ne sont pas mesurées. Test-NetConnection ne dispose pas d’un commutateur -UDP permettant d’examiner UDP. Voir : Syntaxe et résultats de Test-NetConnection.

On juge en gardant à l’esprit les différences de chemin et de service. Avec RD Gateway, entre autres, le chemin de l’ICMP ou de la connexion TCP directe vers l’hôte peut ne pas coïncider avec le chemin RDP réel. Azure Virtual Desktop fournit le RTT et une estimation de la bande passante pour chaque connexion, mais ces fonctions de diagnostic sont propres à ce service. On ne nie pas de courtes interruptions sur la seule base d’une moyenne. Voir : Journaux de qualité de connexion d’Azure Virtual Desktop.

flowchart TB
    accTitle: Chemin vérifié et chemin RDP réel
    accDescr: Dans les configurations qui utilisent RD Gateway ou un service similaire, le chemin de l'ICMP ou de la connexion TCP directe du poste local vers l'hôte peut ne pas coïncider avec le chemin RDP réel.
    A["Poste local"] -->|"ICMP, TCP direct"| C["Hôte RDP"]
    A -->|"RDP réel"| B["RD Gateway, etc."]
    B --> C

Figure 13 : L’ICMP ou la connexion TCP directe vers l’hôte et le RDP réel n’empruntent pas toujours le même chemin.

Mesurer l’attente dans la file d’entrée

User Input Delay mesure l’attente entre le moment où une saisie entre dans la file d’attente sur l’hôte et celui où le processus la récupère. Ce n’est pas le temps total entre l’appui sur une touche et l’apparition du caractère. Voir : Définition de User Input Delay.

La mesure se fait dans la session distante sur l’hôte. Selon Microsoft, elle est prise en charge à partir de Windows 10 version 1809 et de Windows Server 2019. Sur ces systèmes, aucun ajout au Registre n’est nécessaire pour l’activer. Vérifiez le nom affiché, les droits et la présence du compteur ; s’il n’est pas disponible, notez ce fait et consultez l’administrateur. Voir : Conditions de prise en charge et configuration.

1. Dans PowerShell, au sein de 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
       
   

   L’interrogation des sessions d’autres utilisateurs peut exiger des droits supplémentaires. Le nom d’instance standard du processus ciblé est SessionID:ProcessID <Process Image>. Veillez à ne pas mélanger, en vous fiant au seul identifiant de session, les valeurs d’autres utilisateurs ou de processus portant le même nom. Voir : Droits requis par query session, Identification des instances.

2. Dans perfmon.exe, ajoutez User Input Delay per Process ou User Input Delay per Session, selon ce qui est disponible.

   Choisissez le processus ou la session ciblés et observez d’abord avec l’intervalle par défaut de 1 seconde. Distinguez l’instance agrégée, qui regroupe plusieurs sessions, des valeurs d’une session individuelle.

3. Reproduisez l’opération dont la saisie est lente et comparez l’attente dans la file avec l’heure du symptôme.

   Pour une cible individuelle, la valeur observée est le temps d’attente maximal au cours de l’intervalle de mesure. Même si elle est faible, le traitement après la récupération de la saisie par l’application et le délai de retour du résultat vers votre poste demeurent.

Vous pouvez ainsi déterminer si l’attente se situe dans la file d’entrée de l’hôte. Il s’agit d’un indicateur distinct du temps perçu, qui inclut l’aller-retour réseau et l’affichage sur votre poste. Voir : Signification du maximum et de l’intervalle de mesure.

flowchart TB
    accTitle: Le segment mesuré par User Input Delay
    accDescr: Le segment mesuré va de la file d'entrée de l'hôte jusqu'à la récupération par l'application ; la communication et l'affichage de l'écran avant et après n'y sont pas inclus.
    A["La saisie arrive du poste local"] --> B["Elle entre dans la file de l'hôte"]
    B -->|"Mesuré ici"| C["L'application récupère la saisie"]
    C --> D["Traitement et transfert de l'écran"]
    D --> E["Affichage sur le poste local"]

Figure 14 : Ce qui est mesuré, c’est l’attente dans la file d’entrée de l’hôte. Ce n’est pas le temps total jusqu’à ce que le résultat soit visible sur votre poste.

Examiner les mises à jour de l’écran et les raisons des images sautées

Préparez une opération qui entraîne des mises à jour d’écran continues, comme un défilement. La disponibilité des compteurs RemoteFX Graphics et l’endroit où ils mesurent sont à vérifier selon l’OS, la configuration de l’hôte et les droits. On se contente ici de lire les compteurs disponibles. Ce n’est pas une procédure pour installer ou activer l’ancienne fonctionnalité RemoteFX. Voir : Conditions d’application des compteurs Graphics.

1. Vérifiez le nom de la session ciblée avec query session ou qwinsta, puis sélectionnez l’instance de compteur correspondante.

2. Pendant une opération qui met à jour l’écran, comparez Input Frames/Second et Output Frames/Second.

   Si la sortie est inférieure à l’entrée, des images de l’écran sont sautées en cours de route. Examinez les valeurs de Frames Skipped/Second ventilées par manque de ressources : hôte, réseau ou client.

3. Rapprochez les raisons des images sautées de la charge aux deux extrémités et sur le réseau, et vérifiez aussi Average Encoding Time.

   Si le temps d’encodage est long, examinez la compression sur l’hôte. Si le nombre d’images est déjà faible côté entrée, il se peut aussi que l’application ne mette pas souvent l’écran à jour. Un nombre d’images faible sur un écran immobile n’a rien d’anormal en soi.

Les entrées et sorties pendant les mises à jour d’écran, les raisons des images sautées et le temps d’encodage permettent de restreindre les pistes. La classification des compteurs est un indice : on juge en la combinant avec la charge réelle et la configuration de connexion. Voir : Lire le nombre d’images et le temps d’encodage.

flowchart TB
    accTitle: Restreindre les pistes à partir des images sautées
    accDescr: Pendant une opération qui met à jour l'écran, on compare le nombre d'images en entrée et en sortie, puis, en s'appuyant sur les compteurs de raisons des images sautées, on rapproche les résultats de la charge du traitement, du réseau et de l'affichage.
    A["Comparer entrée et sortie au défilement"] --> B["Sortie faible : vérifier les images sautées"]
    B --> C["Voir les compteurs par raison"]
    C --> D["Rapprocher charge hôte, réseau, local"]

Figure 15 : On compare entrée et sortie pendant le défilement, puis on rapproche les raisons des images sautées de la charge de l’hôte, de la connexion et du poste local.

On ne généralise pas à toutes les configurations le schéma conceptuel du transfert de l’écran ni les documents anciens. Certaines configurations transfèrent la vidéo et l’audio par un autre mécanisme. La documentation des compteurs Graphics décrit aussi d’anciennes configurations : on ne transforme donc pas les valeurs qu’elle indique en une spécification commune du type « tout RDP plafonne à 30 images par seconde ». Vérifiez à quoi s’appliquent les fonctionnalités et les valeurs avant de les utiliser. Voir : Transfert de l’écran et charges de travail, Documentation des compteurs Graphics.

Portée des résultats de mesure

On n’assimile pas une valeur faible à une utilisation confortable. La portée de chaque indicateur peut être vérifiée dans la documentation Microsoft indiquée au fil des procédures.

Paramètres réseau et GPU

Les réglages UDP et GPU se choisissent en fonction de ce que les comparaisons et les mesures ont révélé. Si le réseau est suspect, vérifiez d’abord le mode de connexion et le chemin ; si c’est le traitement de l’écran, vérifiez d’abord à quelles étapes le GPU est utilisé.

Vérifier TCP/UDP et le chemin de connexion

Lorsque les comparaisons et les mesures font soupçonner le réseau, on vérifie avec l’administrateur le client utilisé, le chemin et les stratégies appliquées. Même si un changement de réglage s’impose, il reste limité au périmètre approuvé, et l’on note la valeur d’origine ainsi que la méthode de restauration. On ne désactive ni le pare-feu ni l’authentification, et l’on n’expose pas directement le port RDP sur Internet.

1. À l’aide des informations de connexion, des journaux de diagnostic du produit et des journaux réseau de l’administrateur, vérifiez le transport TCP ou UDP réellement utilisé et le chemin.

   RDP utilise TCP ou UDP selon la configuration et les conditions réseau. La stratégie « Select RDP transport protocols » permet de choisir entre un réglage qui utilise UDP ou TCP et un réglage TCP seul. Comme RDP peut aussi se rabattre sur TCP lorsque la connexion UDP ne s’établit pas, une connexion réussie ne suffit pas à connaître le transport. Voir : Choix du transport RDP et repli.

2. Rapprochez l’heure des symptômes du chemin et du transport, puis comparez uniquement les réglages nécessaires, un par un.

   On ne modifie pas systématiquement les réglages en se disant que « couper UDP accélérera les choses ». Comparez à conditions égales de VPN ou de passerelle, d’opération et d’affichage, et annulez les modifications inutiles.

En connaissant le transport et le chemin, vous pouvez consigner la relation entre les modifications et les symptômes. Passer en TCP seul n’accélère pas toujours les choses.

flowchart TB
    accTitle: Vérifier le mode de connexion avant de comparer les réglages réseau
    accDescr: On distingue la connexion directe ordinaire de la connexion via une passerelle ou un service, on vérifie le chemin et le transport réels, puis on effectue les comparaisons autorisées.
    A["Client utilisé et configuration"] --> B["Vérifier le chemin réel, TCP ou UDP"]
    B --> C["Rapprocher de l'heure du symptôme"]
    C --> D["Comparer un réglage utile à la fois"]

Figure 16 : On vérifie le mode de connexion et le chemin utilisés, on les rapproche du symptôme, puis on ne compare que les réglages nécessaires.

RDP Shortpath est un mécanisme d’Azure Virtual Desktop. Il établit un chemin UDP propre à ce service et, selon la configuration, utilise un chemin direct ou un relais. S’il ne peut pas l’établir, il revient à une connexion basée sur TCP. On ne peut pas le traiter dans le même tableau de réglages qu’une connexion directe à un PC de l’entreprise avec mstsc. Voir : Chemins et repli de RDP Shortpath.

flowchart TB
    accTitle: Chemins et repli de RDP Shortpath
    accDescr: RDP Shortpath d'Azure Virtual Desktop tente d'établir un chemin UDP ; s'il y parvient, il utilise un chemin direct ou un relais selon la configuration, sinon il revient à une connexion basée sur TCP.
    A["RDP Shortpath"] --> B{"Chemin UDP"}
    B -->|"Établi"| C["Direct ou relais"]
    B -->|"Échec"| D["Retour à une connexion TCP"]

Figure 17 : Si RDP Shortpath ne peut pas établir de chemin UDP, il revient à une connexion basée sur TCP.

Vérifier l’utilisation du GPU pour le traitement de l’écran

Cette vérification s’applique lorsque les comparaisons et les mesures font soupçonner le traitement de l’écran. Vérifiez les mesures du traitement de l’écran ainsi que l’OS, le pilote, les stratégies et le client pris en charge. On ne modifie pas les réglages au seul motif qu’un GPU est présent. On obtient d’abord l’approbation de l’administrateur et l’on prépare le retour à l’état d’origine.

1. Séparez le rendu de l’application sur l’hôte, l’encodage RDP et le décodage local, puis choisissez l’étape suspecte.

   Même avec un GPU, toutes les étapes ne l’utilisent pas forcément. Dans la documentation de configuration de Microsoft pour Azure Virtual Desktop aussi, le rendu de la session distante et l’encodage matériel des images se configurent et se vérifient séparément. Voir : Configuration et vérification du GPU pour le rendu et l’encodage.

2. Vérifiez l’utilisation réelle en suivant la procédure du produit concerné, et mesurez la même opération avant et après chaque changement nécessaire.

   Si le temps de compression est long, examinez l’utilisation du GPU pour l’encodage. Modifier les réglages d’encodage pour une application qui attend dans la file d’entrée, c’est viser le mauvais endroit. La lisibilité du texte et la fluidité vidéo n’appellent pas non plus les mêmes arbitrages entre qualité d’image, volume de données et charge de traitement. Voir : Différences selon la charge de travail.

Au-delà de la simple présence d’un GPU, vous pouvez consigner si le GPU est utilisé à l’étape en cause et comment la charge et la réponse de la même opération ont évolué. Une modification sans amélioration est annulée après vérification avec l’administrateur.

flowchart TB
    accTitle: Vérifier l'utilisation du GPU étape par étape
    accDescr: On sépare le rendu de l'application sur l'hôte, l'encodage RDP et le décodage local ; même avec un GPU, toutes les étapes ne l'utilisent pas forcément, on vérifie donc son utilisation à l'étape suspecte.
    A["Rendu de l'application sur l'hôte"] --> B["Encodage RDP"]
    B --> C["Décodage local"]
    C -.- D["Vérifier le GPU à chaque étape"]

Figure 18 : Même avec un GPU, le rendu, l’encodage et le décodage ne l’utilisent pas forcément tous.

Revérification et passation

Une amélioration se confirme lorsque, après le changement, la même opération se déroule sans difficulté et que la qualité d’image, les périphériques et les fonctions métier nécessaires sont préservés. Comparez aussi avec le résultat obtenu après le retour aux conditions d’origine. Si le rétablissement n’est que momentané, on ne tient pas la cause pour établie et l’on note aussi les heures d’affluence et les traitements simultanés.

flowchart TB
    accTitle: Ordre de vérification d'une amélioration
    accDescr: Après le changement, on vérifie que la même opération se déroule sans difficulté et que la qualité d'image, les périphériques et les fonctions métier nécessaires sont préservés, on compare avec le résultat après retour aux conditions d'origine, et un rétablissement momentané ne suffit pas à établir la cause.
    A["Tester la même opération après changement"] --> B["Vérifier image, périphériques, fonctions métier"]
    B --> C["Comparer au retour à l'origine"]
    C -.- D["Rétablissement momentané : rien d'établi"]

Figure 19 : Outre le résultat de la même opération, on vérifie les fonctions nécessaires et le résultat après le retour à l’état d’origine.

Passation en l’absence de solution

Une absence d’amélioration, un symptôme qui ne se reproduit pas ou des compteurs indisponibles constituent aussi des résultats utiles. Séparez les comparaisons que vous avez pu effectuer des vérifications impossibles, et transmettez le tout aux administrateurs et aux développeurs à l’aide de la note ci-dessous. Retirez des journaux partagés les informations métier inutiles à l’enquête, comme les noms d’utilisateur ou les hôtes.

Heure du symptôme et fuseau horaire :
OS de l'hôte, client utilisé et version :
Connexion directe / VPN / RD Gateway / Azure Virtual Desktop, etc. :
Opération et application lentes, réaction des autres applications de la session :
Résolution et nombre d'écrans côté distant :
Copies, impressions, etc. en cours au même moment :
Seule condition modifiée et résultat après retour à l'origine :
Charge et compteurs observés sur l'hôte et sur le poste local :

Précisez aussi si le transport TCP ou UDP réel a pu être vérifié, les éléments non vérifiés faute de droits ou pour d’autres raisons, et les réglages acceptables pour le travail. Dire « on tape normalement dans le Bloc-notes, mais tout se bloque quand on fait défiler des photos » plutôt que « la connexion est lente » permet à la personne suivante d’enquêter dans les mêmes conditions.

L’utilisateur consigne l’opération qui reproduit le problème et les résultats des comparaisons ; l’administrateur rapproche les journaux du chemin de connexion, de l’hôte partagé et des sessions. Le seul fait d’attendre dans RDP ne signifie pas que le traitement qui fait attendre relève lui aussi de RDP. Voir : Répartition des rôles entre l’hôte et le back-end.

Les développeurs de l’application journalisent séparément la réception des événements d’entrée, le début et la fin des traitements de base de données et de fichiers, et la répercussion dans l’interface. Ils envisagent aussi une conception qui ne laisse pas les tâches lourdes occuper durablement le thread d’interface. Toutefois, un journal de fin de traitement sur l’hôte n’enregistre pas la fin de l’affichage sur le poste local. Voir : Séparer les traitements pour préserver la réactivité de l’interface.

Articles connexes

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

Références

Il s’agit de sources primaires de Microsoft Learn. Leur contenu a été vérifié le 17 septembre 2026. Lisez-les en distinguant les conditions d’application propres à chaque produit et en gardant à l’esprit qu’il ne s’agit pas de mesures réalisées pour cet article.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Distinction entre le RTT et la latence qui va de la capture de l’écran sur l’hôte à son affichage sur le poste local. Les fonctions de diagnostic elles-mêmes sont destinées à Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Relation entre le contenu de l’écran, la résolution, la mise à jour des images, la compression, la mise en cache et le volume de données.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Méthode de vérification des entrées et sorties d’images, des raisons des images sautées et du temps d’encodage. Comme la page décrit aussi d’anciennes configurations, on ne généralise pas ses plafonds chiffrés à tout RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Charge de l’hôte partagé, communication de l’hôte vers le back-end et effets de la redirection de périphériques.
• Microsoft Learn, Threading model. Thread d’interface et Dispatcher de WPF, séparation des traitements pour préserver la réactivité.
• Microsoft Learn, mstsc. Indication de la largeur et de la hauteur du Bureau à distance, et de plusieurs écrans.
• Microsoft Learn, Supported RDP properties. Distinction entre résolution du bureau, résolution dynamique et smart sizing. Vérifiez les clients pris en charge et les conditions d’application propres à chaque produit.
• Microsoft Learn, ping. Vérification de la réponse par ICMP Echo, et options.
• Microsoft Learn, Test-NetConnection. Vérification de la connexion TCP et signification de la sortie.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Segment mesuré par User Input Delay, OS concernés, instances et signification de la valeur maximale.
• Microsoft Learn, query session. Informations de session et droits nécessaires pour interroger d’autres sessions.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Choix entre TCP et UDP utilisés par RDP, et repli.
• Microsoft Learn, RDP Shortpath. Chemin UDP destiné à Azure Virtual Desktop et comportement lorsqu’il ne peut pas être établi.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Configuration et vérification du GPU en distinguant le rendu et l’encodage des images.

Articles associés

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

Sujets associés

Ce sont des pages de sujets proches de ce thème. À partir de l’article, vous pouvez poursuivre vers les services associés et vers d’autres articles.

Services liés à ce sujet

Cet article est directement lié aux services suivants. Commencez par une entrée proche de votre situation.

Questions fréquentes

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

Le test de débit affiche plusieurs centaines de Mbit/s : pourquoi la saisie RDP est-elle lente ?

La vitesse à laquelle on transporte de gros volumes de données et le temps nécessaire pour qu'une action obtienne une réaction sont deux choses distinctes. L'envoi de la saisie, le traitement de l'application sur l'hôte distant, la compression de l'écran, le transfert et l'affichage sur votre poste entrent en jeu. En outre, le serveur du test de débit et l'hôte RDP ne sont pas atteints par le même chemin réseau.

La frappe est normale, seul le défilement saccade : est-ce un problème de connexion ?

On ne peut pas restreindre la cause à la seule connexion. Quand les mises à jour d'écran augmentent, le rendu ou la compression sur l'hôte, la communication, ou le décodage ou l'affichage sur votre poste peuvent ne pas suivre. Changez la résolution ou le nombre d'écrans côté distant un à la fois pour comparer et, si nécessaire, examinez les compteurs liés au rendu.

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

Cela ne suffit pas pour en juger. Le ping mesure la réponse à ICMP ; il ne mesure ni le transfert de l'écran par RDP ni le traitement des applications. Dans les configurations qui utilisent RD Gateway ou un service similaire, le chemin peut en outre ne pas coïncider. En l'absence de réponse aussi, distinguez un blocage de l'ICMP d'une coupure de RDP lui-même.

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

Non. C'est un compteur qui mesure le temps d'attente entre l'entrée d'une saisie dans la file d'attente de l'hôte et sa récupération par le processus. Ce n'est pas le délai perçu, qui inclut l'aller-retour réseau, le traitement applicatif après la récupération, ainsi que la compression, le décodage et l'affichage de l'écran.

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

Ce n'est pas une recommandation générale. Vérifiez d'abord le mode de connexion réel, le chemin et les stratégies appliquées. Il arrive qu'UDP soit inutilisable et que la connexion se soit rabattue sur TCP ; passer en TCP seul n'accélère donc pas toujours les choses. Comparez à conditions égales avec l'autorisation de l'administrateur, et annulez les modifications inutiles.

Profil de l’auteur

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

Go Komura

Représentant de KomuraSoft LLC

Axé sur le développement de logiciels Windows, le conseil technique et l’analyse de dysfonctionnements, avec un point fort pour les projets où subsistent des actifs existants et pour les enquêtes sur des pannes dont la cause est difficile à discerner.