2

なぜ Windows Azure Service Bus が NAT、ファイアウォール、プロキシを介して機能するのか疑問に思っています。Microsoft はこの事実について頻繁に言及していますが、なぜこれが機能するのかについては言及していません。

各参加者が接続を開始すると思いますが、これでは十分ではありません。彼らはいくつかの開いているポート、80 を「悪用」していますか?

ありがとう

4

4 に答える 4

3

Service Bus は、可能であれば、パフォーマンスを向上させるために、TCP 接続に 9350 ～ 9353 ポートを使用しようとします。失敗した場合は、80 と 443 を使用しようとします。ほとんどの場合、ファイアウォールは 80 と 443 をブロックしないため、ローカル サービスは、ファイアウォールを変更しなくても 80/443 経由で sb://xxxx/ に接続できます。次に、クライアントがサービスを呼び出した場合、最初に sb://xxxx/ にヒットし、次に Service Bus が要求を 80/443 経由でマシンに転送し、次に応答を Service Bus に送り返すと応答が転送されますクライアントに戻ります。

それがサービス リモーティング モードです。イベンティング モードを使用している場合は、同様の手順を実行します。

于 2012-02-29T02:05:47.447 に答える
3

Wireshark を実行して確実に判断できるようにしなくても、私の推測では、クライアント (nat/ファイアウォールの背後) が接続を開始し、サーバー (常に開いている) を呼び出して詳細情報を取得しているためです。

さらに説明しましょう: これは、Windows ソケット (および他のソケット システム) ではわずかに異なる動作をするためです。

  1. クライアント (C) はポート 80 でサーバー (S) への接続を開始します

  2. サーバーはクライアントに応答します: 80 の呼び出しが多すぎます。接続をポート 90000 + rnd() = 90001 の次の空いているソケットに移動しましょう

  3. クライアント ソケット マネージャーは、クライアントの未使用のソケットをカウントし、C:90012 ポートを検出するとします。

  4. クライアントは S:90001 でサーバーを呼び出し、C:90012 と S:90001 の間で適切な接続が開始されます

  5. これは、nat/ファイアウォール ボックスの nat テーブルに書き込まれ、C <-> S 間の通信を許可するものです。

于 2012-02-28T14:28:35.413 に答える
2

単純に、各接続がアウトバウンドであり、Service Bus が「フォワーダー」として機能するためです。

于 2012-02-28T14:21:43.877 に答える
1

ここに示すように、多くの構成では実際に 80 (http) と 443 (https) のみを使用します。ただし、9350、9351、9352、および 9353 を使用することもあるようです。シナリオによっては、それらを開く必要がある場合があります。

于 2012-02-28T14:13:24.610 に答える