最近、RDP 経由で大きな (1.2 GB) ファイルをリモート コンピューターにコピー & 貼り付ける試みを何度か行いました。リモート コンピューターは、MS Windows Server 2008 Datacenter を搭載した仮想テスト マシンです。
まず、クライアント コンピュータの ISP によって転送速度が 100 kB/s に制限されていた深夜前にコピー アンド ペーストを試みましたが、数時間かかり、リモート デスクトップが応答しなくなり、遅くなったため、転送をキャンセルせざるを得ませんでした。そこで、ローカル転送速度が 4MB/s を超えた深夜に再開しました。
したがって、私の印象では、コピー アンド ペースト転送の速度 (ブロードバンド) とは関係なく、RDP 経由でコピーしている間はリモート コンピューターの動作が遅くなります。同時に、インターネットからのダウンロードによってリモート ホストが遅くなることはありません。
私の知る限り、これはリモート コンピューターのクリップボードとそのメモリが転送によって過負荷になるためです。
特定のプロセス (ファイルの貼り付け) のクリップボードの使用を制御 (制限) するにはどうすればよいでしょうか。
それを制御するにはどのような方法がありますか?
アップデート：
転送速度が遅いのは、RDP経由のコピー＆ペーストに使用される暗号化が原因であると読んだ後、私は全体的な効率性、つまりファイルを取得する時間や速さ、そして待たずに作業できる可能性に興味があると思うので、質問のタイトルを変更しましたから：
- 大きなファイルを貼り付けるためにリモート デスクトップのクリップボードの使用を制御するにはどうすればよいでしょうか?
に
- RDP 経由で大きなファイルをより効率的にコピー＆ペーストするにはどうすればよいでしょうか?
たとえば、1 つの巨大な (zip) アーカイブをコピーして貼り付ける方がよいのでしょうか、それともそれを解凍して、解凍されたファイルを含むフォルダーをコピーして貼り付ける方がよいのでしょうか。
もっと正確に聞きたかったのは、次のことです。
全体的なエクスペリエンスを向上させるために考えられる方法は何ですか?
- 転送速度（必要なファイルの可用性）
- リモート ホストの応答性 (コピー & 貼り付けが完了する前にリモート コンピューターを作業に使用できるようにする)?
答え1
Zip ファイルとは、個々のファイルと同じサイズの非圧縮アーカイブのことですか? それとも圧縮アーカイブのことですか? 圧縮アーカイブの場合、転送速度が速くなるので、厳密に言えばその方がよいです。もちろん、アーカイブの作成にかかる時間とアーカイブの解凍にかかる時間を考慮すると、両方のマシンの仕様が、アーカイブがルーズ ファイルよりも優れているかどうかに影響します。
さて、RDP (VNC ではなく) についてお話しているので、リモート接続の帯域幅の使用量は相当なものです。RDP は VNC よりも応答性が高く、色深度は (デフォルトでは) 256 色以上 (変更しない場合は 32 ビット)、画面サイズはデスクトップのサイズになります。これらすべての要素が、リモート接続に使用される帯域幅の量に影響します。リモート デスクトップのサイズや色深度を 16 ビット以下に下げたり、サウンドを共有していないことを確認したりすると、リモート接続に使用される帯域幅が少なくなり、ファイルを転送するときにリモート セッションの応答性が向上します。
しかし、結局のところ、あなたファイル転送を制限できる場合、リモート マシンと自分のマシン間の転送に可能な限り多くの利用可能な帯域幅が使用されるため、ファイル転送中に何をしてもリモート セッションは遅くなります。
編集
リモート接続の品質に影響を与えずにファイルを転送する簡単な方法を見つけようとしています。ファイルが大きいか小さいかは関係ありません。あなたの側 (クライアント マシン) では、リモート マシン (サーバー マシン) に少量のデータを流しています。ご存知のように、入力、マウス コマンドなどです。サーバーは、リモート接続を介して表示される画像という形で、常に大量のデータを送信しています。したがって、ファイルを転送する前から、すでに大量のデータを一方向に転送しています。そのため、転送するデータの量を減らすために実行できることを挙げました。つまり、デスクトップのリモート マシンの解像度を低くします (フル スクリーンではなく)。色の数を 32 ビットから 16 ビット、または 8 ビットに減らします。この 2 つの手順を実行すると、サーバー (リモート) からクライアント (あなた) に転送するデータの量が減ります。また、同じ接続とルートでファイルを転送し始めると、リモート接続への影響が少なくなります。
前にも述べたように、接続を鮮明かつ応答性の高い状態に保つためにできることは何もありません。なぜでしょうか? サーバーからクライアントにファイルを転送し始めるとすぐに、そのパイプで利用可能な帯域幅がすべて消費されてしまうからです。そして、そのパイプの帯域幅の一部は、リモート接続自体のためにすでに使用されています。
まず、クライアント コンピュータの ISP によって転送速度が 100 kB/s に制限されていた深夜前にコピー アンド ペーストを試みました。そのため、数時間かかり、リモート デスクトップが応答しなくなり、遅くなったため、転送をキャンセルせざるを得ませんでした。そこで、ローカル転送速度が 4 GB/s を超えた深夜に再開しました。
最初に転送を試みた時、ダウンロード接続は100kb/sでした。1.2GBのファイルをできるだけ速く転送しようとしていたので、100kb/sをできるだけ多く消費しようとしました。何リモート デスクトップ接続をサポートするデータのためのスペースは十分ですか? そうすると、当然、遅くなり、応答しなくなります。 考慮に入れていない唯一の点は、サーバーのアップロード速度です。 サーバーのアップロード速度がダウンロード速度よりも遅い場合... この完璧な仮定では、サーバーとユーザーの間のルートでこのアップロード速度が一定に保たれていると仮定すると、ファイルの転送を開始するとすぐに、その帯域幅のほとんどすべてがファイル転送によって消費され、リモート接続に支障をきたします。
なぜ？
ファイル転送を特定の速度、または利用可能な帯域幅のパーセンテージに制限するものがないため、可能な限りすべての kb/s を使用しようとします。性質上、これによりリモート接続に悪影響が出ます。
サーバーからサードパーティ (どこかの FTP サーバーなど) にファイルを転送する場合でも、その転送中は接続が遅くなります。これは、使用可能な帯域幅の可能な限り多くがその転送に割り当てられるためです。ただし、転送が完了すると、リモート接続の応答性に影響を与えることなく、FTP サーバーからダウンロードできるようになります。これは、深夜以降の受信パイプがサーバーの送信パイプよりもはるかに大きいためです。
したがって、リモート接続の品質を下げてみます。
答え2
リモートコンピュータ上のローカルドライブへのリンクを作成するRDPオプションがあります。これを有効にするには、RDPクライアントを起動し、（表示）をクリックします。オプション、→「ローカルリソース「タブ」→「クリック」もっと「→」をチェックドライブ「」チェックボックスをオンにします。
接続後、リモート システムで Windows エクスプローラーを開きます。ローカル ドライブは、マイ コンピューターのドライブ リストの一番下に表示されます。「your_computer_name の C」として表示されます。
あるシステムから別のシステムにファイルをドラッグ アンド ドロップできるようになりました。
答え3
私は、UNC 名 \\tsclient を使用して、Windows 7 ボックスで robocopy を使用しています。
答え4
@Tom の回答で示唆されているように、C&P ではなく、D&D でファイルを転送する方が望ましいです。これには、Ctrl+Cクライアント マシンで使用する場合にファイル転送を中断するバグを回避できるという追加の利点があります。