次の方法で共有


Azure SignalR Service の内部

Azure SignalR Service は、ASP.NET Core SignalR フレームワーク上に構築されています。 また、ASP.NET Core フレームワーク上に ASP.NET SignalR のデータ プロトコルを再実装することで、ASP.NET SignalR がサポートされます。

コードを数行変更するだけで、ローカルの ASP.NET Core SignalR または ASP.NET SignalR アプリケーションを簡単に移行して、SignalR Service と連携させることができます。

この図は、アプリケーション サーバーと SignalR Service を使う場合の一般的なアーキテクチャを示しています。

セルフホステッド ASP.NET Core SignalR アプリケーションとの相違点についても説明します。

Architecture

アプリケーション サーバー接続

セルフホステッド ASP.NET Core SignalR アプリケーション サーバーはクライアントをリッスンし、クライアントに直接接続します。

SignalR Service を使うと、アプリケーション サーバーは永続的なクライアント接続を受け入れる必要がなくなり、代わりに、次のようになります。

  1. 各ハブの negotiate エンドポイントが Azure SignalR Service SDK によって公開されます。
  2. このエンドポイントがクライアントのネゴシエーション要求に応答し、クライアントを SignalR Service にリダイレクトします。
  3. クライアントは SignalR Service に接続します。

詳しくは、「クライアント接続」を参照してください。

アプリケーション サーバーが起動すると、次のようになります。

  • ASP.NET Core SignalR の場合: Azure SignalR Service SDK により、SignalR Service への WebSocket 接続がハブあたり 5 個開かれます。
  • ASP.NET SignalR の場合: Azure SignalR Service SDK により、SignalR Service への WebSocket 接続がハブあたり 5 個と、WebSocket 接続がアプリケーションあたり 1 個開かれます。

初期接続数の既定値は 5 であり、SignalR Service SDK の InitialHubServerConnectionCount オプションを使って構成できます。 詳細については、「構成」に関する記事を参照してください。

アプリケーション サーバーが SignalR サービスに接続されている間、Azure SignalR サービスからサーバーに負荷分散メッセージが送信されます。 次に、パフォーマンスを向上させるために、SDK はサービスに対する新しいサーバー接続を開始します。 クライアントとの間のメッセージは、これらの接続に多重化されます。

サーバー接続は SignalR Service に永続的に接続されます。 ネットワークの問題により、サーバー接続が切断された場合は、次のようになります。

  • このサーバー接続によって提供されるすべてのクライアントは切断されます。 詳細については、「クライアントとサーバー間のデータ転送」を参照してください。
  • サーバーはクライアントを自動的に再接続します。

クライアント接続

SignalR Service を使う場合、クライアントはアプリケーション サーバーではなくサービスに接続します。 クライアントと SignalR Service の間の永続的な接続は、3 つの手順によって確立されます。

  1. クライアントがアプリケーション サーバーにネゴシエート要求を送信します。

  2. アプリケーション サーバーは、Azure SignalR Service SDK を使って、SignalR Service の URL とアクセス トークンを含むリダイレクト応答を返します。

    • ASP.NET Core SignalR の場合、標準的なリダイレクト応答は次のようになります。
      {
          "url":"https://test.service.signalr.net/client/?hub=chat&...",
          "accessToken":"<a typical JWT token>"
      }
      
    • ASP.NET SignalR の場合、標準的なリダイレクト応答は次のようになります。
      {
          "ProtocolVersion":"2.0",
          "RedirectUrl":"https://test.service.signalr.net/aspnetclient",
          "AccessToken":"<a typical JWT token>"
      }
      
  3. クライアントは、リダイレクト応答を受け取った後、URL とアクセス トークンを使って SignalR Service に接続します。

ASP.NET Core SignalR の詳細については、トランスポート プロトコルに関する記事を参照してください。

クライアントとサーバー間のデータ転送

クライアントが SignalR Service に接続すると、サービス ランタイムによって、このクライアントに使うサーバー接続が検索されます。

  • この手順は 1 回だけ実行されます。クライアントとサーバー接続のマッピングは 1 対 1 です。
  • このマッピングは、クライアントまたはサーバーが切断されるまで SignalR Service に保持されます。

この時点で、アプリケーション サーバーは新しいクライアントからの情報を含むイベントを受け取ります。 クライアントへの論理接続がアプリケーション サーバーに作成されます。 SignalR Service 経由でクライアントからアプリケーション サーバーへのデータ チャネルが確立されます。

SignalR Service により、クライアントからのデータはペアになっているアプリケーション サーバーに転送されます。 アプリケーション サーバーからのデータはマッピングされているクライアントに送信されます。

SignalR Service によって顧客データが保存または格納されることはありません。受信されたすべての顧客データは、リアルタイムでターゲット サーバーまたはクライアントに送信されます。

Azure SignalR Service はアプリケーション サーバーとクライアント間の論理トランスポート層として動作します。 すべての永続的な接続が SignalR Service にオフロードされます。 そのため、アプリケーション サーバーでは、ハブ クラス内でビジネス ロジックの処理のみを行う必要があります。クライアント接続について心配することはありません。

次のステップ

Azure SignalR SDK の詳細については、以下を参照してください。