SignalR 入門Introduction to SignalR

提供者: Patrick Fletcherby Patrick Fletcher

Note

この記事では、ASP.NET SignalR を指します。This article refers to ASP.NET SignalR. SignalR を使用して、Java、Node.js、またはサーバーレス シナリオでは、リアルタイムのシナリオを有効にする方法と思う場合を見てASP.NET Core SignalRします。If you're thinking about using SignalR to enable real-time scenarios with Java, Node.js, or in a serverless scenario, take a look at ASP.NET Core SignalR. 既に ASP.NET SignalR を使用した場合を見て、のバージョンの違いバージョンの違いと ASP.NET Core SignalR での機能強化を理解するページ。If you've already used ASP.NET SignalR, take a look at the version differences page to understand the differences in the versions and the improvements in ASP.NET Core SignalR. 最後に、Microsoft Azure でリアルタイム アプリを実行することがわかっている場合を見て、 Azure SignalR サービスなど、アプリを必要とすると、クラウド ベースのスケール アウトを提供します。Finally, if you know you'll be running your real-time apps in Microsoft Azure, take a look at the Azure SignalR Service, as it provides cloud-based scale-out once your apps need it.

この記事では、SignalR は、いくつかのソリューションを作成するため、デザインされたについて説明します。This article describes what SignalR is, and some of the solutions it was designed to create.

意見やご質問Questions and comments

このチュートリアルの良い点に関するフィードバックや、ページ下部にあるコメントで改善できる点をお知らせください。Please leave feedback on how you liked this tutorial and what we could improve in the comments at the bottom of the page. チュートリアルに直接関係のない質問がある場合は、ASP.NET SignalR フォーラムまたはStackOverflow.comにて投稿してください。If you have questions that are not directly related to the tutorial, you can post them to the ASP.NET SignalR forum or StackOverflow.com.

SignalR とは何かWhat is SignalR?

ASP.NET SignalR は、リアルタイム Web 機能をアプリケーションに追加するプロセスを簡素化する ASP.NET 開発者向けのライブラリです。ASP.NET SignalR is a library for ASP.NET developers that simplifies the process of adding real-time web functionality to applications. リアルタイム Web 機能とは、サーバーがクライアントからの新しいデータ要求を待つのではなく、サーバー コードが接続クライアントに対して利用可能になったコンテンツを瞬時にプッシュできる機能です。Real-time web functionality is the ability to have server code push content to connected clients instantly as it becomes available, rather than having the server wait for a client to request new data.

SignalR は、ASP.NET アプリケーションに何らかの「リアルタイム」Web 機能を追加するために使用することができます。SignalR can be used to add any sort of "real-time" web functionality to your ASP.NET application. よくチャットが例として使用されますが、もっと多くのことを行うことができます。While chat is often used as an example, you can do a whole lot more. ユーザーが新しいデータを表示するために Web ページを更新したり、ページがロングポーリングを実装して新しいデータを取得したりする場合は、SignalR を使用することをおすすめします。Any time a user refreshes a web page to see new data, or the page implements long polling to retrieve new data, it is a candidate for using SignalR. サンプルとしては、ダッシュ ボード アプリケーションや監視アプリケーション、コラボレーション アプリケーション (ドキュメントの同時編集など)、ジョブの進行状況の更新プログラム、およびリアルタイム フォームが含まれます。Examples include dashboards and monitoring applications, collaborative applications (such as simultaneous editing of documents), job progress updates, and real-time forms.

SignalR はリアルタイム ゲームなど、サーバーから高頻度で更新を必要とするまったく新しいタイプの Web アプリケーションを有効にできます。SignalR also enables completely new types of web applications that require high frequency updates from the server, for example, real-time gaming.

SignalR は、サーバー側の .NET コードからクライアント ブラウザー (およびその他のクライアント プラットフォーム) に JavaScript 関数を呼び出す、サーバーからクライアントへのリモート プロシージャ コール (RPC) を作成するための単純な API を提供します。SignalR provides a simple API for creating server-to-client remote procedure calls (RPC) that call JavaScript functions in client browsers (and other client platforms) from server-side .NET code. SignalR には、接続管理 (イベントの接続や切断など) やグループ接続のための API も含まれます。SignalR also includes API for connection management (for instance, connect and disconnect events), and grouping connections.

SignalR によるメソッドの呼び出し

SignalR では、自動的に接続管理を処理し、チャット ルームのように、接続されているすべてのクライアントへのメッセージを同時に配信できます。SignalR handles connection management automatically, and lets you broadcast messages to all connected clients simultaneously, like a chat room. 特定のクライアントにメッセージを送信することもできます。You can also send messages to specific clients. クライアントとサーバー間の接続は、通信ごとに再確立される従来の HTTP 接続とは異なり永続的です。The connection between the client and server is persistent, unlike a classic HTTP connection, which is re-established for each communication.

SignalR は「サーバー プッシュ」機能をサポートしています。この機能では、現在 Web において一般的な要求 - 応答モデルではなく、リモート プロシージャ コール (RPC) を使用して、サーバー コードによってブラウザー内のクライアント コードを呼び出すことができます。SignalR supports "server push" functionality, in which server code can call out to client code in the browser using Remote Procedure Calls (RPC), rather than the request-response model common on the web today.

SignalR アプリケーションは、Service Bus、SQL Server または Redis を使用して何千ものクライアントにスケール アウトできます。SignalR applications can scale out to thousands of clients using Service Bus, SQL Server or Redis.

SignalR はオープンソースで、GitHub を通してアクセスできます。SignalR is open-source, accessible through GitHub.

SignalR と WebSocketSignalR and WebSocket

SignalR では、使用可能な場合は新しい WebSocket トランスポートを使用し、必要に応じて、古いトランスポートにフォールバックします。SignalR uses the new WebSocket transport where available and falls back to older transports where necessary. WebSocket を直接使用してアプリを作成することはできますが、SignalR を使用するメリットは、実装する必要のある他の機能の多くが既に作成されているという点です。While you could certainly write your app using WebSocket directly, using SignalR means that a lot of the extra functionality you would need to implement is already done for you. これにより、最も重要な事ととして、古いクライアントのために個別のコード パスを作成することなく、WebSocket を活用できるようにアプリをコーディングすることができます。Most importantly, this means that you can code your app to take advantage of WebSocket without having to worry about creating a separate code path for older clients. SignalR は基本トランスポートの変更をサポートするために更新され、異なるバージョンの WebSocket でもアプリケーションにおいて一貫したインターフェイスが提供されるため、SignalR は WebSocket の更新に関する心配からユーザーを解放します。SignalR also shields you from having to worry about updates to WebSocket, since SignalR is updated to support changes in the underlying transport, providing your application a consistent interface across versions of WebSocket.

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

SignalR は、クライアントとサーバー間のリアルタイムの作業を行うために必要なトランスポートの一部を抽象化したものです。SignalR is an abstraction over some of the transports that are required to do real-time work between client and server. SignalR 接続は HTTP として起動し、WebSocket 接続が可能な場合は WebSocket 接続となります。A SignalR connection starts as HTTP, and is then promoted to a WebSocket connection if it is available. サーバーのメモリを最も効率的な使用によりが最も低い待機時間、および、(など、完全な双方向クライアントとサーバー間通信)、最も基本的な機能がいますが、最も厳格なので、WebSocket は、SignalR の理想的なトランスポート要件:WebSocket は、Windows Server 2012 または Windows 8、および .NET Framework 4.5 を使用するサーバーが必要です。WebSocket is the ideal transport for SignalR, since it makes the most efficient use of server memory, has the lowest latency, and has the most underlying features (such as full duplex communication between client and server), but it also has the most stringent requirements: WebSocket requires the server to be using Windows Server 2012 or Windows 8, and .NET Framework 4.5. これらの要件が満たされない場合、SignalR は、接続するために他のトランスポートの使用を試みます。If these requirements are not met, SignalR will attempt to use other transports to make its connections.

HTML 5 トランスポートHTML 5 transports

これらのトランスポートは HTML 5 のサポートに依存します。These transports depend on support for HTML 5. クライアントのブラウザーが HTML 5 の標準をサポートしていない場合は、古いトランスポートが使用されます。If the client browser does not support the HTML 5 standard, older transports will be used.

  • WebSocket (サーバーとブラウザーの両方が Websocket をサポートすることを示す場合):WebSocket (if the both the server and browser indicate they can support Websocket). WebSocket は、クライアントとサーバー間の通信における真に永続的な双方向接続を確立するためのトランスポートです。WebSocket is the only transport that establishes a true persistent, two-way connection between client and server. ただし、WebSocket には細かい要件もあります。WebSocket は Microsoft Internet Explorer、Google Chrome、Mozilla Firefox の最新のバージョンでのみ完全にサポートされ、Opera や Safari などの他のブラウザーでは部分的にしか実装されません。However, WebSocket also has the most stringent requirements; it is fully supported only in the latest versions of Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox, and only has a partial implementation in other browsers such as Opera and Safari.
  • サーバー送信イベントEventSource (ブラウザーがサポートする場合は Internet Explorer を除くすべてのブラウザーでは基本的にサーバー送信イベント、.) とも呼ばれますServer Sent Events, also known as EventSource (if the browser supports Server Sent Events, which is basically all browsers except Internet Explorer.)

Comet トランスポートComet transports

以下のトランスポートは、ブラウザーまたは他のクライアントが長期保持 HTTP リクエストを管理する Comet Web アプリケーションのモデルに基づいています。これは、クライアントからの特別な要求をすることなくサーバーからクライアントへデータをプッシュすることができます。The following transports are based on the Comet web application model, in which a browser or other client maintains a long-held HTTP request, which the server can use to push data to the client without the client specifically requesting it.

  • Forever Frame (Internet Explorer の場合のみ):Forever Frame (for Internet Explorer only). Forever Frame は、サーバー上のエンドポイントへの要求が完了しない非表示の IFrame を作成します。Forever Frame creates a hidden IFrame which makes a request to an endpoint on the server that does not complete. サーバーは、すぐに実行されるスクリプトを継続的にクライアントに送信し、サーバーからクライアントへの一方向のリアルタイム接続を提供します。The server then continually sends script to the client which is immediately executed, providing a one-way realtime connection from server to client. クライアントからサーバーへの接続は、サーバーからクライアントとは異なる接続を使用し、標準の HTTP 要求のように、送信する必要のあるデータがあるたびに新しい接続が作成されます。The connection from client to server uses a separate connection from the server to client connection, and like a standard HTTP request, a new connection is created for each piece of data that needs to be sent.
  • Ajax long polling:Ajax long polling. Long Polling では永続的な接続は作成されませんが、サーバーが応答を完了するまで開いたままの要求でサーバーをポーリングします。接続が閉じられたら即座に新しい接続が要求されます。Long polling does not create a persistent connection, but instead polls the server with a request that stays open until the server responds, at which point the connection closes, and a new connection is requested immediately. 接続のリセット中に、いくつかの待機時間があります。This may introduce some latency while the connection resets.

どの構成でどのようなトランスポートがサポートされているかについての詳細は、サポートされているプラットフォームを参照してください。For more information on what transports are supported under which configurations, see Supported Platforms.

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

SignalR が使用するトランスポートを決定する手順を以下に示します。The following list shows the steps that SignalR uses to decide which transport to use.

  1. ブラウザーが Internet Explorer 8 またはそれ以前の場合は、Long Polling が使用されます。If the browser is Internet Explorer 8 or earlier, Long Polling is used.

  2. JSONP が設定されている場合 (つまり、接続が開始されると jsonpパラメーターが trueに設定される)、Long Polling が使用されます。If JSONP is configured (that is, the jsonp parameter is set to true when the connection is started), Long Polling is used.

  3. クロス ドメイン接続が確立されている場合 (つまり、SignalR エンドポイントが、ホスティング ページと同じドメインにない)、次の条件が満たされた場合に WebSocket が使用されます。If a cross-domain connection is being made (that is, if the SignalR endpoint is not in the same domain as the hosting page), then WebSocket will be used if the following criteria are met:

    • クライアントが CORS (クロス オリジン リソース共有) をサポートしている。The client supports CORS (Cross-Origin Resource Sharing). CORS をサポートしているクライアントの詳細については、caniuse.com での CORS を参照してください。For details on which clients support CORS, see CORS at caniuse.com.

    • クライアントが WebSocket をサポートしている。The client supports WebSocket

    • サーバーが WebSocket をサポートしている。The server supports WebSocket

      これらの条件のいずれかが満たされていない場合は、Long Polling が使用されます。If any of these criteria are not met, Long Polling will be used. ドメイン間の接続の詳細については、「ドメイン間の接続を確立する方法」を参照してください。For more information on cross-domain connections, see How to establish a cross-domain connection.

  4. JSONP が設定されておらず、ドメイン間接続でない場合は WebSocket が使用されます (クライアントとサーバーの両方がサポートしている場合)。If JSONP is not configured and the connection is not cross-domain, WebSocket will be used if both the client and server support it.

  5. クライアントまたはサーバーのいずれかが WebSocket をサポートしていない場合は Server Sent Events が使用されます (利用可能に場合)。If either the client or server do not support WebSocket, Server Sent Events is used if it is available.

  6. クライアントまたはサーバーのいずれかが WebSocket をサポートしていない場合は Server Sent Events が使用されます (利用可能に場合)。If Server Sent Events is not available, Forever Frame is attempted.

  7. Server Sent Events が使用できない場合は、Forever Frame が試されます。If Forever Frame fails, Long Polling is used.

Forever Frame が失敗すると、Long Polling が使用されます。Monitoring transports

ハブでログを有効にし、ブラウザーでコンソール ウィンドウを開くことによって、アプリケーションで使用されているトランスポートを特定できます。You can determine what transport your application is using by enabling logging on your hub, and opening the console window in your browser.

ブラウザーで、ハブのイベントのログ記録を有効にするには、クライアント アプリケーションに、次のコマンドを追加します。To enable logging for your hub's events in a browser, add the following command to your client application:

$.connection.hub.logging = true;

  • Internet Explorer で、F12 キーを押して開発者ツールを開き、[コンソール] タブをクリックします。In Internet Explorer, open the developer tools by pressing F12, and click the Console tab.

    Microsoft Internet Explorer でコンソール

  • Chrome では、Ctrl + Shift + J キーを押して、コンソールを開きます。In Chrome, open the console by pressing Ctrl+Shift+J.

    Google Chrome でコンソール

コンソールが開いた状態で、ログが有効な場合は、SignalR で利用されているトランスポートを確認することができます。With the console open and logging enabled, you'll be able to see which transport is being used by SignalR.

Internet explorer が WebSocket トランスポートを示すコンソールします。

トランスポートの指定Specifying a transport

トランスポートのネゴシエートには一定の時間を要し、クライアントとサーバーの一定量のリソースを使用します。Negotiating a transport takes a certain amount of time and client/server resources. クライアントの機能が分かっている場合は、クライアント接続が開始された時点でトランスポートを指定することができます。If the client capabilities are known, then a transport can be specified when the client connection is started. 次のコード スニペットでは、クラインが他のプロトコルをサポートしていないことが分かっている場合にも使用される、Ajax Long Polling のトランスポートを使用して接続を開始する方法を示しています。The following code snippet demonstrates starting a connection using the Ajax Long Polling transport, as would be used if it was known that the client did not support any other protocol:

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

クライアントが特定のトランスポートを順番に試行するようにする場合は、フォールバック順序を指定できます。You can specify a fallback order if you want a client to try specific transports in order. 次のコード スニペットは、WebSocket を試し、失敗した場合、Long Polling に直接移行する例を示します。The following code snippet demonstrates trying WebSocket, and failing that, going directly to Long Polling.

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

トランスポートを指定する文字列定数の定義は次のとおりです。The string constants for specifying transports are defined as follows:

  • webSockets
  • foreverFrame
  • serverSentEvents
  • longPolling

接続とハブConnections and Hubs

SignalR の API には、クライアントとサーバー間の通信に 2 つのモデルが含まれています。永続的な接続とハブ。The SignalR API contains two models for communicating between clients and servers: Persistent Connections and Hubs.

接続は、単一受信者メッセージ、グループ化メッセージ、またはブロードキャスト メッセージを送信するための単純なエンドポイントを表します。A Connection represents a simple endpoint for sending single-recipient, grouped, or broadcast messages. 固定接続 API (PersistentConnection クラスによって .NET コードで表される) は、SignalR が公開している低レベルの通信プロトコルへの直接アクセスを開発者に提供します。The Persistent Connection API (represented in .NET code by the PersistentConnection class) gives the developer direct access to the low-level communication protocol that SignalR exposes. 接続の通信モデルは、Windows Communication Foundation などの接続に基づく API を使用したことのある開発者にとって使いやすいものです。Using the Connections communication model will be familiar to developers who have used connection-based APIs such as Windows Communication Foundation.

ハブは、クライアントとサーバーが相互に直接メソッドを呼び出すことができるようにする接続 API に基づいて構築されたより高度なパイプラインです。A Hub is a more high-level pipeline built upon the Connection API that allows your client and server to call methods on each other directly. SignalR は、マシンの境界でのディスパッチを魔法のように行い、クライアントがローカルのメソッドのように簡単にサーバーでメソッドを呼び出せるようにします (またはその逆)。SignalR handles the dispatching across machine boundaries as if by magic, allowing clients to call methods on the server as easily as local methods, and vice versa. ハブ通信モデルは、.NET Remoting などのリモート呼び出し API を使用したことのある開発者にとって使いやすいものです。Using the Hubs communication model will be familiar to developers who have used remote invocation APIs such as .NET Remoting. また、ハブを使用すると、厳密に型指定されたパラメーターをメソッドに渡すことができ、モデルのバインディングが可能になります。Using a Hub also allows you to pass strongly typed parameters to methods, enabling model binding.

アーキテクチャ図Architecture diagram

次の図は、ハブ、永続的な接続、およびトランスポートに使用される基になるテクノロジ間の関係を示します。The following diagram shows the relationship between Hubs, Persistent Connections, and the underlying technologies used for transports.

Api、トランスポート、およびクライアントを示す、SignalR のアーキテクチャ図

ハブのしくみHow Hubs work

サーバー側コードでは、クライアントでメソッドを呼び出すと、呼び出されるメソッドの名前とパラメーターを含むパケットがアクティブなトランスポート経由で送信されます (オブジェクトがメソッド パラメーターとして送信される場合、JSON を使用してシリアル化されます)。When server-side code calls a method on the client, a packet is sent across the active transport that contains the name and parameters of the method to be called (when an object is sent as a method parameter, it is serialized using JSON). 次にクライアントは、メソッド名をクライアント側のコードで定義されているメソッドと一致させます。The client then matches the method name to methods defined in client-side code. 一致がある場合、逆シリアル化されたパラメーターのデータを使用してクライアント メソッドが実行されます。If there is a match, the client method will be executed using the deserialized parameter data.

メソッドは、Fiddler などのツールを使用して監視することができます。The method call can be monitored using tools like Fiddler. 次のイメージは、Fiddler の [ログ] ウィンドウで、SignalR サーバーから Web ブラウザー クライアントに送信されたメソッドの呼び出しを示します。The following image shows a method call sent from a SignalR server to a web browser client in the Logs pane of Fiddler. メソッドの呼び出しは、MoveShapeHub というハブから送信され、呼び出されるメソッドは updateShapeと呼ばれます。The method call is being sent from a hub called MoveShapeHub, and the method being invoked is called updateShape.

SignalR のトラフィックを示す Fiddler ログの表示

この例では、ハブ名はHパラメーターで識別されます。メソッド名は、Mパラメーターで識別され、メソッドに送信されるデータはAパラメーターで識別されます。In this example, the hub name is identified with the H parameter; the method name is identified with the M parameter, and the data being sent to the method is identified with the A parameter. このメッセージを生成したアプリケーションは、高頻度リアルタイム メッセージングチュートリアルで作成されます。The application that generated this message is created in the High-Frequency Realtime tutorial.

通信モデルの選択Choosing a communication model

ほとんどのアプリケーションでは、ハブ API を使用する必要があります。Most applications should use the Hubs API. 接続 API は次の状況で使用できます。The Connections API could be used in the following circumstances:

  • 実際の送信メッセージの形式を指定する必要があるThe format of the actual message sent needs to be specified.
  • 開発者が、リモート呼び出しモデルではなく、メッセージおよびディスパッチ モデルを利用する事を推奨しているThe developer prefers to work with a messaging and dispatching model rather than a remote invocation model.
  • メッセージングモデルを使用する既存のアプリケーションが SignalR を使用するように移植されているAn existing application that uses a messaging model is being ported to use SignalR.