サーバーに接続されたWebアプリケーションを開発していますが、サーバーが特定の時間にクライアントに情報をプッシュする必要があります。
そのため、WebサイトはHTML5で開発されており、SSEは私が探していたものに適合しているように見えたため、サーバー送信イベント（SSE）について読み始めました。しかし、SSEが実際に行っているのは、逆の方法ではなく、クライアントからサーバーにリクエストを送信していることを読んだとき、なんと驚きでした（昨日、長いポーリングは一種のプッシュエミュレーションであると理解しました）。そのため、私はWebソケットについて読み始め（ただし、標準はまだドラフトであることがわかりました）、Cometも調べました。しかし、私は私の心にすべての部分を合わせることができないと思います。
誰かが私の問題に合ったこれらのテクノロジー（そしておそらく他のプッシュテック）を強調し、それぞれに適した状況はどれですか？
どうもありがとうございました、私はこの分野で完全に迷子になっていると思います。
この投稿は、Long Polling、Comet、SSE、およびWebSocketに関する違い/利点などについて説明した、より適切な説明です。
ほとんどの場合、クライアントは通常、接続を確立するためにサーバーに最初の要求を行う必要があります。接続が確立されると、サーバーはデータをクライアントにプッシュできます。そのため、 WebSocketを使用している場合でも、クライアントはサーバーに対して最初の要求を行い、2つの間の信頼できる接続を確立します。
サーバー送信イベントは、通常のHTTPGET要求を使用してサーバーとの接続を確立します。これは、クライアントの読み取り専用接続でもあります。新しいプロトコルを定義する必要がないため、実装が簡単であるという利点があります。問題は、持続的接続であっても、ほとんどのWebサーバーで約15秒後にHTTP接続が閉じられることです。長期間のリクエストの場合でも、Webサーバーにはタイムアウトが発生することが多く、その後接続が閉じられます。ここで、ロングポーリングのアイデアが生まれます。サーバーに対して通常のajaxリクエストを行い、サーバーが可能な限りそれを開いたままにしておくのは簡単なアイデアです。なんらかの理由でサーバーによってリクエストが閉じられた場合は、すぐに同じリクエストを再度行います。Nodeなどのサーバーを使用すると、長いポーリングメカニズム（Cometなど）を非常に簡単に実装できます。jsとブラウザからの通常のAjaxリクエスト。サーバー送信イベントは、これのブラウザ側の実装を抽象化しようとしますEventSource。したがって、長いポーリング/コメット用にブラウザ/クライアント側のコードを実装する代わりに、ブラウザがこれを処理します。これは、持続的接続のように見えるものの優れた抽象化を提供します。Webサーバーは、ヘッダーでContent-Typeを「text / event-stream」として指定し、HTTP接続を可能な限り開いたままにするGETリクエストを探す必要があります。
サーバー送信イベントが何であるかを過度に複雑にしないことをお勧めします。通常のHTTPGETリクエストを理解している場合は、その背後にある考え方をすでに90％理解している可能性があります。
SSE / Cometと従来のロングポーリングには、強調する価値のある違いが1つあります。私の経験から、長いポーリングの背後にある考え方は、更新があるまでリクエストが返されないということです。その時点でHTTP接続が閉じられ、その直後に別の要求が行われます。SSEを使用すると、更新されたメッセージを送信した直後にHTTP接続を閉じることができますが、目的は、HTTP要求を実際に閉じたり終了したりせずに、サーバーからクライアントにデータをフラッシュすることです。これにより、実際にGETリクエストを行うオーバーヘッドが回避されます。これは通常のajaxリクエストで実現できますが、SSEはEventSourceを使用した優れた効率的な実装を提供します。
編集：SSEとロングポーリングの違いを明確にします。