サーバー送信イベントとポーリング
HTML5 SSE とAjaxポーリングの間に大きな違い（パフォーマンス、ブラウザー実装の可用性、サーバー負荷など）がありますか？サーバー側からは、EventSourceが指定されたページに約3秒ごとにヒットしているように見えます（タイミングは柔軟です）。
確かに、タイマーを設定して$.getを頻繁に設定するよりもクライアント側で設定する方が簡単ですが、他に何かありますか？送信するヘッダーが少なくなりますか、それとも他に不足している魔法がありますか？
Ajaxポーリングは、HTTP接続を常に確立および切断するため、多くのHTTPオーバーヘッドを追加します。 HTML5 Rocks puts it "一方で、サーバー送信イベントは、効率的になるようにゼロから設計されています。"
サーバー送信イベントは、単一の長期間存続するHTTP接続を開きます。サーバーは、データを取得すると一方向にデータを送信します。クライアントがデータを要求したり、メッセージを待つ以外のことをする必要はありません。
サーバー送信イベントの欠点の1つは、サーバーへの永続的な接続が作成されるため、サーバーに対して多くの接続が開かれる可能性があることです。一部のサーバー 大量の同時接続をより適切に処理する 他のサーバーよりも。ただし、ポーリングで同様の問題に加えて、これらの接続を絶えず再確立するオーバーヘッドが発生します。
サーバー送信イベントは非常によく ほとんどのブラウザーでサポートされています です。もちろん、IEの顕著な例外です。しかし、それを修正する カップルポリフィル （および jQueryプラグイン ）があります。
一方向の通信のみを必要とする何かをしている場合、私は間違いなくサーバー送信イベントに行きます。前述のように、サーバー送信イベントは、クライアント側で実装する方が簡単でクリーンになる傾向があります。メッセージとイベントのリスナーを設定するだけで、ブラウザは切断された場合の再接続などの低レベルのものを処理します。サーバー側では、単純なテキストを使用するだけなので実装もかなり簡単です。 JSONでエンコードされたオブジェクトを送信する場合、 JSON.parse() を介して、クライアント上で簡単にJavaScriptオブジェクトに変換できます。
サーバー上でPHPを使用している場合は、 json_encode() を使用して、文字列、数値、配列、オブジェクトを適切にエンコードされたJSONに変換できます。終了言語も同様の機能を提供する場合があります。
私は言われたことに高い視点を追加するだけで、それはSSEはAJAXの場合の一定のポーリングとは対照的に、パブリッシュ/サブスクライブモデルです。
一般に、両方の方法（ポーリングとパブリッシュ/サブスクライブ）は、クライアントで最新の状態を維持する方法の問題を解決しようとしています。
1）ポーリングモデル
それは単純だ。クライアント（ブラウザ）は最初に初期状態（ページ）を取得し、更新するために、定期的に状態（ページまたはその部分）を要求し、結果を現在の状態に処理する（ページ全体を更新するか、またはAJAXの場合の一部）。
当然、1つの欠点は、サーバーの状態に何も起こらない場合、リソース（CPU、ネットワークなど）が不必要に使用されることです。もう1つは、状態が変化しても、クライアントは次のポーリング期間にのみ取得し、できるだけ早く取得しないということです。多くの場合、2つのことの間で適切な期間の妥協点を評価する必要があります。
ポーリングのもう1つの例は、スレッドのスピンウェイトです。
2）パブリッシュ/サブスクライブモデル
次のように機能します。
- （クライアントが最初に要求し、いくつかの初期状態を示します）
- クライアントはサーバーにサブスクライブします（イベントソースなどのコンテキストを使用して、1つのリクエストを送信します）
- サーバーは、クライアントへの参照をそのクライアント参照リポジトリにマークします
- 状態が更新された場合、サーバーは保持しているクライアントへの参照に基づいてクライアントに通知を送信します。つまり、リクエストへの応答ではなく、サーバーによって開始されたメッセージです
- 良いクライアントは、通知に興味がなくなったときに登録を解除します
別の例として、これはSSE、または待機可能なイベントのスレッド内です。前述のように、自然な欠点は、サーバーがサブスクライブしているすべてのクライアントを認識している必要があることです。これは、実装によっては問題になる場合があります。