CometPub20070223

1,049 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,049
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

CometPub20070223

  1. 1. Keeping COMET alive サイボウズ・ラボ株式会社 奥 一穂
  2. 2. Comet とは ? <ul><li>a.k.a. Ajax Polling </li></ul><ul><ul><li>long-lived stream over HTTP </li></ul></ul><ul><li>代表例 </li></ul><ul><ul><li>Lingr </li></ul></ul><ul><li>やる気のない説明でごめんなさい </li></ul>
  3. 3. Comet とは ? (2) <ul><li>Comet は、まだまだ未成熟な技術です </li></ul><ul><li>道を誤ると危険 !! </li></ul>でも、今日は地上の星について話しましょう シューメーカー・レヴィ第9彗星 1994 年 7 月、分裂して木星に衝突
  4. 4. 目次 <ul><li>Comet vs. Specifications </li></ul><ul><li>Comet のプログラミングモデル </li></ul><ul><li>まとめ & おまけ </li></ul>
  5. 5. <ul><li>Comet vs. Specifications </li></ul>
  6. 6. Comet vs. Specifications <ul><li>HTTP Keepalive </li></ul><ul><li>HTTP/1.1 Pipelining </li></ul><ul><li>同時接続数の制限 </li></ul><ul><li>XHR の Same Origin Policy </li></ul>
  7. 7. What is Keepalive? <ul><li>複数リクエストで TCP 接続を使いまわし </li></ul><ul><li>接続切断のオーバーヘッドがなくなる </li></ul><ul><li>HTTP/1.0 で de-facto な仕様が出現 </li></ul><ul><ul><li>参考 : RFC2068 </li></ul></ul><ul><li>HTTP/1.1 で正式な仕様になった </li></ul><ul><li>Comet では、当然使いたい </li></ul>
  8. 8. HTTP/1.1 Pipelining <ul><li>HTTP/1.1 の requirement </li></ul><ul><ul><li>Keepalive をサポートする限りにおいて </li></ul></ul><ul><li>複数の HTTP リクエストを続けて送信 </li></ul><ul><ul><li>レイテンシの隠蔽が可能 </li></ul></ul><ul><li>Comet とは相性が悪い </li></ul><ul><ul><li>レスポンス送信待ちの接続に次のリクエストが来る </li></ul></ul><ul><li>Firefox は Pipelining を実装している orz </li></ul><ul><ul><li>デフォルト Off だけど、 On にしている人も </li></ul></ul><ul><ul><li>IE は未実装 ? </li></ul></ul>
  9. 9. How to Use Keepalive BUT NOT Pipelining <ul><li>やや裏技ですが… </li></ul><ul><li>2つの方法 </li></ul><ul><ul><li>HTTP/1.0 Keepalive を使う </li></ul></ul><ul><ul><li>Pipeline 実装が壊れているサーバを名乗る </li></ul></ul><ul><ul><ul><li>IIS/4, IIS/5, Netscape Enterprise/3 </li></ul></ul></ul><ul><ul><li>参考 : Firefox のソース </li></ul></ul>
  10. 10. 同時接続数の制限 <ul><li>HTTP の同時接続数 : 2 ~ 4 </li></ul><ul><ul><li>A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy . </li></ul></ul><ul><ul><li>-- 8.1.4 Practical Considerations, RFC 2616 </li></ul></ul><ul><li>複数の Comet セッションがほしいケースも </li></ul><ul><ul><li>例 : 複数のチャットルームに入る </li></ul></ul><ul><li>回避策は ? </li></ul><ul><ul><li>JSONP – セキュリティリスク or パフォーマンス劣化 </li></ul></ul><ul><ul><ul><li>やはり XHR を使いたい </li></ul></ul></ul>
  11. 11. 同時接続数の制限 (2) <ul><li>RFC2616 再訪 </li></ul><ul><ul><li>A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy . </li></ul></ul><ul><ul><li>-- 8.1.4 Practical Considerations, RFC 2616 </li></ul></ul><ul><li>Server の定義とは ? </li></ul><ul><ul><li>IP アドレスではなく location.hostname </li></ul></ul><ul><ul><ul><li>主要ブラウザ全部がそう ( だったと思う… ) </li></ul></ul></ul><ul><ul><ul><li>VirtualHost や Load Balancing を考えると妥当な設計 ? </li></ul></ul></ul><ul><li>結論 : ホスト名を増やすことで回避可能 </li></ul>
  12. 12. XHR の Same Origin Policy <ul><li>XmlHttpRequest は、 location.hostport のサーバとしか交信できない </li></ul><ul><li>ホスト名を増やした場合の回避策 ? </li></ul>
  13. 13. XHR の Same Origin Policy (2) <ul><li>回避策 : Iframe + XHR </li></ul><ul><ul><li>Iframe の場合は、 document.domain を変更することで、異なるサブドメインのフレーム間交信が可能 </li></ul></ul><ul><li>例 : サービスの URL は chatservice.yy </li></ul><ul><ul><li>iframe に xxx.chatservice.yy をロード </li></ul></ul><ul><ul><li>iframe 内から xxx.chatservice.yy に XHR </li></ul></ul><ul><ul><li>xxx を大量に生成 -> 同時接続数制限を回避 </li></ul></ul>
  14. 14. <ul><li>Comet のプログラミングモデル </li></ul>
  15. 15. Comet のプログラミングモデル <ul><li>C10K Problem </li></ul><ul><li>3+1 種類のプログラミングモデル </li></ul><ul><ul><li>Suspend & Resume モデル </li></ul></ul><ul><ul><li>Queue モデル </li></ul></ul><ul><ul><li>Suspend & Push モデル </li></ul></ul><ul><ul><li>独自サーバモデル </li></ul></ul><ul><li>これからの課題 </li></ul>
  16. 16. C10K Problem <ul><li>C10K Problem </li></ul><ul><ul><li>サーバで TCP 接続 10,000 本をどう扱うか ? </li></ul></ul><ul><ul><li>大規模サービスの人たちは経験済 </li></ul></ul><ul><li>Comet では、 C10K の意味が変わる </li></ul><ul><ul><li>これまで場合 : リクエスト待ち x 10K </li></ul></ul><ul><ul><li>Comet の場合 : 処理中のリクエスト x 10K </li></ul></ul><ul><li>従来のプログラミングモデルは使えない </li></ul><ul><ul><li>例 : Perl インタプリタを1万個も起動したくない </li></ul></ul><ul><ul><ul><li>メモリが 100GB くらい必要 ? </li></ul></ul></ul>
  17. 17. Suspend & Resume モデル <ul><li>Jetty が実装 (Jetty Continuations) </li></ul><ul><li>手順 </li></ul><ul><ul><li>1. アプリケーションロジックでサスペンド宣言 </li></ul></ul><ul><ul><li>2. サーバが Notify or タイムアウトまで待機 </li></ul></ul><ul><ul><li>3. アプリケーションロジックを再実行 </li></ul></ul><ul><li>評価 </li></ul><ul><ul><li>+ 従来のプログラミングモデルに近い </li></ul></ul><ul><ul><li>- 負荷が高く、チャット等マルチキャストには向かない </li></ul></ul>
  18. 18. Queue モデル <ul><li>lighttpd の開発者が提案 (mod_mailbox) </li></ul><ul><li>ウェブサーバ上に Queue を作る </li></ul><ul><ul><li>アプリケーションロジックが Queue を作成&書込 </li></ul></ul><ul><ul><li>ブラウザが Comet で Queue から読込 </li></ul></ul><ul><ul><li>Queue は自動的に expire </li></ul></ul><ul><li>評価 </li></ul><ul><ul><li>+ 負荷が低く、マルチキャストに向く </li></ul></ul><ul><ul><li>- アクセス制限等の柔軟性に疑問符 </li></ul></ul><ul><ul><li>- スケールアウトできない </li></ul></ul>
  19. 19. Suspend & Push モデル <ul><li>cometd (reverse proxy) が実装 </li></ul><ul><li>手順 </li></ul><ul><ul><li>1. ウェブサーバが特殊なヘッダ (w.ID) を返す </li></ul></ul><ul><ul><li>2. rproxy がレスポンス送信待ち状態に入る </li></ul></ul><ul><ul><li>3. アプリケーションロジックが rproxy を経由して (ID で指定した接続に ) レスポンスをプッシュ </li></ul></ul><ul><li>評価 </li></ul><ul><ul><li>+ 負荷が低く、マルチキャストに向く </li></ul></ul><ul><ul><li>+ スケールアウト可能 </li></ul></ul>
  20. 20. 独自サーバモデル <ul><li>スケールアップを狙うならコレ </li></ul><ul><ul><li>無駄なオーバーヘッドが無い </li></ul></ul><ul><ul><li>特定用途向け httpd の実装は難しくない </li></ul></ul><ul><li>Perl 等でも、そこそこの速度が出ます </li></ul><ul><ul><li>C やネットワークの知識はあったほうがいい </li></ul></ul><ul><ul><ul><li>パフォーマンスチューニングのため </li></ul></ul></ul><ul><ul><li>初心者へのオススメ : PoCo::Server::HTTP </li></ul></ul><ul><ul><li>パフォーマンスがほしい人 : Sys::Syscall qw(:epoll) </li></ul></ul>
  21. 21. これからの課題 <ul><li>現実的な例 : スケジュールの変更通知 </li></ul><ul><ul><li>変更を共有メンバー ( 変更者を除く ) に通知したい </li></ul></ul><ul><ul><li>スケジュールの追加・変更・削除… </li></ul></ul><ul><ul><li>アプリケーションロジックの何ヶ所で対応が必要 ? </li></ul></ul><ul><li>DB 変更をトリガーにして Push したいよね ? </li></ul><ul><ul><li>Push のロジックはスクリプト言語で書きたいはず </li></ul></ul><ul><ul><li>DB サーバーを拡張 ? </li></ul></ul><ul><ul><li>O/R マッパーで対応可能 ? </li></ul></ul>
  22. 22. <ul><li>まとめ & おまけ </li></ul>
  23. 23. まとめ <ul><li>オススメの Comet サービス構成 </li></ul><ul><ul><li>Comet 接続は別 hostname </li></ul></ul><ul><ul><li>iframe + XHR </li></ul></ul><ul><li>プログラミングモデルは発展途上 </li></ul><ul><li>パフォーマンスを狙うなら独自サーバ </li></ul>
  24. 24. おまけ <ul><li>Comet に「新しい技術的問題」は無い </li></ul><ul><ul><li>問題があったとしても、 TCP/IP の歴史に答えはある </li></ul></ul><ul><ul><li>TCP で可能なことは over HTTP でも可能 </li></ul></ul><ul><ul><ul><li>see SoftEther </li></ul></ul></ul><ul><li>いかに楽に Comet するかが問題なんです </li></ul>

×