HTML 5サーバがメッセージをプッシュする様々な解決策

10694 ワード

サマリ
様々なBSアーキテクチャのアプリケーションでは、メール、メッセージ、待機事項などの通知に類似するように、サービス側がクライアントに積極的に様々なメッセージを送信することを望んでいることが多い.
BSアーキテクチャ自体に問題があるのは,サーバが常に一問一答のメカニズムを採用していることである.これは、クライアントがサーバにメッセージをアクティブに送信しないと、サーバがクライアントにメッセージをプッシュする方法を知ることができないことを意味する.
HTML、ブラウザなどの各技術、標準の発展に伴い、AJAX、Conet、Server Sent、WebSocketというサービス側のアクティブなプッシュメッセージを実現するための異なる手段と方法が順次生成された.
本稿では,上述した種々の技術的手段を直白化して説明する.
AJAX
通常のページは、ブラウザで次のように動作します.

ユーザは、ブラウザにアクセスする必要があるアドレス

を与える.

ブラウザは、このアドレスに基づいてサーバにアクセスする、サーバとの間にTCP接続(HTTP要求)

を作成する.

サーバはこのアドレスといくつかの他のデータに基づいてHTMLテキストを構築し、TCP接続に書き込み、接続

を閉じる.

ブラウザはサーバからのHTMLテキストを取得し、ブラウザ上でユーザーに

をブラウズするように解析して提示する.
このとき、ユーザは、ウェブサイト上のいずれかのまたはいずれかをトリガー送信時:をクリックした.

ブラウザは、formのパラメータまたはaのパラメータに基づいて、アクセスアドレス

として機能する.

サーバとTCP接続

を作成する.

サーバはHTMLテキストを作成し、接続

を閉じます.

ブラウザは現在表示されているページを破壊し、新しいHTMLテキストに従って新しいページをユーザー

に提示する.
プロセス全体が接続されると、ページが維持されないことがわかります.全体の過程は少し強引に売っているように見えますが、私は新しいコーラを1杯しか持っていないかもしれませんが、セット全体をください.
このとき、XmlHttpRequestコンポーネントを理解することができます.このコンポーネントは、HTTPリクエストを手動で作成し、必要なデータを送信することができます.サーバは、サーバの応答を受信したときに、元のページが破壊されないことが最大のメリットです.これは、私が「コーヒーを飲み終わったら、お代わりします」と叫んだ後、従業員が私の食べていないセットを全部捨てるのではなく、コーヒーを持ってきたようなものです.
AJAXを利用してサーバプッシュを実現すると、実質的にクライアントが「私にくれたメッセージはありますか?」とサーバに尋ね続け、そして、サーバが「ある」または「ない」と答えて達成した実装効果.その実現方法も簡単で、jQueryフレームワークでカプセル化されたAJAX呼び出しも便利です.

function getMessage(fn) {
    $.ajax({
        url: "Handler.ashx", //           
        dataType: "text",    //    ，   JSON，XML     
        type: "get",         //HTTP    ，    post
        success: function (d, s) {
            fn(d);           //         ，          
        },
        complete: function (x, s) {
            setTimeout(function () {
                getMessage(fn);
            }, 5000);       //         ，             
        }
    });
}

上記のコードでは、5秒おきにサーバに処理するメッセージがあるかどうかを尋ねることができます.これにより、プッシュの効果が得られますが、問題があります.

間隔が速いほど、プッシュのタイムリー性が高くなり、サーバの消費が大きくなります.

間隔が遅いほど、プッシュのタイムリー性が低くなり、サーバの消費が小さくなります.

また厳密には,このような実際の方式は,真の意味でのサーバが自発的にメッセージをプッシュするわけではないが,初期の技術的手段が不足していたため,AJAXループは普遍的な手段となった.

Comet
HTTPリクエストがTCP接続に基づいて実装されていることを知っています.前に述べたHTTPリクエスト処理手順を見てみましょう.

クライアントとサーバはTCP接続

を確立する.

サーバは、クライアントから送信メッセージ処理に基づいてHTMLテキスト

を生成する.

HTMLをHTTPプロトコルメッセージとして閉じてクライアント

に返す.

リンクを閉じます.

この処理過程を見ると、4ステップ目の接続を閉じることを省くと、長い接続が維持されているのではないかと連想するのは難しくありません.サービス側のいくつかの操作により、このTCP接続からクライアントにデータを直接送信することができます.
このテクノロジーにより、サーバプッシュのリアルタイム性を大幅に向上させ、サービス側が接続を継続的に確立し、適用するコストを削減することができます.
現在、市場にはAJAXに基づいて実現されたCometメカニズムがたくさんありますが、主に2つの方法があります.

接続が確立された後も「問い合わせ」+「応答」のモードが使用される.働き方は変わっていませんが、施放との接続が確立されるたびの作業を減らしたため、性能がかなり向上しました.また,サーバはTCP接続に対してコンテキストの定義を持つことができ,従来のAJAXとは全く無状態ではない.

は、Streamへの書き込み実装サーバを介してクライアントにデータをプロアクティブに送信する.TCP接続なので、サーバーのプログラミングを通じて、サービス側からクライアントにデータを積極的に送信することができ、モードから本当にプッシュの概念を確立しました.

Server-Sent
Server-SentはHTML 5の標準であり、Cometの考え方を延長し、いくつかの規範化を行っています.Conetという技術を従来の分岐派生技術から正統な公式基準に変えた.
その原理はCometと同じで、クライアントによってサーバーとの間にTCP接続を作成して、それからこの接続を維持して、クライアントあるいはサーバーの中でいかなる1放断をして、サーバーSentは“質問”+“答え”のメカニズムを使って、接続が作成した後にブラウザは周期的にサーバーにメッセージを送って、自分のメッセージがあるかどうかを尋ねます.
この基準は、サポートされているブラウザがサーバとの長い接続を元の生態的に作成できるだけでなく、JavaScriptスクリプトの統一性も要求され、この機能を兼ね備えたブラウザが同じコードを使用してサーバ-Sentの符号化を完了できるようにします.
コードの作成は簡単です.

//    ServerSent  
var s = new EventSource("Handler.ashx");
//                 
s.onmessage = function (e) {
    alert(e.data);
};
//            MyEvent          
s.addEventListener("MyEvent", function (e) {
    alert(e.data);
});

サーバのコードも簡単です.

public class Handler : IHttpHandler
{

    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "text/event-stream";
        context.Response.Expires = -1;
        context.Response.Write("event: MyEvent\r
");       //    ，  \r
  
        context.Response.Write("data: HelloWorld!\r
");    //    ，     \r
，       data:
        context.Response.Write("data: I'm server!

");    //      ，  


        context.Response.Flush();                           //     End，        
    }

    public bool IsReusable
    {
        get
        {
            return true;
        }
    }

}

2つのセグメントコードは、サーバメッセージプッシュを備えています.
要するにSeverSentはHTML 5仕様のConetであり、より統一性が高く、簡単で使いやすい.

WebSocket
名前を見ればわかりますが、ブラウザで使えるSocket接続です.
これもHTML 5規格の1つで、ブラウザがJavaScriptスクリプトを使用してTCP接続を手動で作成してサービス側と通信できるように要求しています.
WebSocketは、TCP接続のいくつかの基本機能である確立、一時、および送信にすぎない追加機能を含まない.
また、WebSocketはwsとwssプロトコルを使用しており、接続を開くにはサーバが握手するアルゴリズムが必要です.
従って、WebSocketは、以前のいくつかの手段に比べて符号化量が最大であったが、他の制約がないため、可能なすべての機能を自由に実現することができる.
すなわち「問」+「答」の応答メカニズムを満たすことができ,アクティブプッシュ機能を実現することもできる.
ServerSentと同様にHTML 5もWebSocketが呼び出すJavaScriptを仕様しており、簡単なコードでWebSocket接続を構築することができます.

var ws = new WebSocket("ws://192.168.0.105:10080"); //             

ws.onopen = function (event) { alert("           \r
      ：" + this.readyState); };
ws.onmessage = function (event) { alert("           ：\r
" + event.data); };
ws.onclose = function (event) { alert("          \r
      ：" + this.readyState); };
ws.onerror = function (event) { alert("WebSocket  ！"); };

メッセージをsendで送信することもできます

ws.send("Hello World");

WebSocketには複雑なプロトコルがあり、データ通信のためにサービス側で追加のプログラミングを行う必要があります.協議の詳細については、今後の文章で説明します.

WebSocket + MessageQueue
MessageQueue、略称MQ、すなわちメッセージキュー.Tcpサービス端末によく用いられる技術である.MQサーバは、生産者が生成したメッセージを、様々なメッセージ・タイプにアクセスすることによって、関心のあるクライアントに送信します.市場には多くのMQフレームワークがあります.例えば、ActiveMQです.
ActiveMQはWebSocketプロトコルをサポートしています.つまり、WebSocketはすでに生産者または消費者としてMQサーバに接続できることを意味します.
開発者はMQTTのJSスクリプトを通じて、MQサーバに接続し、同時にWebサーバもMQサーバに接続することができ、これからHttp通信プロトコルに別れを告げ、Socket通信を完全に使用してデータの交換を完了することができる.

まとめ:
要するに、HTML 5仕様では、サーバメッセージのプッシュをサーバSentとWebSocketで行うことが最も推奨されています.
この2つの方式を比較する.
Server Sentの方式は、サービス側の開発を従来の方式に従うことができますが、その動作方式はConetと似ています.
WebSocket方式は,サービス側の開発に高い要求があるが,その動作方式は完全にプッシュされている.
私自身はWebSocket+MQの働き方に偏っていますが、古いプロジェクトのリニューアルにはSeverSentの方がいいと思います

の最後の部分
本文は作者のオリジナルで、転載は出典を明記してください:http://www.zizhusoft.com/note/show.aspx?id=db723a7c-17ce-4c46-9935-aef07f4f371e
記事の関連コードはhttp://j.zizhusoft.com/Develop/Explorer.aspxのサーバSentディレクトリでの表示

微信ウィジェットで滝のレイアウトと無限のロードを実現

iframeでページをリフレッシュしても現在のページをリフレッシュできない解決策