サーバPUSHざっくりまとめ
- 3. 概要 •各方式をざっくり確認＋比較 •ポーリング •Ajax •Comet •Server Sent Events •WebSocket •図は以前書いたWebSocket / WebRTCの技術紹介から
- 4. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス
- 5. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス
- 6. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス
- 7. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新
- 8. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新 …
- 12. Ajax (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新 … • クライアント契機でXML/jsonを取得 • 疑似PUSH
- 13. Ajax (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新 … • クライアント契機でXML/jsonを取得 • 疑似PUSH この辺がAjax
- 14. Ajax (2/4) •Ajax = Asynchronous JavaScript + XML •XHR(XMLHttpRequest)で実装 •XMLでなくテキストでもいい •なのでJSONが使われることが多い（と 思う） •「ちょっとマシなポーリング」ができる
- 17. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH
- 18. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH
- 19. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留
- 20. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留
- 21. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 画面を更新
- 22. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 次のPUSH用の リクエストを投げる 画面を更新
- 23. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 次のPUSH用の リクエストを投げる 画面を更新
- 24. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 次のPUSH用の リクエストを投げる 画面を更新
- 25. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 この辺でデータが 発生するとラグ 次のPUSH用の リクエストを投げる 画面を更新
- 26. Comet (2/4) •ロングポーリング •一般に、サーバは可及的速やかにレスポンスを返す •Cometでは「PUSHしたい時」までレスポンスを返さ ない •つまりポーリングよりポーリング間隔が長い •双方向通信 •クライアント to サーバは通常のHTTP •サーバ to クライアントはComet
- 27. Comet (2/4) •ロングポーリング •一般に、サーバは可及的速やかにレスポンスを返す •Cometでは「PUSHしたい時」までレスポンスを返さ ない •つまりポーリングよりポーリング間隔が長い •双方向通信 •クライアント to サーバは通常のHTTP •サーバ to クライアントはComet この辺がロング
- 29. Comet (4/4) •デメリット •仕組み上、ごく短時間に連続でPUSHすることができない •一度PUSHすると、クライアントから次のPUSH用の接続を 待たないといけない •サーバは最大でポーリングの2倍のリソース（曖昧）を消費する •「サーバ to クライアント（Comet）」で1つ •「クライアント to サーバ（HTTP）」で1つ •ポーリング方式より不利というだけで、根本的にはどの方式 でも同じ問題がついて回る（C10K問題）
- 30. Comet (4/4) •デメリット •仕組み上、ごく短時間に連続でPUSHすることができない •一度PUSHすると、クライアントから次のPUSH用の接続を 待たないといけない •サーバは最大でポーリングの2倍のリソース（曖昧）を消費する •「サーバ to クライアント（Comet）」で1つ •「クライアント to サーバ（HTTP）」で1つ •ポーリング方式より不利というだけで、根本的にはどの方式 でも同じ問題がついて回る（C10K問題） あくまでも 最大だよ
- 31. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH
- 32. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH
- 33. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH データ発生のたびに 送信する
- 34. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH 分割（chunked）データ扱い データ発生のたびに 送信する
- 35. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH 分割（chunked）データ扱い データ発生のたびに 送信する 画面を更新
- 36. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH 分割（chunked）データ扱い クローズしていないのでさらに送れる データ発生のたびに 送信する 画面を更新
- 37. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH 分割（chunked）データ扱い クローズしていないのでさらに送れる データ発生のたびに 送信する 画面を更新
- 38. •Server Sent Events (SSE) •新しいロングポーリング方式 •Chunked Transfer Coding •HTTPサーバがレスポンスを「分割（chunked）データ」 として宣言する •サーバはPUSHが必要になる度にクライアントへデータを 送る •データ = 「HTTPレスポンスの一部」をPUSHしても通信 が維持される Server Sent Events (2/4)
- 40. •デメリット •HTTPクライアント（ブラウザ等）がServer Sent Eventsに対応していないといけない •古いブラウザだと動かない •具体的にはIE（11でも ）とかAndroid標準 ブラウザ（4.4未満は ） •Cometと同じく、サーバは最大でポーリング方式 の2倍のリソースを消費する Server Sent Events (4/4)
- 41. (補足) Streaming API •Twitterのアレ •Ajax + Chunked Transfer Coding •機能上の特徴はServer Sent Eventsと同等 •クライアント側の処理がServer Sent Eventsより複雑 •Server Sent Eventsの仕様ができるより前に、同等のことを HTTP 1.1 + Ajaxで実現したもの •独自仕様の「Server Sent Eventsっぽい何か」と捉えても良い •と解釈しているんだけど、情報がいまいち出てこなくて正しいかわか らない
- 42. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH WebSocket メッセージ
- 43. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH WebSocket メッセージ
- 44. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH WebSocket メッセージ データ発生のたびに 送信する
- 45. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH 画面を更新 WebSocket メッセージ データ発生のたびに 送信する
- 46. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH 画面を更新 WebSocket メッセージ データ発生のたびに 送信する
- 51. WebSocket (4/5) •メリット •HTTPプロトコルと比較してヘッダが軽量＝通信負 荷が低い •リアルタイム性が高い •サーバ to クライアントとクライアント to サーバで 同じ経路 •サーバにやさしい、リソース的な意味で •標準化策定済み
- 52. WebSocket (5/5) •デメリット •サーバ、クライアントともWebSocket規格への準拠が必要 •古いWebサーバやブラウザは非対応 •IE10未満とか、Android 4.4未満の標準ブラウザ •既存の通信機器を通過できない可能性がある •例えば80番port = HTTPの前提で監査しているルータ等 にWebSocket通信を流すと、異常データ扱いで弾かれる ことがある •httpsだと中身が見えないので比較的通りやすい
- 53. PUSH方式の比較 リアルタイム性 サーバの 負荷 (低) Webサーバの 対応 ブラウザの 対応 ポーリング / Ajax △∼ ∼△ ○ ○ Comet ○ ○ ○ ○ Server Sent Events ○ ○ ○ △ WebSocket ○ ○ △ △