Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
サーバPUSH
ざっくりまとめ
2014/8/11
(2013/10に一度お蔵入り)
!
回り道 康博
目的
•PUSHについて以下のことを確認
•何でWebSocketがいいんだっけ
•従来の方式は何がよくないんだっけ
•そもそも何があったっけ
概要
•各方式をざっくり確認+比較
•ポーリング
•Ajax
•Comet
•Server Sent Events
•WebSocket
•図は以前書いたWebSocket / WebRTCの技術紹介から
ポーリング (1/4)
• クライアント契機でHTMLを取得
• 疑似PUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
ポーリング (1/4)
• クライアント契機でHTMLを取得
• 疑似PUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
ポーリング (1/4)
• クライアント契機でHTMLを取得
• 疑似PUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
ポーリング (1/4)
• クライアント契機でHTMLを取得
• 疑似PUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
画面を更新
ポーリング (1/4)
• クライアント契機でHTMLを取得
• 疑似PUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
画面を更新
…
ポーリング (2/4)
•初期の疑似PUSH
•昔のBBSやチャット
•HTTPクライアントがHTTPサーバへ定
期的にアクセスして画面を再描画
•リアルタイム性はアクセス間隔に依存
ポーリング (3/4)
•メリット
•昔(とても昔)のブラウザでも動く
•特殊なことはやっていない
ポーリング (4/4)
•デメリット
•リアルタイム性が低い
•リアルタイム性を上げるために更新頻度を上げ
るとサーバ負荷上がる
•差分でなくフルのHTMLを毎回取得する
•クライアントは定期的にサーバへアクセスする
•クライアントはサーバに新...
Ajax (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
画面を更新
…
• クライアント契機でXML/jsonを取得
• 疑似PUSH
Ajax (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
画面を更新
…
• クライアント契機でXML/jsonを取得
• 疑似PUSH この辺がAjax
Ajax (2/4)
•Ajax = Asynchronous JavaScript + XML
•XHR(XMLHttpRequest)で実装
•XMLでなくテキストでもいい
•なのでJSONが使われることが多い(と
思う)
•「ちょっとマシ...
Ajax (3/4)
•メリット
•ポーリング方式より通信負荷が低い
•サーバから必要なデータだけ持ってくる
•画面全体のHTMLを再取得しない
•「全データを予め取得するのが非現実的」で「状
況に応じてデータを取得する」用途に向く
•Goog...
Ajax (4/4)
•デメリット
•PUSHの観点ではポーリングと変わらない
•サーバからデータを送るにはクライアン
トからのアクセスが必要
•というかそもそもPUSHのリアルタイム
性を上げるための仕様じゃない
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
画面を更新
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
次のPUSH用の
リクエス...
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
次のPUSH用の
リクエス...
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
次のPUSH用の
リクエス...
Comet (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得
• サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
この辺でデータが
発生する...
Comet (2/4)
•ロングポーリング
•一般に、サーバは可及的速やかにレスポンスを返す
•Cometでは「PUSHしたい時」までレスポンスを返さ
ない
•つまりポーリングよりポーリング間隔が長い
•双方向通信
•クライアント to サーバ...
Comet (2/4)
•ロングポーリング
•一般に、サーバは可及的速やかにレスポンスを返す
•Cometでは「PUSHしたい時」までレスポンスを返さ
ない
•つまりポーリングよりポーリング間隔が長い
•双方向通信
•クライアント to サーバ...
Comet (3/4)
•メリット
•リアルタイム性がポーリング方式より
高い
Comet (4/4)
•デメリット
•仕組み上、ごく短時間に連続でPUSHすることができない
•一度PUSHすると、クライアントから次のPUSH用の接続を
待たないといけない
•サーバは最大でポーリングの2倍のリソース(曖昧)を消費する
•「...
Comet (4/4)
•デメリット
•仕組み上、ごく短時間に連続でPUSHすることができない
•一度PUSHすると、クライアントから次のPUSH用の接続を
待たないといけない
•サーバは最大でポーリングの2倍のリソース(曖昧)を消費する
•「...
Server Sent Events (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR)
• 本格的なPUSH
Server Sent Events (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR)
• 本格的なPUSH
Server Sent Events (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR)
• 本格的なPUSH データ発生のたびに
送信する
Server Sent Events (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR)
• 本格的なPUSH
分割(chunked)データ扱い
データ発生のたびに
送...
Server Sent Events (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR)
• 本格的なPUSH
分割(chunked)データ扱い
データ発生のたびに
送...
Server Sent Events (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR)
• 本格的なPUSH
分割(chunked)データ扱い
クローズしていないので...
Server Sent Events (1/4)
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR)
• 本格的なPUSH
分割(chunked)データ扱い
クローズしていないので...
•Server Sent Events (SSE)
•新しいロングポーリング方式
•Chunked Transfer Coding
•HTTPサーバがレスポンスを「分割(chunked)データ」
として宣言する
•サーバはPUSHが必要になる度...
•メリット
•リアルタイム性がポーリングより高い
•Cometに比べて、「一度サーバPUSHを受け
た後にクライアントが再接続」する手間とラ
グがない
•サーバ側の実装が従来の延長で可能
•WebSocketのような新規格への対応が不要
Ser...
•デメリット
•HTTPクライアント(ブラウザ等)がServer
Sent Eventsに対応していないといけない
•古いブラウザだと動かない
•具体的にはIE(11でも )とかAndroid標準
ブラウザ(4.4未満は )
•Cometと同じ...
(補足) Streaming API
•Twitterのアレ
•Ajax + Chunked Transfer Coding
•機能上の特徴はServer Sent Eventsと同等
•クライアント側の処理がServer Sent Event...
WebSocket (1/5)
サーバ
• HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR)
• 本格的なPUSH
WebSocket
メッセージ
WebSocket (1/5)
サーバ
• HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR)
• 本格的なPUSH
WebSocket
メッセージ
WebSocket (1/5)
サーバ
• HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR)
• 本格的なPUSH
WebSocket
メッセージ
データ発生のたびに
送信する
WebSocket (1/5)
サーバ
• HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR)
• 本格的なPUSH
画面を更新
WebSocket
メッセージ
データ発生のたびに
送信する
WebSocket (1/5)
サーバ
• HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR)
• 本格的なPUSH
画面を更新
WebSocket
メッセージ
データ発生のたびに
送信する
WebSocket
メッセージ
クライアント
WebSocket (2/5)
サーバ
WebSocket
メッセージ
クライアント
送信完了前に別の送信を開始しても可
WebSocket (2/5)
サーバ
WebSocket
メッセージ
クロスしても可
クライアント
送信完了前に別の送信を開始しても可
WebSocket (2/5)
サーバ
WebSocket (3/5)
•効率的な双方向通信のために作られた、HTTPと別の規格
•WebSocketプロトコルは通信仕様、IETF管轄
•http://tools.ietf.org/html/rfc6455
•単に使う分にはそれほど意...
WebSocket (4/5)
•メリット
•HTTPプロトコルと比較してヘッダが軽量=通信負
荷が低い
•リアルタイム性が高い
•サーバ to クライアントとクライアント to サーバで
同じ経路
•サーバにやさしい、リソース的な意味で
•標...
WebSocket (5/5)
•デメリット
•サーバ、クライアントともWebSocket規格への準拠が必要
•古いWebサーバやブラウザは非対応
•IE10未満とか、Android 4.4未満の標準ブラウザ
•既存の通信機器を通過できない可能...
PUSH方式の比較
リアルタイム性
サーバの
負荷 (低)
Webサーバの
対応
ブラウザの
対応
ポーリング /
Ajax
△∼ ∼△ ○ ○
Comet ○ ○ ○ ○
Server Sent
Events
○ ○ ○ △
WebSocke...
まとめ
•WebSocket
•Server Sent Events
•Comet
•Ajax
•ポーリング
まとめ
•WebSocket
•Server Sent Events
•Comet
•Ajax
•ポーリング
越えられない壁
まとめ
•WebSocket
•Server Sent Events
•Comet
•Ajax
•ポーリング
おすすめ
非おすすめ
越えられない壁
蛇足
•HTTP2がないね
•そうすね、近いうちにRFC出そうですね
•あっちのPUSHは「好きな時にサーバPUSH」じゃなく「Webページ
に必要そうなデータをサーバ契機で予め送信」のPUSH
•PUSH方式選択のポイントは(サポート対象の)...
Upcoming SlideShare
Loading in …5
×

サーバPUSHざっくりまとめ

33,617 views

Published on

ポーリング、Ajax、Comet、Server Sent Events、WebSocket
サーバPUSH方式の大雑把な比較

Published in: Technology
  • Be the first to comment

サーバPUSHざっくりまとめ

  1. 1. サーバPUSH ざっくりまとめ 2014/8/11 (2013/10に一度お蔵入り) ! 回り道 康博
  2. 2. 目的 •PUSHについて以下のことを確認 •何でWebSocketがいいんだっけ •従来の方式は何がよくないんだっけ •そもそも何があったっけ
  3. 3. 概要 •各方式をざっくり確認+比較 •ポーリング •Ajax •Comet •Server Sent Events •WebSocket •図は以前書いたWebSocket / WebRTCの技術紹介から
  4. 4. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス
  5. 5. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス
  6. 6. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス
  7. 7. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新
  8. 8. ポーリング (1/4) • クライアント契機でHTMLを取得 • 疑似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新 …
  9. 9. ポーリング (2/4) •初期の疑似PUSH •昔のBBSやチャット •HTTPクライアントがHTTPサーバへ定 期的にアクセスして画面を再描画 •リアルタイム性はアクセス間隔に依存
  10. 10. ポーリング (3/4) •メリット •昔(とても昔)のブラウザでも動く •特殊なことはやっていない
  11. 11. ポーリング (4/4) •デメリット •リアルタイム性が低い •リアルタイム性を上げるために更新頻度を上げ るとサーバ負荷上がる •差分でなくフルのHTMLを毎回取得する •クライアントは定期的にサーバへアクセスする •クライアントはサーバに新しい情報があるかど うか(だけを)知る術がない
  12. 12. Ajax (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新 … • クライアント契機でXML/jsonを取得 • 疑似PUSH
  13. 13. Ajax (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス 画面を更新 … • クライアント契機でXML/jsonを取得 • 疑似PUSH この辺がAjax
  14. 14. Ajax (2/4) •Ajax = Asynchronous JavaScript + XML •XHR(XMLHttpRequest)で実装 •XMLでなくテキストでもいい •なのでJSONが使われることが多い(と 思う) •「ちょっとマシなポーリング」ができる
  15. 15. Ajax (3/4) •メリット •ポーリング方式より通信負荷が低い •サーバから必要なデータだけ持ってくる •画面全体のHTMLを再取得しない •「全データを予め取得するのが非現実的」で「状 況に応じてデータを取得する」用途に向く •Googleマップとか
  16. 16. Ajax (4/4) •デメリット •PUSHの観点ではポーリングと変わらない •サーバからデータを送るにはクライアン トからのアクセスが必要 •というかそもそもPUSHのリアルタイム 性を上げるための仕様じゃない
  17. 17. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH
  18. 18. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH
  19. 19. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留
  20. 20. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留
  21. 21. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 画面を更新
  22. 22. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 次のPUSH用の リクエストを投げる 画面を更新
  23. 23. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 次のPUSH用の リクエストを投げる 画面を更新
  24. 24. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 次のPUSH用の リクエストを投げる 画面を更新
  25. 25. Comet (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで レスポンスを保留 この辺でデータが 発生するとラグ 次のPUSH用の リクエストを投げる 画面を更新
  26. 26. Comet (2/4) •ロングポーリング •一般に、サーバは可及的速やかにレスポンスを返す •Cometでは「PUSHしたい時」までレスポンスを返さ ない •つまりポーリングよりポーリング間隔が長い •双方向通信 •クライアント to サーバは通常のHTTP •サーバ to クライアントはComet
  27. 27. Comet (2/4) •ロングポーリング •一般に、サーバは可及的速やかにレスポンスを返す •Cometでは「PUSHしたい時」までレスポンスを返さ ない •つまりポーリングよりポーリング間隔が長い •双方向通信 •クライアント to サーバは通常のHTTP •サーバ to クライアントはComet この辺がロング
  28. 28. Comet (3/4) •メリット •リアルタイム性がポーリング方式より 高い
  29. 29. Comet (4/4) •デメリット •仕組み上、ごく短時間に連続でPUSHすることができない •一度PUSHすると、クライアントから次のPUSH用の接続を 待たないといけない •サーバは最大でポーリングの2倍のリソース(曖昧)を消費する •「サーバ to クライアント(Comet)」で1つ •「クライアント to サーバ(HTTP)」で1つ •ポーリング方式より不利というだけで、根本的にはどの方式 でも同じ問題がついて回る(C10K問題)
  30. 30. Comet (4/4) •デメリット •仕組み上、ごく短時間に連続でPUSHすることができない •一度PUSHすると、クライアントから次のPUSH用の接続を 待たないといけない •サーバは最大でポーリングの2倍のリソース(曖昧)を消費する •「サーバ to クライアント(Comet)」で1つ •「クライアント to サーバ(HTTP)」で1つ •ポーリング方式より不利というだけで、根本的にはどの方式 でも同じ問題がついて回る(C10K問題) あくまでも 最大だよ
  31. 31. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
  32. 32. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
  33. 33. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH データ発生のたびに 送信する
  34. 34. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH 分割(chunked)データ扱い データ発生のたびに 送信する
  35. 35. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH 分割(chunked)データ扱い データ発生のたびに 送信する 画面を更新
  36. 36. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH 分割(chunked)データ扱い クローズしていないのでさらに送れる データ発生のたびに 送信する 画面を更新
  37. 37. Server Sent Events (1/4) クライアント サーバ HTTPリクエスト HTTPレスポンス • Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH 分割(chunked)データ扱い クローズしていないのでさらに送れる データ発生のたびに 送信する 画面を更新
  38. 38. •Server Sent Events (SSE) •新しいロングポーリング方式 •Chunked Transfer Coding •HTTPサーバがレスポンスを「分割(chunked)データ」 として宣言する •サーバはPUSHが必要になる度にクライアントへデータを 送る •データ = 「HTTPレスポンスの一部」をPUSHしても通信 が維持される Server Sent Events (2/4)
  39. 39. •メリット •リアルタイム性がポーリングより高い •Cometに比べて、「一度サーバPUSHを受け た後にクライアントが再接続」する手間とラ グがない •サーバ側の実装が従来の延長で可能 •WebSocketのような新規格への対応が不要 Server Sent Events (3/4)
  40. 40. •デメリット •HTTPクライアント(ブラウザ等)がServer Sent Eventsに対応していないといけない •古いブラウザだと動かない •具体的にはIE(11でも )とかAndroid標準 ブラウザ(4.4未満は ) •Cometと同じく、サーバは最大でポーリング方式 の2倍のリソースを消費する Server Sent Events (4/4)
  41. 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. 42. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH WebSocket メッセージ
  43. 43. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH WebSocket メッセージ
  44. 44. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH WebSocket メッセージ データ発生のたびに 送信する
  45. 45. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH 画面を更新 WebSocket メッセージ データ発生のたびに 送信する
  46. 46. WebSocket (1/5) サーバ • HTTPの縛りを外して作られたWeb標準 (RFC 6455 / W3C CR) • 本格的なPUSH 画面を更新 WebSocket メッセージ データ発生のたびに 送信する
  47. 47. WebSocket メッセージ クライアント WebSocket (2/5) サーバ
  48. 48. WebSocket メッセージ クライアント 送信完了前に別の送信を開始しても可 WebSocket (2/5) サーバ
  49. 49. WebSocket メッセージ クロスしても可 クライアント 送信完了前に別の送信を開始しても可 WebSocket (2/5) サーバ
  50. 50. WebSocket (3/5) •効率的な双方向通信のために作られた、HTTPと別の規格 •WebSocketプロトコルは通信仕様、IETF管轄 •http://tools.ietf.org/html/rfc6455 •単に使う分にはそれほど意識しなくてもいい •知っているに越したことはないが •WebSocket APIはWebSocketをJavaScriptから使うた めのAPI、W3C管轄 •http://www.w3.org/TR/websockets/
  51. 51. WebSocket (4/5) •メリット •HTTPプロトコルと比較してヘッダが軽量=通信負 荷が低い •リアルタイム性が高い •サーバ to クライアントとクライアント to サーバで 同じ経路 •サーバにやさしい、リソース的な意味で •標準化策定済み
  52. 52. WebSocket (5/5) •デメリット •サーバ、クライアントともWebSocket規格への準拠が必要 •古いWebサーバやブラウザは非対応 •IE10未満とか、Android 4.4未満の標準ブラウザ •既存の通信機器を通過できない可能性がある •例えば80番port = HTTPの前提で監査しているルータ等 にWebSocket通信を流すと、異常データ扱いで弾かれる ことがある •httpsだと中身が見えないので比較的通りやすい
  53. 53. PUSH方式の比較 リアルタイム性 サーバの 負荷 (低) Webサーバの 対応 ブラウザの 対応 ポーリング / Ajax △∼ ∼△ ○ ○ Comet ○ ○ ○ ○ Server Sent Events ○ ○ ○ △ WebSocket ○ ○ △ △
  54. 54. まとめ •WebSocket •Server Sent Events •Comet •Ajax •ポーリング
  55. 55. まとめ •WebSocket •Server Sent Events •Comet •Ajax •ポーリング 越えられない壁
  56. 56. まとめ •WebSocket •Server Sent Events •Comet •Ajax •ポーリング おすすめ 非おすすめ 越えられない壁
  57. 57. 蛇足 •HTTP2がないね •そうすね、近いうちにRFC出そうですね •あっちのPUSHは「好きな時にサーバPUSH」じゃなく「Webページ に必要そうなデータをサーバ契機で予め送信」のPUSH •PUSH方式選択のポイントは(サポート対象の)ブラウザ •古いブラウザのサポートがmustな場合、新しい方式は辛いよ(今後も 含めて) •今のWebサーバやブラウザは大抵WebSocketに対応済み •でも通信経路的に使えないケースもあるから注意だよ •悩んだらとりあえずSocket.IOで安定

×