Comment mieux copier et coller de gros fichiers sur RDP?
Récemment, je faisais quelques tentatives pour copier et coller un gros fichier (1,2 Go) sur un ordinateur distant via RDP. L'ordinateur distant est une machine de test virtuelle avec MS Windows Server 2008 Datacenter.
J'ai d'abord essayé de copier-coller avant minuit, lorsque la vitesse de transfert était limitée à 100 ko/s par l'ordinateur client. Donc, cela a pris quelques heures et j'ai été obligé d'annuler le transfert car le bureau à distance est devenu trop insensible et lent (lent). Donc, je l'ai redémarré à minuit lorsque ma vitesse de transfert local est supérieure à 4 Mo/s.
Donc, mon impression est que, indépendamment de la vitesse (large bande) du transfert copier-coller, l’ordinateur distant devient lent lorsqu’il copie sur RDP. Dans le même temps, le téléchargement à partir d'Internet ne ralentit pas l'hôte distant.
AFAIU, c’est parce que presse-papier de l’ordinateur distant et que sa mémoire est surchargée par le transfert.
Comment puis-je contrôler (restreindre) l'utilisation du presse-papier pour un processus spécifique (collage de fichier)?
Quels sont les moyens possibles pour le contrôler?
Mise à jour:
Après lecture, cette lenteur du transfert est causée par le chiffrement utilisé pour copier/coller sur RDP et, depuis, je suis plus intéressé par l’efficacité globale: le temps, ou la rapidité, pour obtenir un fichier ainsi que la possibilité de travailler sans en attente, j'ai changé le titre de la question de:
- Comment contrôler l'utilisation du presse-papier du bureau distant pour le collage d'un fichier volumineux?
à
- Comment mieux copier et coller de gros fichiers sur RDP?
Par exemple, est-il préférable de copier-coller une énorme archive (Zip) ou de la décompresser et de copier-coller un dossier contenant des fichiers non compressés?
Et plus précisément, je voulais demander:
Quels sont les moyens possibles d'améliorer l'expérience globale:
- la rapidité du transfert (c'est-à-dire la disponibilité du fichier nécessaire)
- réactivité de l'hôte distant (mise à disposition d'un ordinateur distant avant le travail de copier-coller)?
Lorsque vous parlez de fichier Zip, voulez-vous dire une archive non compressée de la même taille que tous les fichiers? Ou voulez-vous dire une archive compressée? Parce que là-bas, si vous parlez d'une archive compressée, vous obtiendrez un transfert plus rapide, ce qui serait mieux, à proprement parler. Bien sûr, si vous prenez en compte le temps nécessaire à la création de l'archive et à l'extraction de l'archive, les spécifications des deux machines entrent en jeu pour déterminer si l'archive est meilleure que les fichiers perdus.
Maintenant, puisque vous parlez de RDP (par opposition à VNC), la bande passante utilisée par la connexion distante est assez lourde. RDP est plus réactif que VNC, la profondeur de couleur est (par défaut) supérieure à 256 couleurs (32 bits si vous ne le changez pas), la taille de l’écran sera celle de votre bureau, etc ... tous ces facteurs affecte la quantité de bande passante utilisée uniquement pour la connexion distante. Si vous supprimez des éléments tels que ... la taille du bureau distant et la profondeur de couleur jusqu'à 16 bits ou moins, assurez-vous de ne pas partager le son, etc ... vous utiliserez moins de bande passante pour la connexion distante. vous transférez des fichiers, la session distante devrait être plus réactive.
En fin de compte cependant, à moins que vous puissiez limiter le transfert de fichiers, la session distante va devenir lente, peu importe ce que vous faites pendant le transfert de fichiers, la bande passante possible sera utilisée pour le transfert entre la machine distante et votre machine.
EDIT
Vous essayez de trouver un moyen simple de transférer des fichiers SANS affecter la qualité de la connexion à distance. Peu importe qu'il s'agisse de gros fichiers ou de petits fichiers. De votre côté (la machine cliente), vous éjectez de petites quantités de données sur la machine distante (machine serveur). Vous savez ... taper, commandes de la souris, etc. Le serveur vous envoie tout le temps de grandes quantités de données, sous la forme d'images qui constituent ce que vous voyez via la connexion distante. Donc, avant de transférer des fichiers, vous transférez déjà une grande quantité de données dans une direction. C'est pourquoi j'ai évoqué les mesures que vous pouvez prendre pour réduire la quantité de données que vous transmettez ... à savoir utiliser une résolution plus petite pour la machine distante sur votre bureau (par opposition à l'écran complet) .... pour réduire le nombre de couleurs de 32 bits à 16 bits ou même 8 bits. Ces deux étapes là-bas vont laisser tomber la quantité de données que vous transmettez du serveur (distant) au client (vous). Cela signifie également que lorsque vous commencez à transférer des fichiers via la même connexion et le même itinéraire, votre connexion à distance en souffrira moins.
Comme je l’ai dit, rien ne pourra rendre la connexion nette et réactive. Pourquoi? Dès que vous commencez à transférer des fichiers du serveur vers le client, cela va absorber chaque bande de bande passante disponible le long de ce canal .... et vous utilisez déjà une partie de la bande passante le long de ce canal pour la connexion distante. connexion elle-même.
J'ai d'abord essayé de copier-coller avant minuit, lorsque la vitesse de transfert était limitée à 100 ko/s par l'ordinateur client. Donc, cela a pris quelques heures et j'ai été obligé d'annuler le transfert car le bureau à distance est devenu trop insensible et lent (lent). Je l'ai donc redémarré à minuit lorsque ma vitesse de transfert local est supérieure à 4 Go/s.
Ainsi, lorsque vous avez essayé le transfert pour la première fois, vous disposiez d'une connexion de téléchargement de 100 Ko/s. Vous déplaciez 1,2 Go de fichiers le plus rapidement possible, ce qui pousserait Push à consommer autant de ces 100 Ko/s que possible. Ce qui laisserait quelle pièce pour les données prenant en charge la connexion de bureau à distance? Donc, bien sûr, ce serait lent et insensible. La seule chose que vous ne prenez pas également en compte, est la vitesse de téléchargement du serveur. Si la vitesse de téléchargement du serveur est inférieure à votre vitesse de téléchargement ... et que, dans cette hypothèse parfaite, la route entre le serveur et vous permettiez à cette vitesse de téléchargement de rester constante, dès que vous commencez à transférer les fichiers, à peu près tout. de cette bande passante va être consommée par le transfert de fichier, ce qui fera souffrir la connexion distante.
Pourquoi?
Etant donné que rien ne limite le transfert de fichiers à une vitesse spécifique, ni à un pourcentage de la bande passante disponible, il va tenter d'utiliser chaque kilo par seconde possible. De par la nature des choses, cela fera souffrir la connexion à distance.
Même le transfert des fichiers du serveur vers un tiers (comme un serveur FTP quelque part) rendrait la connexion lente pendant ce transfert, car là encore, la plus grande partie de la bande passante disponible serait allouée à ce transfert. Une fois ce transfert effectué, vous pourrez le télécharger à partir du serveur FTP sans affecter la réactivité de la connexion distante ... encore une fois, car votre canal entrant après minuit est beaucoup plus volumineux que le canal sortant du serveur.
Donc, je voudrais essayer de réduire la qualité de la connexion à distance.
Il existe une option RDP qui crée un lien vers votre lecteur local sur l’ordinateur distant. Pour l'activer, démarrez le client RDP, cliquez sur (Afficher) Options , → ouvrez le " Ressources locales "Onglet. → cliquez sur " Plus " → cochez la case " Disques ".
Une fois la connexion établie, ouvrez l'Explorateur Windows sur le système distant. Votre lecteur local doit apparaître au bas de la liste des lecteurs dans Poste de travail. Il apparaît en tant que "C sur votre nom_ordinateur".
Vous pouvez maintenant faire glisser et déposer des fichiers d'un système à un autre.
J'utilise robocopy sur ma fenêtre Windows 7, en utilisant le nom unc \\ tsclient.
Je pense qu'aucune de ces réponses ne répond vraiment très bien à la question.
Microsoft RDP est un protocole qui n'est pas vraiment optimisé pour le transfert de fichiers. Si votre connexion est un peu lente, le déplacement des bits de fichier, qui voyagent sur le même canal de réseau que les paquets de l'interface utilisateur tels que les tracés d'écran et les mouvements de la souris, peut entraîner l'expiration de l'un de ces éléments; et ensuite, le serveur supposera que vous avez perdu votre connexion et vous déconnectera, cassant vos canaux IO. Bien entendu, cela aggrave le problème.
En premier lieu, vous devez examiner votre flux de travail et voir si vous disposez d'un moyen plus simple de déplacer les fichiers sur un autre canal (par exemple sur Internet vers votre serveur plutôt que depuis votre station de travail) sans violer votre stratégie de sécurité.
Si vous décidez que vous devez utiliser le canal de copie de fichiers RDP, suivez alors ces instructions qui me conviennent parfaitement.
- N'accédez pas aux fichiers volumineux directement sur le chemin UNC du client. Par exemple, l'activation de dossiers partagés et l'accès au fichier à partir de\TSCLIENT\share. Cela pousse le contenu du fichier volumineux sur le petit tuyau multi-usage.
- Vous obtiendrez un peu d'optimisation et de stabilité en mappant un lecteur. Par exemple, Net Use X:\TSCLIENT\Share mappera un lecteur X: à l'emplacement ci-dessus. Néanmoins, une surcharge des canaux réseau vous déconnectera et déconnectera également le mappage de votre lecteur.
- Plus important encore, lors du démarrage du client RDP, choisissez le paramètre de bande passante réseau "Modem" ou "Lent". Cela optimisera beaucoup mieux les canaux de transfert de fichiers et audio, de sorte qu'ils ne puissent pas encombrer le reste du canal utilisé pour le contrôle de l'interface utilisateur.
- Sur le client OS X Microsoft Remote Desktop, ce paramètre est étrangement indisponible. Dans ce cas, installez MacPorts et exécutez le port de Sudo, installez rdesktop , puis vous pourrez vous connecter avec rdesktop et le - xm réglage (définissez le niveau "d'expérience" sur "modem ou 28.8K")
- Si vous suivez les recommandations ci-dessus, vous disposerez désormais d'une connexion optimisée pour la stabilité et le transfert de fichiers volumineux ne vous déconnectera pas. Maintenant, utilisez une méthode plus contrôlée pour copier les fichiers que copier/coller ou glisser-déposer: par exemple, essayez ** XCOPY X: *. Msi C:\Install ** pour copier les éléments correspondant à un motif de nom de fichier dans le fichier spécifié. répertoire local (serveur).
J'espère que quelqu'un trouvera ces suggestions utiles. Ils travaillent certainement pour moi.
Comme suggéré dans sa réponse par @Tom, il est préférable de D & D les fichiers au lieu de C & Ping. Cela présente l'avantage supplémentaire de contourner un bogue qui interrompt le transfert de fichier si vous utilisez Ctrl+C sur la machine cliente.
Jetez un oeil à http://www.bittorrent.com/sync/download
Ceci est beaucoup plus rapide et ne nécessite pas l'ouverture de la session RDP pendant la fin de la copie.
Cela ne nécessite pas non plus que vous ayez accès au chemin UNC comme dans les suggestions ci-dessus.
À votre santé
J'ai commencé à utiliser des services de transfert de fichiers basés sur WebRTC, basés sur un navigateur, pour ce genre de choses - j'utilise actuellement http://dragshare.com avec bons résultats (toujours en version bêta).
Copier-coller RDP a toujours été une douleur pour moi - c'est très lent, et si vous avez des milliers de fichiers, le processus est encore plus lent. Il a également une limite de taille de fichier maximale (pour laquelle il ne vous avertit pas, il échoue après avoir essayé de le dépasser). WebRTC semble être bien plus rapide que tout ce que RDP m'a jamais montré.