リモートデスクトップの通信データ量について
こんにちは。Windows テクノロジー サポートの大羽です。
Windows 7 や Windows Vista といったクライアント コンピュータから、
Windows Server 2008、Windows Server 2008 R2 といったサーバー OS まで
幅広くご利用いただいているリモートデスクトップ サービスですが、
実際の通信データ量がどのくらい発生するのか気になったことはないでしょうか。
ターミナルサーバーに対して、複数のシン クライアントからアクセスするような
運用方法を検討している場合、1 クライアント セッションでどれくらいの
通信帯域が使用されるのかが分からなければ、ネットワーク周りのインフラ設計を
行うことは困難かと思います。
リモートデスクトップの通信では、リモート デスクトップ プロトコル (RDP) と
いうプロトコルが使用されており、キーボード、マウスという入力情報や
デスクトップ画面の情報を通信データとしてやり取りします。
文書番号: 186607
リモートデスクトップ プロトコル (RDP) の解説
https://support.microsoft.com/kb/186607/ja
デスクトップの画面情報を通信データとしてやり取りするとなりますと、
かなり大きなデータが送信されるのではないか、と考えてしまいますが、
画面情報としては差分データのみを転送しており、かつ圧縮を施しているため、
データ量が意外と小さくなっています。
では、具体的にどのくらいの通信量なのか？
残念ながら、現時点では明確なデータ量を示す情報は公開しておりません。
公開していないというよりは、ターミナルサービスの通信データ量は、
設定や使用方法によって通信量が変わってくるため、明確な数字はお出し
できない、という表現が正しいかもしれません。
例えば、以下のリモートデスクトップ クライアントの設定画面にありますように
画面の設定サイズや画面の色、更にフォントスムージングやデスクトップ
コンポジションといったエクスペリエンス機能の設定、また実際の操作方法などに
よって情報量が大きく変化します。
では、リモートデスクトップの通信量はどのように判断すればよいのかと
言いますと、答えは「実測」です。
実測の方法は単純で、フリーのパケットキャプチャ ソフトである Wireshark や
弊社製の Netmon などをご利用いただき、認証、操作なし、操作あり、など
実際の運用方法にマッチした形で通信データ量を実測します。
例えば、wireshark では [Statistics]-[Summary] から通信データのサマリーを
表示することができます。
認証、操作なし、操作あり、などオペレーションを時間で区切り、その間の
サマリーを表示することで、ある程度正確な通信データ量の計測が可能です。
それで、最後にネットワーク周りのインフラ設計ですが、実はネットワーク
トラフィックというのは平均化しないという特徴を持っており、統計学としても
確立していないため、明確な見積もりができないというのが現状です。
どういうことかと言いますと、トラフィックピークが一気に立つこともあれば
逆に全くトラフィックが発生しないこともある、ということです。
そのため、平均的な通信データ量でインフラ設計することができないため、
最後はどんぶり勘定(オーバー プロビジョニング)で、多少余裕のあるインフラ
を設計するのが一般的です。
とは、言いましても、ある程度基準となる通信データ量は抑えておく必要が
あるので、是非通信データの実測を行ってみてください。
以下、ご参考までに実際に測定した結果を記載させていただきます。
ただし、あくまで参考値としてご参照ください。
///
/// 検証結果
///
<< 検証環境 >>
サーバー： Windows Server 2003 Std SP2
クライアント： Windows XP SP2 (RDC 6.0.6001.18000)
検証結果 1/ デフォルト設定 - 標準オプション
===================================================
画面：
リモート デスクトップのサイズ --- 最大 (サーバー画面 800 x 600)
画面の色 --- High Color (16 ビット)
エクスペリエンス：
接続速度 --- モデム (56 Kbps)
デスクトップの背景 --- OFF
フォント スムージング --- OFF
デスクトップ コンポジション --- OFF
ドラッグ中にウインドウの内容を表示 --- OFF
メニューとウィンドウ アニメーション --- OFF
テーマ --- ON
ビットマップのキャッシュ --- ON
< 作業全体の総データ >
300 sec Between first and last packet
2900 Packets
632,000 Bytes
2000 Avg.bytes/sec
作業全体の総データ転送量：約 600 KB
< 各操作の内訳 >
認証処理：平均 3,500 bytes / sec
操作なし：平均 30 bytes / sec
操作あり：平均 3,000 bytes / sec
検証結果 2/ データ量最小 - 画面の色 256
=================================================
画面：
リモート デスクトップのサイズ --- 最大 (サーバー画面 800 x 600)
画面の色 --- 256
エクスペリエンス：
接続速度 --- モデム (56 Kbps)
デスクトップの背景 --- OFF
フォント スムージング --- OFF
デスクトップ コンポジション --- OFF
ドラッグ中にウインドウの内容を表示 --- OFF
メニューとウィンドウ アニメーション --- OFF
テーマ --- ON
ビットマップのキャッシュ --- ON
< 作業全体の総データ >
300 sec Between first and last packet
2300 Packets
459,000 Bytes
1500 Avg.bytes/sec
作業全体の総データ転送量：約 448 KB
< 各操作の内訳 >
認証処理：平均 2,300 bytes / sec
操作なし：平均 10 bytes / sec
操作あり：平均 2,000 bytes / sec
検証結果 3/ データ量最大 - 全てのオプションを有効
==========================================================
画面：
リモート デスクトップのサイズ --- 最大 (サーバー画面 800 x 600)
画面の色 --- High Color (16 ビット)
エクスペリエンス：
接続速度 --- LAN (10 Mbps 以上)
デスクトップの背景 --- ON
フォント スムージング --- ON
デスクトップ コンポジション --- ON
ドラッグ中にウインドウの内容を表示 --- ON
メニューとウィンドウ アニメーション --- ON
テーマ --- ON
ビットマップのキャッシュ --- ON
< 作業全体の総データ >
300 sec Between first and last packet
9800 Packets
695,000 Bytes
2300 Avg.bytes/sec
作業全体の総データ転送量：約 680 KB
< 各操作の内訳 >
認証処理：平均 3,000 bytes / sec
操作なし：平均 90 bytes / sec
操作あり：平均 4,500 bytes / sec
検証結果 4/ デフォルト設定 - 標準オプション
===================================================
画面：
リモート デスクトップのサイズ --- 最大 (サーバー画面 1024 x 768)
画面の色 --- High Color (16 ビット)
エクスペリエンス：
接続速度 --- モデム (56 Kbps)
デスクトップの背景 --- OFF
フォント スムージング --- OFF
デスクトップ コンポジション --- OFF
ドラッグ中にウインドウの内容を表示 --- OFF
メニューとウィンドウ アニメーション --- OFF
テーマ --- ON
ビットマップのキャッシュ --- ON
< 作業全体の総データ >
300 sec Between first and last packet
2600 Packets
450,000 Bytes
1700 Avg.bytes/sec
作業全体の総データ転送量：約 440 KB
< 各操作の内訳 >
認証処理：平均 2,800 bytes / sec
操作なし：平均 50 bytes / sec
操作あり：平均 3,100 bytes / sec
---
上記「操作あり」部の結果を参照していただきますと、実際に画面操作を
行った際の通信データ量の比較ができます。
ある意味このデータが 1 ユーザー辺りの最大通信量を示す値になるかと
思いますが、検証結果 1 ～ 4 の結果を比較いただくと分かるように
画面の解像度はデータ量に大きく影響するようです。
逆に画面サイズなどは、差分のみが送信されるため、さほど大きく影響して
いないように見えます。
他にも色々と試していただくことで、実際の運用環境に合った通信データ量が
見えてくるかと思います。
また、ベースとなる通信データを抑えておくことで、実際の運用段階に入って
からも、通信データの変動を管理することができ、将来的なスケールアップ
など、事前に見積もることも可能になるかと思います。