SignalR 入門

提供 : Patrick Fletcher

警告

このドキュメントは、最新バージョンの SignalR を使用したドキュメントではサポートされています。 SignalR の ASP.NET Coreします

この記事では、SignalR とは何か、およびそれが作成するように設計されたソリューションの一部について説明します。

質問とコメント

このチュートリアルを気に入った方法と、ページの下部にあるコメントで改善できる機能に関するフィードバックをお寄せください。 チュートリアルに直接関連しない質問がある場合は、ASP.NET SignalR フォーラムまたは StackOverflow.com に投稿できます

SignalR とは

ASP.NET SignalR は、アプリケーション ASP.NET リアルタイム Web 機能を追加するプロセスを簡略化する、開発者向けのライブラリです。 リアルタイム Web 機能は、クライアントが新しいデータを要求するのをサーバーに待たされるのではなく、接続されたクライアントが使用可能になったらすぐに、サーバー コードでコンテンツをプッシュする機能です。

SignalR を使用すると、任意の種類の "リアルタイム" Web 機能をアプリケーションに ASP.NET できます。 チャットは多くの場合、例として使用しますが、さらに多くのことを実行できます。 ユーザーが Web ページを更新して新しいデータを表示したり、ページが新しいデータを取得するために長いポーリングを実装したりすると、SignalR を使用する候補です。 たとえば、ダッシュボードや監視アプリケーション、共同作業アプリケーション (ドキュメントの同時編集など)、ジョブの進行状況の更新、リアルタイム フォームなどです。

SignalR では、リアルタイム ゲームなど、サーバーからの頻度の高い更新を必要とする、完全に新しい種類の Web アプリケーションも有効になります。

SignalR は、サーバー側の .NET コードからクライアント ブラウザー (および他のクライアント プラットフォーム) で JavaScript 関数を呼び出すサーバー間リモート プロシージャ コール (RPC) を作成するための単純な API を提供します。 SignalR には、接続管理 (たとえば、接続イベントと切断イベント)、および接続のグループ化のための API も含まれています。

Invoking methods with SignalR

SignalR では、自動的に接続管理が処理され、ユーザーは、チャットルームのように、同時に接続されているすべてのクライアントにメッセージをブロードキャストすることができます。 また、特定のクライアントにメッセージを送信することもできます。 クライアントとサーバー間の接続は、通信ごとに再確立される従来の HTTP 接続とは異なり、永続的なものです。

SignalR では"サーバー プッシュ" 機能がサポートされています。サーバー コードは、現在、Web で一般的な要求応答モデルではなく、リモート プロシージャ コール (RPC) を使用してブラウザーのクライアント コードに呼び出しを行えます。

SignalR アプリケーションでは、組み込みのサードパーティ製のスケールアウト プロバイダーを使用して、数千のクライアントにスケールアウトできます。

組み込みプロバイダーには次のものが含まれます。

サード パーティプロバイダーには次のものが含まれます。

SignalR はオープンソースで、アプリケーションからアクセスGitHub

SignalR と WebSocket

SignalR は、使用可能な場合は新しい WebSocket トランスポートを使用し、必要に応じて古いトランスポートに戻します。 WebSocket を使用してアプリを直接記述することもできますが、SignalR を使用すると、実装する必要がある追加機能の多くが既に完了しています。 最も重要なのは、古いクライアント用に別のコード パスを作成する心配をすることなく、WebSocket を利用するためにアプリをコード化できるという意味です。 SignalR は、基になるトランスポートの変更をサポートするために SignalR が更新され、WebSocket のバージョン間で一貫したインターフェイスがアプリケーションに提供されるので、WebSocket の更新について心配する必要がなから保護されます。

トランスポートとフォールバック

SignalR は、クライアントとサーバーの間でリアルタイムの作業を行うのに必要なトランスポートの一部に対する抽象化です。 SignalR はまず、可能であれば WebSocket 接続の確立を試みる。 WebSocket は次の機能を持つため、SignalR に最適なトランスポートです。

  • サーバー メモリの最も効率的な使用。
  • 最も短い待機時間。
  • クライアントとサーバー間の全二重通信など、最も基になる機能。
  • 最も厳しい要件である WebSocket には、サーバーが必要です。
    • Windows Server 2012 または Windows 8 で実行します。
    • .NET Framework 4.5。

これらの要件が満たされていない場合、SignalR は他のトランスポートを使用して接続を行います。

HTML 5 トランスポート

これらのトランスポートは、 HTML 5 のサポートに依存します。 クライアント ブラウザーが HTML 5 標準をサポートしていない場合は、古いトランスポートが使用されます。

  • WebSocket (サーバーとブラウザーの両方が Websocket をサポートできると示している場合)。 WebSocket は、クライアントとサーバーの間に真の永続的な 2 ウェイ接続を確立する唯一のトランスポートです。 ただし、WebSocket には最も厳しい要件があります。Microsoft Internet Explorer、Google Chrome、Mozilla Firefox の最新バージョンでのみ完全にサポートされ、Opera や Safari などの他のブラウザーでは部分的な実装しか行されていません。
  • サーバー送信イベント (EventSource とも呼ばれる) (ブラウザーでサーバー送信イベントがサポートされている場合は 、基本的にはサーバー送信イベントを除くInternet Explorer。

Comet トランスポート

次のトランスポートは Comet Web アプリケーション モデルに基づいており、ブラウザーまたは他のクライアントが長時間保持される HTTP 要求を保持します。この要求は、サーバーは、クライアントが特に要求せずにクライアントにデータをプッシュするために使用できます。

  • Forever Frame (Internet Explorerのみ)。 Forever Frame は非表示の IFrame を作成します。これにより、完了しないサーバー上のエンドポイントに要求が行われます。 その後、サーバーはスクリプトをクライアントに継続的に送信します。このスクリプトはすぐに実行され、サーバーからクライアントへの一方通行のリアルタイム接続が提供されます。 クライアントからサーバーへの接続では、サーバーからクライアントへの接続とは別の接続が使用され、標準の HTTP 要求と同様に、送信する必要があるデータごとに新しい接続が作成されます。
  • Ajax の長いポーリング。 長いポーリングでは永続的な接続は作成されませんが、サーバーが応答するまで開いたままの要求でサーバーをポーリングします。その時点で接続が閉じ、新しい接続がすぐに要求されます。 これにより、接続のリセット中に待機時間が発生する可能性があります。

どの構成でサポートされるトランスポートの詳細については、「サポートされているプラットフォーム 」を参照してください

トランスポートの選択プロセス

次の一覧は、SignalR が使用するトランスポートを決定するために使用する手順を示しています。

  1. ブラウザーが 8 以前Internet Explorer場合は、Long Polling が使用されます。

  2. JSONP が構成されている場合 (つまりjsonptrue、接続の開始時に パラメーターが に設定されます)、長いポーリングが使用されます。

  3. クロスドメイン接続が行われる場合 (つまり、SignalR エンドポイントがホスティング ページと同じドメイン内にない場合)、次の条件が満たされた場合は WebSocket が使用されます。

    • クライアントは CORS (クロスオリジン リソース共有) をサポートしています。 CORS をサポートするクライアントの詳細については、 CORS に関するページを caniuse.com。

    • クライアントは WebSocket をサポートします

    • サーバーは WebSocket をサポートしています

      これらの条件が満たされていない場合は、長いポーリングが使用されます。 ドメイン間接続の詳細については、「ドメイン間接続 を確立する方法」を参照してください

  4. JSONP が構成されていない場合、接続がクロスドメインではない場合、クライアントとサーバーの両方でサポートされている場合は、WebSocket が使用されます。

  5. クライアントまたはサーバーが WebSocket をサポートしていない場合は、サーバー送信イベントが使用可能な場合に使用されます。

  6. サーバー送信イベントを使用できない場合は、Forever Frame が試行されます。

  7. Forever Frame が失敗した場合は、Long Polling が使用されます。

トランスポートの監視

ハブでログ記録を有効にし、ブラウザーでコンソール ウィンドウを開いて、アプリケーションが使用しているトランスポートを確認できます。

ブラウザーでハブのイベントのログ記録を有効にするには、クライアント アプリケーションに次のコマンドを追加します。

$.connection.hub.logging = true;

  • このInternet Explorer F12 キーを押して開発者ツールを開き、[コンソール] タブをクリックします。

    Console in Microsoft Internet Explorer

  • Chrome で、Ctrl + Shift + J キーを押してコンソールを開きます。

    Console in Google Chrome

コンソールを開いてログ記録を有効にすると、SignalR によって使用されているトランスポートを確認できます。

Console in Internet Explorer showing WebSocket transport

トランスポートの指定

トランスポートのネゴシエートには、一定の時間とクライアント/サーバー リソースが必要です。 クライアント機能が既知の場合は、クライアント接続の開始時にトランスポートを指定できます。 次のコード スニペットは、クライアントが他のプロトコルをサポートしていない場合に使用される Ajax Long Polling トランスポートを使用して接続を開始する方法を示しています。

connection.start({ transport: 'longPolling' });

クライアントが特定のトランスポートを順番に試す場合は、フォールバック順序を指定できます。 次のコード スニペットは、WebSocket を試し、それを失敗させ、Long Polling に直接移動する方法を示しています。

connection.start({ transport: ['webSockets','longPolling'] });

トランスポートを指定する文字列定数は、次のように定義されます。

  • webSockets
  • foreverFrame
  • serverSentEvents
  • longPolling

接続とハブ

SignalR API には、クライアントとサーバー間で通信するための 2 つのモデルが含まれています。永続的な接続とハブです。

接続は、単一受信者、グループ化、またはブロードキャスト メッセージを送信する単純なエンドポイントを表します。 Persistent Connection API (PersistentConnection クラスによって .NET コードで表されます) を使用すると、開発者は SignalR が公開する低レベルの通信プロトコルに直接アクセスできます。 接続通信モデルの使用は、Communication Foundation などの接続ベースの API を使用した開発者Windows慣れ親しんだものになります。

ハブは、クライアントとサーバーが互いにメソッドを直接呼び出す接続 API を基に構築された、より高レベルのパイプラインです。 SignalR はマジックでの場合と同様にコンピューターの境界を越えたディスパッチを処理し、クライアントがローカルメソッドと同様に簡単にサーバー上のメソッドを呼び出すことができるようにします。また、その逆も可能です。 ハブ通信モデルを使用すると、.NET リモート処理などのリモート呼び出し Api を使用している開発者にとってなじみがあります。 ハブを使用すると、厳密に型指定されたパラメーターをメソッドに渡して、モデルバインドを有効にすることもできます。

アーキテクチャの図

次の図は、ハブ、永続的な接続、およびトランスポートに使用される基になるテクノロジの関係を示しています。

SignalR Architecture Diagram showing APIs, transports, and clients

ハブのしくみ

サーバー側のコードがクライアントでメソッドを呼び出すと、呼び出されるメソッドの名前とパラメーターを含むアクティブなトランスポート全体にパケットが送信されます (オブジェクトがメソッドパラメーターとして送信された場合は、JSON を使用してシリアル化されます)。 次に、クライアントは、メソッド名をクライアント側コードで定義されているメソッドと照合します。 一致するものがある場合は、逆シリアル化されたパラメーターデータを使用してクライアントメソッドが実行されます。

メソッドの呼び出しは、Fiddler などのツールを使用して監視でき ます。 次の図は、Fiddler の [ログ] ウィンドウで SignalR サーバーから web ブラウザークライアントに送信されるメソッド呼び出しを示しています。 メソッドの呼び出しは、という MoveShapeHub ハブから送信され、呼び出されるメソッドが呼び出さ updateShape れます。

View of Fiddler log showing SignalR traffic

この例では、パラメーターを使用 H してハブ名を識別します。メソッド名はパラメーターで識別 M され、メソッドに送信されるデータはパラメーターで A 識別されます。 このメッセージを生成したアプリケーションは、 高頻度のリアルタイム チュートリアルで作成されます。

通信モデルの選択

ほとんどのアプリケーションでは、ハブ API を使用する必要があります。 Connections API は、次のような状況で使用できます。

  • 実際に送信されるメッセージの形式を指定する必要があります。
  • 開発者は、リモート呼び出しモデルではなく、メッセージングとディスパッチモデルを使用することを推奨しています。
  • メッセージングモデルを使用する既存のアプリケーションは、SignalR を使用するように移植されています。