20

最近、サーバーからのプッシュを行うための WebSocket に代わるはるかに単純な方法として、Server-Sent イベントを見つけました。それらを比較するほとんどの場所 (ここ、ここ、ここなど) では、クライアントとサーバー間の全二重通信が必要ない場合、WebSocket は過剰であり、SSE で十分であると述べています。

私の質問は、クライアントからメッセージを送信するために通常の ajax リクエストを使用し、それらを受信するためにサーバー ストリームを使用して、双方向通信 (チャットなど) が必要な場合に SSE を使用することのマイナス面は何でしょうか? SSE を使用するためにサーバー側でほとんどまたはまったく構成を行う必要がないことを考えると、これははるかに魅力的なオプションのようです。

4

2 に答える 2

28

WebSocket に対するSSEの利点:

  • 特別な Web サーバーや Web プロキシの変更は必要ありません。
  • カスタム イベントを定義します (それ以外の場合、クライアント API は基本的に同じです)。
  • 既存の認証メカニズム (OAuth、OpenID など) のより簡単な統合

WebSocket と比較したSSEの欠点:

  • 単方向通信チャネル (サーバーからクライアントへ)。クライアントからサーバーへは別のチャネルが必要です。
  • ブラウザーのサポートはより制限されています (WebSockets は IE 10 でサポートされていますが、ネイティブの IE サポートはありません): WebSockets、SSE
  • 発信元の検証をクライアントに依存します (WebSocket よりも XSS 攻撃に対して脆弱である可能性があります)
  • バイナリ型のネイティブ サポートはありません (WebSockets は ArrayBuffers と Blobs を使用して raw フレームをサポートします)。
  • SSE エンドポイントが静的な Web コンテンツを提供していない場合でも、本格的な Web サーバーが必要です (スタンドアロンの WebSocket サーバーはかなり単純な場合があります)。
  • 双方向通信用の AJAX を使用した SSE は、WebSocket 接続を使用する場合よりも、往復の待ち時間がはるかに長く、クライアントからサーバーへの帯域幅が大きくなります。これは、すべてのクライアントからサーバーへの AJAX 要求に対する接続セットアップのオーバーヘッドによるものです。また、多くの構成では、長時間保持されていた接続が最終的に (多くの場合 30 秒ごとに) 閉じられ、再度開く必要があるため、サーバーからクライアントへのレイテンシーが SSE でスパイクする可能性があり、サーバーからクライアントへのレイテンシーにも一時的なスパイクが発生します。 .

参考文献:

于 2012-11-08T13:16:07.830 に答える
3

Ajax リクエストは、小さな WebSocket メッセージに比べて巨大です。標準の HTTP リクエスト (Ajax) には、すべてのリクエストに Cookie を含む多くのヘッダーが含まれていますが、WebSocket メッセージはほんの数バイトです。

HTTP (Ajax) リクエストの良い点は、キャッシュが問題の利点である場合に簡単にキャッシュできることです。

于 2012-11-07T21:40:35.247 に答える