
EC2 には、RDP を使用して接続できる Windows インスタンスが多数あります。さまざまな帯域幅と遅延条件下での RDP のパフォーマンスをテストしたいと考えています。tc qdisc
マシン上の特定のインターフェイスでトラフィックを制御できるツールについては知っています。ただし、これを開発マシンから独立させておきたいと考えています。別のボックス (おそらく Ubuntu AWS インスタンス) を用意して、RDP 接続がそのマシンのインターフェイスを介してルーティングされるように構成し、そのマシンのさまざまなポートで帯域幅制御を設定できるセットアップが必要でした。これは RDP 接続へのゲートウェイとして機能するため、このゲートウェイの適切なポートに接続することで、特定の帯域幅条件下での RDP のパフォーマンスを確認できます。
サーバーなどのツールをいくつか調べてrinetd
、iptable ルールで作業しようとしました。必要なものに最も近いのは、ゲートウェイを使用した SSH ポート フォワーディングでした。ただし、パフォーマンスに異常が見られるため、SSH を廃止して、透過的な (SSH フリーの) ソリューションを入手できるかどうかを確認したいと思います。ゲートウェイのポートに RDP するだけで、ゲートウェイがこの接続を (事前構成された) リモート マシンに自動的に「転送」できるセットアップが必要です。また、リモート マシンから戻ってくるトラフィックも、ゲートウェイを介してクライアントにリダイレクトされる必要があります。そうすれば、tc qdisc
ゲートウェイで使用して、さまざまな設定での RDP を調査できます。
答え1
想像通りに動作しないというわけではありませんが、Windows ボックス自体の帯域幅を制限するツールを使用すると、より簡単に実行できる可能性があります。いくつかの例を以下に示します。
- ネットリミッター
- シュンラ vCat
これらのツールは帯域幅を制限します。または、Shunra の場合、ネットワークの ping またはパケット損失を低下させます。その後、テスト クライアントから直接接続でき、帯域幅を制限するために接続をルーティングする必要がなくなります。