websocket
Server-Sent-Events

サーバサイドpush技術としてのWebsocketとServer-sent eventsの特徴比較

More than 1 year has passed since last update.

サーバサイドpush技術として見たときのWebsocketとServer-sent events(SSE)の特徴を整理したい。

ブラウザのサポート状況

既存の開発スタックとの親和性

  • SSEはHTTPそのものなので、ストリームレスポンスを返せるプラットフォームなら導入が容易。素のPHPでも25行で実装可能
  • Websocketは独自プロトコルなので、対応したウェブフレームワークが必要
  • SSEはHTTPに対応リバースプロキシで動く。ただし、例えばnginxならX-Accel-Bufferingヘッダーproxy_buffering offなどのbufferingをOFFにする対応は必要。
  • WebsocketはWebsocketに対応したリバースプロキシが必要。大抵の有名なリバースプロキシは対応している。例えば、nginxでは数行の設定を書くだけで対応できる。
  • WebsocketをCloudFlareに通すには有料のEnterpriseプランが必要

サーバから送れるデータ

  • SSEはテキストのみ。バイナリを送る場合はbase64する。base64したバイナリのデータ量は33%ほど増えるが、SSEはHTTPなので同時にgzipが使える。
  • Websocketはバイナリも送信できる。
  • SSEはUTF-8のみ。UTF-8以外はやはりbase64する。
  • Websocketは文字コードに制限がない。

チャネル

  • WebsocketもSSEもチャネルを複数持てる。厳密には、SSEは「チャネル」という用語は使ってなく「event」という。

制約面

セキュリティ面

  • WebsocketはSame-origin policyが無い。Cross-Site WebSocket Hijacking (CSWSH)の対策、Cross-site WebSockets Scripting (XSWS)の対策のため、Originヘッダのチェックする、Content-Security-Policyヘッダを活用しXSSしにくくしておく。
  • SSEは普通のHTTP GETリクエストにするのと同じようにセキュリティを講じれば良い。もちろんSame-origin policyも適用される。

後で検討したいこと

  • コネクション確立後、クライアントのIPが変化した場合の振る舞いはどうなるか?
  • オンライン状況の変化による切断・再接続の振る舞いはどうか?

気づいたことがあれば追記していきたい。