最近、モバイル デバイスに RDP アプリをインストールしたのですが、接続先の PC に比べてリソースが限られているこの小型デバイスでも、リモート マシンをほぼフル稼働で操作できるのではないかという疑問が湧きました。では、リモート マシンへの接続で実際に使用されるローカル マシンのリソースはどのくらいなのでしょうか?
また、リモート マシンで使用されるリソースはどれくらいですか?
答え1
帯域幅が主なリソースです。UI アクションは RDP ホストに送信され、そこで処理され、描画操作が返送されます (簡単に言えば)。
答え2
デスクトップ要素はシンボルとしてクライアント マシンに送信され、サード パーティ アプリはビットマップとして送信されるため、これに対する明確な答えはありません。また、DirectX は最新バージョンの RDP を介して動作するため、処理がローカルで実行されるクライアントではより多くのリソースが使用されます。
答え3
クライアント側でもホスト側でも、リソースはほとんど使用されません。RDP プロトコルは帯域幅を使用しますが、それほど多くはありません。当社では、オフィスごとに 20 ～ 30 台を 2Mbps MPLS で問題なく実行しています (同じパイプで IAX トランクも実行しています)。QOS は有効になっていますが、ユーザーが大きなメールを送信するときに問題が発生するのを防ぐためだけにオンにしています。画面イメージを除くすべての処理は、RPD 先のリモート PC によって処理されます。MPLS にアップグレードする前は、IPsec 接続でフル デスクトップをレンダリングする WYSE シン クライアントを何年も実行していました (90 年代初頭に開始されたと思います)。本格的なデスクトップ PC で MSTC と citrix を使用する人が増えたのは、ここ 10 年ほどのことです。ターミナル サービスは、ダミー ターミナル (名前の通り) とシン クライアントで使用するように設計されているため、プロセス全体が合理化され、特にクライアントでリソースをできるだけ使用しなくなりました。
答え4
Mark の言う通りです。リモート マシンのリソースに関しては、使用するクライアントとその記述の質によって異なります。ビットマップ キャッシュを実行し、最新の (より複雑な) 圧縮スキーマをサポートしている場合は、当然、より多くのリソースが必要になります。私は Java ベースの RDP クライアントに取り組んでおり、Blackberry や Android フォンなどのデバイスでも実行できるように、できるだけ薄くて軽量にするよう努めています。最新バージョンをそこでテストしている人は聞いたことがありませんが、Java アプリとしては非常にスムーズに動作していたことは知っています。