一般的なWebアプリケーションの場合、ほとんどの開発者は見知らぬ人ではありません。 Webアプリケーションでは、ブラウザとサーバーの間でリクエスト/応答のインタラクティブモードが使用されます。ブラウザはリクエストを発行し、サーバーはリクエストに従って対応する応答を生成します。ブラウザは、ユーザーへの受信応答に処理されます。応答形式は、HTML、XML、またはJSONです。 RESTアーキテクチャスタイルとAJAXの人気により、サーバーはJSONを応答データ形式としてさらに使用します。 Webアプリケーションは、XMLHTTPREQUESTオブジェクトを使用してリクエストを送信し、サーバーが返したデータに従ってページのコンテンツを動的に更新します。一般的に、マウスのクリックや移動など、ページ上のユーザーの操作は、対応するイベントをトリガーします。 XMLHTTPREQUESTオブジェクトによってリクエストが発行され、サーバーが応答した後にページにローカルアップデートがあります。この方法の欠陥は、サーバーによって生成されたデータに時間内にブラウザの通知を通知できないことですが、次のリクエストが送信されるまでブラウザで取得する必要があります。高いデータ要件を持つ一部のアプリケーションでは、この遅延は受け入れられません。このようなアプリケーションのニーズを満たすために、サーバー側のデータ変更を初めてユーザーに通知できるように、サーバーからブラウザにデータをプッシュする方法が必要です。多くの一般的なソリューションがあり、2つのカテゴリに分けることができます。これら2つの方法の違いは、HTTPプロトコルに基づいているかどうかです。 HTTPプロトコルを使用しない慣行は、HTML 5の新しいWebSocket仕様を使用することであり、HTTPプロトコルを使用する方法には、この記事で説明されているHTML 5サーバープッシュイベントが含まれます。これらのテクノロジーを以下に紹介します。
簡単な紹介HTML 5サーバープッシュイベントを導入する前に、最初に上記のサーバー側のデータプッシュテクノロジーの数を導入します。 1つ目はWebSocketです。 WebSocket仕様はHTML 5の重要な部分です。多くの主流のブラウザーによってサポートされており、WebSocketに基づいて開発された多くのアプリケーションがサポートされています。名前が表現されているように、WebSocketはTCPプロトコルに基づいてジャケット接続を使用します。 WebSocketを使用した後、実際にサーバーとブラウザの間に一連のワード接続を構築し、2つのウェイデータで送信できます。 WebSocketの機能は非常に強力であり、使用が柔軟であり、さまざまなシナリオに適しています。ただし、WebSocketテクノロジーも比較的複雑です。これには、サーバーとブラウザ側の実装が通常のWebアプリケーションとは異なります。
WebSocketを除き、他の実装方法は、実際のプッシュの効果を達成するためのHTTPプロトコルに基づいています。最初の方法は単純な回転です。つまり、ブラウザは時々サーバーにリクエストを送信して、データの更新があるかどうかを尋ねます。このアプローチは比較的単純であり、問題をある程度解決できます。ただし、回転の時間間隔を慎重に考慮してください。回転間の間隔が長すぎると、ユーザーは時間内に更新されたデータを受信しません。
Comet Technologyは、長いホイールの問い合わせを使用して、単純な回転の欠点を改善しました。長い回転の各リクエストでは、サーバーは、応答が完了した直後に閉じるのではなく、一定期間開いた期間に接続を維持します。これの利点は、接続が開かれた期間内に、サーバーによって生成されたデータの更新を時間内にブラウザに返すことができることです。長い接続が閉じられると、ブラウザはすぐに新しい長い接続を開き、リクエストを継続します。ただし、Cometテクノロジーの実装には、サーバーとブラウザ側の3番目のパーティライブラリのサポートが必要です。要約すると、上記の4つの異なる技術は、その欠陥のために使用することをお勧めしません。 Comet Technologyは、HTML 5標準の一部ではありません。 WebSocketの仕様とサーバープッシュテクノロジーは、HTML 5標準の一部であり、主流のブラウザでネイティブサポートを提供します。ただし、WebSocketの仕様はより複雑で、複雑で2つのデータ通信が必要なシーンに適しています。シンプルなサーバーデータプッシュシナリオの場合、サーバープッシュイベントを使用するだけで十分です。
ブラウザのサポートに関しては、IEを除くほとんどのデスクトップとモバイルブラウザーでサーバープッシュイベントがサポートされています。サポートサーバープッシュイベントのブラウザとバージョンには、Firefox 6.0+、Chrome 6.0+、Safari 5.0+、Opera 11.0+、iOS Safari 4.0+、Opera Mobile 11.1+、Android 25.0+のクロム、Andr Andr Oid 19.0のFirefoxが含まれます。 +およびBlackBerryブラウザ7.0+ et al。 IEのサポートには、次の章で詳細な紹介があります。
サーバープッシュイベント仕様の次の仕様が指定されています。
仕様サーバーセントイベントの仕様は、HTML 5仕様の不可欠な部分です。参照リソースを参照してください。この仕様は比較的単純で、主に2つの部分で構成されています。最初の部分は、サーバーとブラウザ側の間の通信プロトコルであり、2番目の部分はブラウザがJavaScriptを使用するために使用するEventSourceオブジェクトです。通信プロトコルは、純粋なテキストに基づいた単純なプロトコルです。サーバー上の応答の内容は、テキスト/イベントストリームです。応答テキストの内容は、異なるイベントで構成されるイベントフローと見なすことができます。各イベントは、タイプとデータの2つの部分で構成されており、各イベントにはオプションの識別子があります。さまざまなイベントの内容は、車と王室のシンボルのみを含む空の線（/r/n）によって分離されます。各イベントのデータは、複数の行で構成されている場合があります。コードリスト1は、サーバー側の応答の例を示しています。
サーバー側の応答の例データ：First EventData：Second EventID：100Event：MyEventData：3番目のEventID：101：これはコメントです：Fouteh EventData：Fours Event Continue
リスト1に示すように、各イベントは空の行で区切られています。各線について、コロン（:)は前の線のタイプであり、コロンの背後にある対応する値です。可能なタイプは次のとおりです。
上記のコードでは、2番目のイベントの識別子は100個のイベントを生成しますイベントはFoursイベント/nfounth eovent継続です。複数のデータがある場合、実際のデータは、行の変更のためにデータによって接続されます。
サーバーによって返されたデータにイベントの識別子が含まれている場合、ブラウザは最近受信したイベントの識別子を記録します。サーバーへの接続が中断されている場合、ブラウザの端が再び接続されている場合、イベントがHTTP Head-Event-IDによって最後に取得されるときのロゴ。サーバーは、ブラウザ側から送信されたイベント識別子によって決定して、どのイベントが接続を継続し始めるかを判断できます。
サーバー側によって返される応答の場合、ブラウザ側は処理のためにJavaScriptのEventSourceオブジェクトを使用する必要があります。 EventSourceは、対応するイベント処理方法をオブジェクトに追加するだけで標準のイベント監視方法を使用します。 Eventsourceは、表1に示すように、3つの標準イベントを提供します。
表1。Eventsourceオブジェクトが提供する標準イベント| 名前 | 説明します | イベント処理方法 |
| 開ける | サーバーとの接続が正常に確立されたとき | オープン |
| メッセージ | サーバーから送信されたイベント | オンメサージ |
| エラー | エラーが発生したとき | onerror |
前述のように、サーバーはカスタムタイプのイベントを返すことができます。これらのイベントでは、AddEventListenerメソッドを使用して、対応するイベント処理方法を追加できます。コードリスト2は、Eventsourceオブジェクトの例を示しています。
EventSourceオブジェクトの例var es = new eventsource（ 'events'）;データ）;}）;
上に示すように、eventSourceオブジェクトを特に作成した後、イベント処理方法は、オンメサージおよびAddEventListenerメソッドを介して追加できます。サーバーに新しいイベントがある場合、対応するイベント処理方法が呼び出されます。 EventSourceオブジェクトの対立プロパティの役割は、AddEventListener（「メッセージ」）の役割と類似していますが、Onmessage属性は1つのイベント処理方法のみをサポートします。サーバープッシュイベントの仕様コンテンツを導入した後、サーバーの実装を以下に紹介します。
サーバーとブラウザの終了実装前のセクションの通信プロトコルの説明から、サーバープッシュイベントがより単純なプロトコルであることがわかります。サーバー側の実装は比較的簡単です。オープンソースコミュニティには、さまざまなサーバー側のテクノロジーが見つかります。開発することは難しくありません。この記事では、Javaをサーバーの実装言語として使用しています。対応して、オープンソースベースのイベントスルースサービスプロジェクトを実装して、参照リソースを参照してください。以下は、Jetty-Eventsource-Servletプロジェクトの使用方法を説明する具体的な例です。この例は、限られた空間内のオブジェクトのランダムな動きをシミュレートするために使用されます。オブジェクトはランダムな位置から始まり、上部、下、左、および正しい方向から一方向をランダムに選択し、この方向にランダムな距離を移動します。サーバーは、オブジェクトの位置を常に変更し、ブラウザによって表示されるブラウザに位置情報をプッシュしています。
サーバーの実装服务器端的实现由两部分组成：org.eclipse.jetty.servlets.eventsource接口的实现、另一部分是作为浏览器访问端点的继承自org.eclipse.jetty.servlets.eventsourceservlet类的サーブレットの実装。次のコードは、Eventsourceインターフェイスの実装クラスを提供します。
EventSourceインターフェイス実装クラスMovementEventsource
Public ClassEventsourceは、プライベートint height = 600 = 5; logger .getlogger（）。getname（））; .nextint（width）; （lasteventid）; .split（、）; pos [1]、10）;} catch（numberformatexception e）{} if（isvalidmove（xpos、ypos））{x = xpos;情報.data（id）場所に従って。 、e）;}} emitter.close（）; move = xnext = x + ynext = y +現在の移動位置が合法かどうかを判断します。 xdir = new int}; ）};}}MovementEventSourceは、Onopen、OncloseメソッドをOnopenメソッドを実装する必要があります。 OnopenメソッドとOnresumeメソッドの両方に、eventsource.emitterインターフェイスのパラメーターがあり、データの送信に使用できます。 eventsource.emitterインターフェイスに含まれる方法には、それぞれ通信プロトコル内のさまざまなタイプのイベントに対応するデータ、イベント、コメント、ID、およびクローズが含まれます。 OnResumeメソッドには、LastEventidの追加パラメーターも含まれており、Last-Id-IDヘッダーが送信した最新のイベントの識別子を示しています。
MovementEventSourceクラスでイベントで生成されたイベントの主なロジックは、クエリメソッドです。このメソッドには、2秒ごとに位置を変更する無制限のサイクルが含まれており、同時に、eventsource.emitterインターフェイスのデータメソッドを介して更新位置のデータメソッドを介して更新された位置をブラウザエンドに送信します。各イベントには対応する識別子があり、識別子の値は位置自体です。接続が切断された後にブラウザが再接続されている場合、オブジェクトは最後の位置から移動できます。
MovementEventsourceクラスに対応するサービスのサービスを実装するのは簡単です。 NewEventsourceメソッドの実装では、以下に示すように、MovementEventSourceクラスを返す必要があります。ブラウザが確立されるたびに、サービスはリクエストを処理するために新しいMovementEventSourceクラスのオブジェクトを作成します。
MovementsErvletのサーブレット実装Public Class Movementservlet ExtendSarcesOrceservlet {@Override Protected Eventsource NewsSource（httpservletrequest、string clientId）return new MovementEventsource（800、600、20）;}}}サーバーの実装では、対応するサーバーフィルターサポートを追加する必要があることに注意する必要があります。これは、Jetty-Eventsource-Servletプロジェクトが依存しているJetty Continuationsフレームワークの要件であり、そうでなければこの場合にエラーが発生します。フィルターを追加する方法は、Web.xmlファイルに以下に示すように、構成コンテンツを追加することです。
Jetty Continuationsに必要なサービスフィルターの構成<filter> <filter-name> continuation </filter-name> <filter-class> org.eclipse.jetty.continuation.continuationfilter </filter-class> </filter> <filter-ma pping> <filter-name>継続</filter-name> <url-pattern>/sse/*</url-pattern> </filter-mapping>ブラウザの終了実装
ブラウザ側の実装は比較的簡単です。次のコードは、対応する実装を提供します。ページ上の正方形を使用してオブジェクトを表します。新しいイベントが受信されると、イベントデータに記載されている座標情報に従って、ブロックの位置がページ上にあります。
ブラウザ側の実装コードvar es = new eventsource（ 'SSE/movement'）; es.addeventlistener（ 'message'、function（e）{var pos = e.data.split（ '、'）、x = pos [0]、y = pos [1];基本的なサーバー側とブラウザのエンディングを導入した後、より重要なIEサポートを以下に紹介します。
つまり、サポートブラウザのネイティブEventsourceオブジェクトを使用する大きな問題は、IEがサポートを提供しないことです。 IEで同じサポートを提供するために、通常、2つの方法があります。最初の方法は、他のブラウザで元のEventSourceオブジェクトを使用しながら、IEで単純な回転または彗星テクノロジーを使用することです。 。この記事では、PolyFillテクノロジーを使用して、ページに3番目のパーティJavaScriptライブラリをロードするだけです。ブラウザサイドコードを適用すると、変更する必要はありません。通常、2番目の方法を使用することをお勧めします。このようにして、サーバー側に必要な実装テクノロジーは1つだけです。
IEで同様のプライマリイベントソースオブジェクトを提供することは容易ではありません。理論的には、サーバー側の応答コンテンツを取得するにはxmlhttprequestオブジェクトのみが必要であり、テキスト分析により、対応するイベントを抽出し、対応するイベント処理方法をトリガーできます。問題は、IEのxmlhttprequestオブジェクトが取得部の応答コンテンツをサポートしていないことです。応答が完了した後にのみ、取得できます。サーバープッシュイベントが長い接続を使用しているためです。接続が常に開いている場合、対応するイベントをxmlhttprequestオブジェクトを介してトリガーすることはできず、対応するイベントをトリガーできません。より具体的には、xmlhttprequestオブジェクトのReadyStateが3（ReadyState_Interactive）の場合、その応答属性を取得できません。
IEでxmlhttpRequestオブジェクトの問題を解決するには、IE 8で導入されたxDomainRequestオブジェクトを使用する必要があります。 XdomainRequestオブジェクトの役割は、Cross -Domain Ajaxリクエストを送信することです。 XdomainRequestオブジェクトは、OnProgressイベントを提供します。 OnProgressイベントが発生すると、ResponseTextプロパティを介して応答のコンテンツを取得できます。これは、XMORIANREQUESTオブジェクトとXMLHTTPRequestオブジェクトの最大の違いでもあります。 XdomainRequestオブジェクトを使用して、サーバー側への接続を開くと、サーバー上で新しいデータが生成されると、XdomainRequestオブジェクトのオンプログレスイベントによって処理できます。
ただし、XdomainRequestオブジェクトの元の目的により、Cross -Domainアクセスのセキュリティ問題を考慮して、XdomainRequestオブジェクトの制限も厳密です。これらの制限は、Eventsourceオブジェクトとしての実装に影響します。特定の制限とソリューションを以下に示します。
XdomainRequestオブジェクトのこれらの制限により、サーバーの実装も対応する変更を行う必要があります。これらの変更には、リクエストに含まれるユーザー認証に関連するテキスト/プレーンタイプのパラメーターを分析するアクセスコントロールオリジンヘッドが含まれます。
この記事で使用されているPolyFillライブラリは、GitHubのYaffleによって開発されたEventSourceプロジェクトです。参照リソースを参照してください。 PolyFillライブラリを使用し、サーバー側の実装を変更した後、サーバーを使用してブラウザIE 8以降でイベントをプッシュできます。 IE 7をサポートする必要がある場合は、簡単な問い合わせまたは彗星テクノロジーのみを使用できます。この記事の例コードの参照リソースを参照してください。
まとめデータをサーバーからブラウザにプッシュする必要がある場合、HTML 5仕様標準に基づいて使用できるテクノロジーには、WebSocketおよびサーバープッシュイベントが含まれます。開発者は、アプリケーションの特定のニーズに応じて適切なテクノロジーを選択できます。サーバーからデータをプッシュする必要がある場合、サーバープッシュイベントの標準はよりシンプルで簡単に達成できます。この記事では、サーバープッシュイベントの標準コンテンツ、サーバーとブラウザ側の実装を詳細に導入し、IEブラウザーのサポート方法も分析しました。