3

HTML5 Server-Sent Events (SSE) API は、HTML5 WebSocket の上にある限定されたイベントベースの API にすぎませんか?

EventSourceanはただの aのように私には思えますWebSocket:

  1. .send()データできません
  2. text/event-streamフォーマットを使用
  3. 代わりに、動的に名前が付けられた (サーバー定義の) イベントを発生させます。onmessage

Web サーバーがイベントをクライアント デバイスにプッシュするというアイデアは、非常に興味深いものです。この API には牽引力がありますか?

非同期イベント モデルは、Node と組み合わせるとうまく機能すると思いますが、私の ASP.NET の世界では、これのユース ケースはあまり見られません。

4

2 に答える 2

7

サーバー送信イベントは、サーバー プッシュのみが必要なアプリケーションに役立ちますが、Web ソケットは、双方向の高速通信を必要とするアプリケーションに適しています。

サーバー送信イベントが適切なソリューションである例は次のとおりです。

  • 株価変動
  • ニュースフィード

サーバー送信イベントは、自動再接続やeventIDなど、Web ソケットに組み込まれていないいくつかのことを行います。

Server Sent イベントは、今日の時点で、Safari (Web ソケットの古いドラフトのみをサポート) と Opera (デフォルトで Web ソケットが無効になっており、古いドラフトを使用) でのサポートにより、より広範な Web ブラウザーをサポートしています。

Server-Sent Events を使用したスト​​リーム更新に関する Server Sent Events の詳細を参照してください。

于 2011-12-14T09:59:08.527 に答える
5

ジョナスが言ったことに加えて、プロトコルはまったく異なります。

  • The WebSocket Protocol(RFC 6455) は HTTP 接続として開始され、ハンドシェイクを使用して接続を新しいプロトコルにアップグレードします。これは、フレーミング、メッセージ タイプなどを使用するバイナリ プロトコルです。

  • Server-Sent Events開いたままの長時間実行される HTTP 要求です。UTF-8サーバーは、 で区切られた単純なテキストベースの形式 (エンコーディング) でメッセージを送信します\n\n。メッセージにはフィールドevent(イベント タイプ) 、data、idがあり、オプションでコメントを含めることができます。

大きな違いの 1 つは、セキュリティ モデルです。WebSocket では、デフォルトで誰でも接続できます。Origin接続の拒否は、ヘッダーに基づいてサーバー側で行う必要があります。

一方、SSE は HTTP に近く、同一オリジン ポリシーを使用します。デフォルトでは、同じホストとポートに対してのみリクエストを行うことができます。将来的には、CORSを使用してクロスドメイン SSE リクエストを作成できるようになります。現在、ブラウザはこれをまだ実装していません。

2 つのプロトコルは、異なる問題を解決するため、異なるアプローチをとります。

于 2012-01-10T08:13:26.117 に答える