大きなファイルをRDP経由でより適切にコピーして貼り付ける方法は？
最近、大きな（1.2 GB）ファイルをRDP経由でリモートコンピューターにコピー＆ペーストする試みをいくつか行っていました。リモートコンピューターは、MS Windows Server 2008 Datacenterを備えた仮想テストマシンです。
最初に、クライアントコンピュータのISPによって転送速度が100 kB/sに制限されている真夜中の前にコピーして貼り付けようとしました。そのため、数時間かかり、リモートデスクトップの応答が遅くなり、動作が遅くなった（遅い）ため、転送をキャンセルせざるを得ませんでした。そのため、ローカル転送速度が4MB /秒を超える深夜に再起動しました。
だから、私の印象は、コピー＆ペースト転送の速度（ブロードバンド）とは関係なく、RDP経由でコピーしているときにリモートコンピューターが遅くなるということです。同時に、インターネットからダウンロードしても、リモートホストが遅くなることはありません。
AFAIU、それはリモートコンピュータのクリップボードとそのメモリが転送によって過負荷になるためです。
特定のプロセス（ファイルの貼り付け）でのクリップボードの使用をどのように制御（制限）できますか？
それを制御するために可能な方法は何ですか？
更新：
読み取り後、転送速度が遅いのは、RDPを介したコピーと貼り付けに使用される暗号化が原因であり、ファイル全体を取得するための時間と速さの両方に関心があると信じているため、待機中質問のタイトルを変更しましたから：
- 大きなファイルを貼り付けるためのリモートデスクトップクリップボードの使用法を制御する方法？
に
- 大きなファイルをRDPにコピーして貼り付ける方法
たとえば、1つの巨大な（Zip）アーカイブをコピーして貼り付けるか、それを解凍して、解凍したファイルを含むフォルダーをコピーして貼り付ける方が良いでしょうか。
そしてもっと正確に私は尋ねたかった：
全体的なエクスペリエンスを改善するために可能な方法は何ですか。
- 転送速度（つまり、必要なファイルの可用性）
- リモートホストの応答性（コピー＆貼り付けが完了する前にリモートcoputerを作業に利用できるようにする）？
Zipファイルとは、個々のすべてのファイルと同じサイズの非圧縮アーカイブを意味しますか？または、圧縮アーカイブを意味しますか？なぜなら、圧縮アーカイブについて話していると、転送が速くなるからです。厳密に言えば、それが良いでしょう。もちろん、アーカイブの作成にかかる時間とアーカイブの抽出にかかる時間を考慮すると、アーカイブがルーズファイルよりも優れているかどうかについて、両方のマシンの仕様が関係します。
ここで、（VNCではなく）RDPについて話しているので、リモート接続の帯域幅の使用量はかなり多くなります。 RDPはVNCよりも応答性が高く、色深度は（デフォルトで）256色（変更しない場合は32ビット）を超え、画面サイズはデスクトップのサイズなどになります...これらすべての要因リモート接続にのみ使用されている帯域幅に影響します。リモートデスクトップのサイズや色深度を16ビット以下に落とした場合、サウンドなどを共有していないことを確認してください...これにより、リモート接続に使用される帯域幅が少なくなるため、ファイルを転送している場合、リモートセッションの応答性が向上するはずです。
ただし、最終的には、youがファイル転送を抑制できない限り、リモートセッションは、ファイルの転送中に何を実行しても、処理が遅くなります。可能な限り多くの帯域幅がリモートマシンとマシン間の転送に使用されるためです。
[〜＃〜]編集[〜＃〜]
リモート接続の品質に影響を与えずにファイルを転送する簡単な方法を見つけようとしています。大きいファイルでも小さいファイルでもかまいません。エンド（クライアントマシン）では、少量のデータをリモートマシン（サーバーマシン）に噴出しています。入力、マウスコマンドなど、サーバーは常に、リモート接続を介して表示される画像を構成する画像の形式で、大量のデータを送信しています。したがって、ファイルを転送する前に、大量のデータを一方向に転送しています。そのため、送信するデータの量を減らすためにできることを思いつきました。つまり、デスクトップのリモートマシンの解像度を小さくします（全画面ではありません）。.. 32ビットから16ビット、さらには8ビットの色。この2つの手順を実行すると、サーバー（リモート）からクライアント（ユーザー）に送信するデータの量が減少します。また、同じ接続とルートでファイルの転送を開始すると、リモート接続の影響が少なくなることも意味します。
私が言ったように...あなたができることは何も接続が鮮明で応答性を維持しません。どうして？ファイルをサーバーからクライアントに転送し始めるとすぐに、これはそのパイプに沿って利用可能な帯域幅のすべてのビットを消費します...そして、あなたはすでにそのパイプに沿った帯域幅の一部をリモートに使用しています接続自体。
最初に、クライアントコンピュータのISPによって転送速度が100 kB/sに制限されている真夜中の前にコピーして貼り付けようとしました。そのため、数時間かかり、リモートデスクトップの応答が遅くなり、動作が遅くなった（遅い）ため、転送をキャンセルせざるを得ませんでした。それで、ローカル転送速度が4 GB/sを超えたときに真夜中に再開しました
したがって、最初に転送を試みたとき、ダウンロード接続は100kb/sでした。 1.2 GBのファイルをできるだけ速く移動していました。これにより、100 kb/sを可能な限り多く消費します。リモートデスクトップ接続をサポートするデータ用にwhat余地を残すのはどれですか？ですから、もちろんそれは緩慢で無反応でしょう。あなたが考慮に入れていない唯一のことは、サーバーのアップロード速度です。サーバーのアップロード速度がダウンロード速度より遅い場合...そしてこの完全な仮説では、サーバーとこのアップロード速度を一定に保つことを許可したサーバーとの間のルートは、ファイルの転送を開始するとすぐに、ほぼすべてその帯域幅の一部がファイル転送によって使い果たされ、リモート接続が低下します。
どうして？
ファイル転送を特定の速度、または利用可能な帯域幅の割合に制限するものは何もないため、可能なすべてのkb/sを使用しようとします。物事の性質上、これはリモート接続に影響を与えます。
サーバーからサードパーティ（FTPサーバーなど）にファイルを転送しても、転送中に接続が遅くなります。これも、可能な限り多くの帯域幅がその転送に割り当てられるためです。ただし、その転送が完了すると、リモート接続の応答性に影響を与えずにFTPサーバーからダウンロードできます。これも、深夜0時以降の着信パイプがサーバーの発信パイプよりもはるかに大きいためです。
そこで、リモート接続の品質を下げてみます。
リモートコンピューター上のローカルドライブへのリンクを作成するRDPオプションがあります。これを有効にするには、RDPクライアントを起動し、（表示）オプションをクリックします。→「ローカルリソース」タブを開きます。 →「その他」をクリックします→「ドライブ」チェックボックスを選択します。
接続後、リモートシステムでWindowsエクスプローラを開きます。ローカルドライブは、マイコンピュータのドライブリストの一番下に表示されます。 「C on your_computer_name」として表示されます。
システム間でファイルをドラッグアンドドロップできるようになりました。
私はWindows 7ボックスでuncts名\\ tsclientを使用してrobocopyを使用しています。
私はこれらの答えのどれも実際に問題を非常にうまく処理しないと思います。
Microsoft RDPは、ファイル転送用に最適化されていないプロトコルです。接続が少し遅い場合は、画面の描画やマウスの動きのようなUIパケットと同じネットワークパイプ上を移動するファイルビットの移動により、これらのいずれかがタイムアウトする可能性があります。その後、サーバーは接続が失われたと見なして接続を解除し、IOチャネルを破壊します。これはもちろん問題をさらに悪化させます。
主に、ワークフローを検討し、セキュリティポリシーに違反しない別のチャネル（ワークステーションからではなくインターネットを介してサーバーなど）経由でファイルを移動する簡単な方法があるかどうかを確認する必要があります。
RDPファイルコピーチャネルを使用する必要があると判断した場合は、これらのガイドラインに従ってください。
- クライアントへのUNCパスを介して大きなファイルに直接アクセスしないでください。たとえば、共有フォルダーを有効にし、\ TSCLIENT\shareからファイルにアクセスします。これにより、小さなファイルのパイプを介して大きなファイルコンテンツがプッシュされます。
- ドライブをマッピングすることにより、最適化と安定性が少し向上します。たとえば、Net Use X：\ TSCLIENT\Shareは、ドライブX：を上記の場所にマップします。それでも、ネットワークパイプを過負荷にすると、接続が切断され、ドライブマッピングも切断されます。
- 最も重要なのは、RDPクライアントを起動するときに、ネットワーク帯域幅設定「モデム」または「低速」を選択することです。これにより、ファイル転送とサウンドチャネルの最適化が大幅に改善され、UIコントロールに使用されるパイプの残りの部分を壊すことがなくなります。
- OS X Microsoftリモートデスクトップクライアントでは、この設定は奇妙に利用できません。この場合、MacPortsをインストールしてSudo port install rdesktopを実行すると、rdesktopおよび-xm設定で接続できます（「エクスペリエンス」レベルを「モデムまたは28.8に設定しますK "）
- 上記の推奨事項に従うと、安定性のために最適化された接続が確立され、大きなファイルをプッシュしても切断されません。ここで、コピー/貼り付けやドラッグアンドドロップよりも制御された方法でファイルをコピーします。たとえば、** XCOPY X：*。msi C：\ Install **を試して、ファイル名パターンに一致するアイテムを指定した場所にコピーしますローカル（サーバー）ディレクトリ。
これらの提案がお役に立てば幸いです。彼らは確かに私のために働きます。
@Tomによる彼の回答で示唆されているように、ファイルをC＆Pするのではなく、D＆Dすることをお勧めします。これには、クライアントマシンでCtrl+Cを使用した場合にファイル転送を中断するバグを回避するという追加の利点があります。
http://www.bittorrent.com/sync/download を見てください。
これはヒープが高速で、コピーの完了中にRDPセッションを開く必要がありません。
また、上記の提案のようにUNCパスにアクセスする必要もありません。
乾杯
私はこの種のもののためにブラウザベースのWebRTCベースのファイル転送サービスを使い始めました-私は現在 http://dragshare.com を使用していますが、良い結果が得られています（まだベータ版です）。
RDPのコピーと貼り付けは常に私にとって苦痛でした-非常に遅く、何千ものファイルがある場合、さらに遅くなります。また、最大ファイルサイズの制限があります（警告は表示されません。超過しようとした直後に失敗します）。 WebRTCは、RDPがこれまでに示したものよりもはるかに高速であるようです。