Zipファイルとは、個々のファイルすべてと同じサイズの非圧縮アーカイブを意味しますか？または、圧縮されたアーカイブを意味しますか？圧縮されたアーカイブについて話している場合、すぐに転送できるので、厳密に言えばより良いでしょう。もちろん、アーカイブの作成にかかる時間と、アーカイブの抽出にかかる時間を考慮すると、両方のマシンの仕様が、アーカイブがルーズファイルよりも優れているかどうかに関して重要になります。
ここで、（VNCとは対照的に）RDPについて話しているので、リモート接続の帯域幅の使用量はかなり多くなります。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サーバーからダウンロードできるようになります...真夜中以降の着信パイプはサーバーの発信パイプよりもはるかに大きいためです。
そのため、リモート接続の品質を低下させてみます。