リアルタイムWebの栄光を願い!!
これから死に行くせめてものこの間に!!
SSEの戦術的価値を説きます!!
今日はSSEの戦術的価値を説きます
SSEとは
SSEとは
- Server-Sent Events
- 常時接続系API
- JavaScriptからはnew EventSource(url);で使う
- JavaScript APIと通信プロトコルが合わさったもの
- プロトコルはHTTPのContent-type: application/octet-stream;、Transfer-Encoding: chunked;
簡単に言うと
「きれいなComet」
または
「妥協したWebSocket」
基本的には「SSE？ なにそれ？」と言われる役
（日本語でしかツイートしてないのに、いきなり知らない人に英語で「would you can help me with HTML5 SSE.? It does not work」とか聞かれるレベル）
Cometと比べてどうか
Cometは調子に乗りすぎた……
いつかSSEが然るべき報いを
Cometとの違い
- 目的はだいたい同じ（ブラウザ上でサーバからpush通信したい）
- Cometはサーバから通信が完了した時点で接続をきる
- SSEは切らないので性能が良い（が互換性はやや下がる）
WebSocketと比べてどうか
俺にはわかる、WebSocketは本物の化け物だ……
WebSocketとの違い
- 目的はSSEとかぶる（ブラウザ上でサーバからpush通信したい場合にも使われる）
- 「WebSocketはHTTPの通信じゃない」
- SSEはHTTPなので互換性が高い
SSEの戦術的価値
SSEの戦術的価値
- HTTPなので通りやすい
（一部のProxyはHTTP chunked streamを通さないけど、基本的にはだいたい通る）
- HTTPなので開発しやすい
（Cookieとか、クロスドメインの問題とか、同じOriginでhtml提供したりとか）
- W3Cの標準仕様なので各言語ごとのライブラリ等も整備されてる
SSEの戦術的価値
- 回線を貼り続けられるのでTCP socketの消費が少ない
- 切断時のリトライ、KeepAlive等も仕様に入ってるので実装が楽
- 速度的には結構早い
「でも未サポートブラウザあるんでしょ？」
（IEは11でも未実装。Android標準ブラウザは結局最後まで未実装）
SSEはpolyfillがあってはじめて「本物のSSE」になる
SSEの問題点
SSEの問題点
- Cometに比べると古いブラウザで動かすのが大変
（Android2系で4Kのpaddingが必要だったり）
- WebSocketと比べると効率が悪い
（再接続は毎回普通のHTTP通信だし）
- HTTPのセキュリティモデルを引き継いでいる
（その辺WebSocketは色々と楽）
SSEの問題点
- ブラウザの実装にバグが多い（polyfillがブラウザ実装無視してObject乗っ取るレベル）
- バイナリは乗らない（\r\nが区切りなので）
- 双方向通信じゃない（upload通信は別途接続が必要）
- デバッグはそこそこ辛い（どちらかと言うとSSEの問題というより常時接続の問題）
これから死に行くせめてものこの間
これから死に行くせめてものこの間
- SSEは死にゆく技術
- 基本的に既存のHTTP、XMLHTTPRequestで出来る範囲での解決策
- 同じ目的であればWebSocketの方が圧倒的に性能が良い
SSEは使えるのか
SSEは使えるのか
- 普通に使える（Android2系を除いて）
- Android2系をサポートするなら一回のデータ送信が常に4Kを越えるようにpaddingを入れる
- 多少の速度ペナルティを許容できるならpolyfillはおすすめ（が、問題あるのはエッジケースの場合もあるのでほんとうに必要か確認した方がいい）
- SharedWorkerで一本常時接続して、複数タブから共有とかすると面白いかも
まだわりと未開の地
みなさんも使ってみてください
ご清聴ありがとうございました