HTTP/2.0がもたらす Webサービスの進化(後半)

7,787 views
7,439 views

Published on

Published in: Technology
0 Comments
18 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,787
On SlideShare
0
From Embeds
0
Number of Embeds
2,187
Actions
Shares
0
Downloads
61
Comments
0
Likes
18
Embeds 0
No embeds

No notes for slide

HTTP/2.0がもたらす Webサービスの進化(後半)

  1. 1. HTTP/2.0がもたらす Webサービスの進化(後半) SPDY→HTTP/2.0の歩みと仕組み、 Webはどう進化するのか? IIJ 大津 繁樹 2013年11月30日 HTML5 Conference 2013
  2. 2. 自己紹介 • 大津繁樹 株式会社インターネットイニシアティブ(IIJ) プロダクト本部戦略的開発部 新技術の検証評価 – – – – SPDY,HTTP/2.0 HTML5 Node.js Kinect/Leap Motion
  3. 3. HTTP/2.0とは、 • HTTP/1.1 の策定(1999年)から 14年。 • IETF httpbis WGで HTTP/1.1仕様 改訂の見込みがたった。 • 新しい仕様を作る動きが開始 • 従来のHTTP/1.1のセマンティク ス維持。互換性保持。 • HTTP/2.0でフレーム化、新しい シンタックスを導入。 • SPDYをアイデアにしているが、 仕様提案を一般公募して決定。 HTTP/1.1 Semantics HTTP/2.0 Frame Layer TLS TCP IP(v4/v6) Ethernet
  4. 4. まさに今、HTTP/2.0絶賛開発中 HTTP-draft-06/2.0 対応相互接続試験実装リスト 名称 実装言語 Client,Server, Intermidate ニゴシエーション 1 nghttp2 C S, C, I NPN, Upgrade, Direct 2 http2-katana C# S, C ALPN, Upgrade 3 node-http2 Node.js S, C NPN, direct 4 Mozilla Firefox C++ C ALPN, NPN 5 iij-http2 Node.js S, C ALPN, NPN, Upgrade, Direct 6 Akamai Ghost C++ I NPN 7 Chromium C++ C ALPN, NPN 8 Twitter Java S, C NPN 9 Wireshark C other NPN, ALPN C proxy 10 Ericcson MSP (2013/10時点 https://github.com/http2/http2-spec/wiki/Implementations より引用)
  5. 5. HTTP/2.0の主な技術的な特徴 • • • • • • • クライアント・サーバのTCP接続数を1つに限定 3種類・2段階の初期接続方法 バイナリープロトコル 優先度付全2重多重化通信 フロー制御(コネクション・ストリームレベル) サーバプッシュ機能 HTTPヘッダに特化したデータの圧縮手法 (注:SPDYの特徴と重なる項目)
  6. 6. HTTP/2.0初期ニゴシエーション 3種類で2段階(その1) 詳細後述 (1) TLS + ALPN (2) HTTP Upgrade (3) Direct接続 TLS接続時にALPN拡張フィールドを利用して HTTP/2.0に接続を行う。 HTTP/1.1の接続後 Upgradeヘッダを使って、 HTTP/2.0 に接続をアップグレードする。 別仕様への 分離や廃止も 議論中 あらかじめサーバがHTTP/2.0対応とわかってい る場合、直接第2段階の接続方法を行う。 (DNSレコードや HTTPヘッダによるリダイレクト)
  7. 7. HTTP/2.0初期ニゴシエーション 3種類で2段階(その2) PRI * HTTP/2.0¥r¥n ¥r¥n SM¥r¥n ¥r¥n 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a SETTINGS (初期ウィンドウサイズ、ストリームの最大同時オープン数等の設定情報を含む) クライアントから謎の24byteのマジックコードをサー バに送り、初期情報(SETTINGSフレームを交換する)
  8. 8. 単純なHTTP/2.0のストリームフロー 初期ハンドシェイク (HTTP/2.0の利用を合意) HEADERS (id=0x1, END_HEADERS) HTTPリクエストヘッダ情報を送信 HEADERS (id=0x1, END_HEADERS) クライアント HTTPレスポンスヘッダ情報を送信 DATA (id=0x1, END_STREAM) HTTPレスポンスボディを送信 (ストリーム 0x1 を終了) サーバ
  9. 9. サーバプッシュ機能(予約機能) ストリーム(0x1) 予約されたリクエ ストは新しくリクエ ストしない。 HEADERS (id=0x1,index.html) PUSH_PROMISE 先読みさせるリ クエストヘッダと ストリームIDをク ライアントに予約 プロミスID: 0x2 リクエストヘッダ (/images/pic1.png) DATA(index.htmlのコンテンツ) クライアント ストリーム(0x2) サーバ HEADERS キャッシュ レスポンスヘッダ DATA レスポンスボディ サーバがコンテンツをプッシュしてクライアントにキャッシュ
  10. 10. HPACK:新しいヘッダ圧縮仕様 GET / HTTP/1.1 host: www.example.com 1. 2. 3. 4. 平均20~30%デー タ量を削減 CRIME脆弱性対応 2番の:method GETを追加 7番の:scheme http を追加 6番の :path / を追加 4番の : authority に www.example.com をハフマン符号化して追加 (ヘッダの差分情報を符号化して やり取りする) 送信前ヘッダテーブル 1. :authority, 2. :method, GET 3. :method, POST 4. :path, / 5. :path, /index.html 6. :scheme, http ・・・・ 0x82 0x87 0x86 0x04 0x8b 0 xdb 0x6d 0x88 0x3e 0x68 0xd1 0xcb 0x12 0x25 0xba 0x7f (実際に送信するヘッダ情報) 受信後ヘッダテーブル 1. :authority, www.example.com 2. :path, / 3. :scheme, http 4. :method, GET ・・・・
  11. 11. HTTP/2.0がもたらす Webサービスの進化は? • ユーザ視点では、一見なにも変わらない。 – 2011年1月よりGoogleサービスは全面SPDY化 – Chrome ユーザは、その違いに気づいただろうか? • 確かに昔より表示が速く、スムーズになったよう な感じはある。いろんな最適化の複合要因であ ろう。 • 標準化で多種ブラウザーが対応し、広く利用で きる環境が整う。HTTP/2.0に最適化されたサー ビスが数多く出てくるだろう…
  12. 12. HTTP/2.0がもたらす Webサービスの進化は? • 大規模システムでは、*おそらく*変わる。 – SPDYでは、TLS利用によるオーバヘッドより性能向上効果 が上回る。 – サーバリソース、ネットワークリソースを効率的に利用で きるので大規模サービスになればなるほどその効果を享 受できる。 • ブラウザー以外の利用への展開も進むだろう。 – {key,value} + data をやり取りする独自アプリ(LINEなど) • 原理的には接続後サーバ側からリクエストも可能(双 方向化) • いろんな付加情報をあらかじめ送りつける(DNS, Proxy, NTP 等々)
  13. 13. HTTP/2.0がもたらす Webサービスの進化は? • Internet Giants を中心にHTTP/2.0の導入が進む。 (先行者利益を享受) • 小規模サイト、一般ユーザの移行メリットは少な いだろう。HTTP/1.1はなくならない。(二極化) • ブラウザ側の対応も進み、ますますHTTP/2.0に 最適化されるであろう。 • 特にモバイル環境での性能改善に期待がかか る。
  14. 14. HTTP/2.0をめぐる 最新トピックスの御紹介 ただ今 IETF にて HTTP/2.0とインターネットセキュリティ を巡る大議論が継続中。 次世代のWebサービスのあり方が問われています。
  15. 15. インターネットの脅威 • PRISM: 情報収集・通信監視 • Quantum: バックボーンMITM • Fox Acid: 脆弱性攻撃 • MUSCULAR: データセンター内通信傍受 など・・・・ (写真出典 wikipedia)
  16. 16. Webを今後どうするか? IETF-88 httpbis ワーキングループの議論 1. 現状のままなにもしない。 2. http://~ は、サーバ認証せず暗号化する (Opportunistic Encryption:日和見暗号) 3. http://~ は、サーバ認証と暗号化する 4. HTTP/2.0 では https:// の利用を必須 (Openな環境でHTTP/2.0の利用をSSLに限定) 会場では 3 か 4 の賛成が主流だったが…
  17. 17. HTTP/2.0をhttps(暗号化必須)に限定する? 仕様策定する IETF httpbis WG議長から提案 HTTPのセキュリティをもっと改善しよう (Moving forward on improving HTTP's security)
  18. 18. HTTP/2.0をhttps(暗号化必須)に限定する? 賛成意見 • 広範囲なネット盗聴・監視に対抗できる • 既存のネット環境にすばやく導入可能 • TLSのALPN拡張と組み合わせて初期接続時間 の短縮が図れる • Chrome/Firefoxは、平文(http://~)での HTTP/2.0 通信は実装しないと明言 – Microsoftは、平文でのHTTP/2.0通信をサポートと 明言
  19. 19. HTTP/2.0をhttps(暗号化必須)に限定する? 反対意見 • Proxy機能が損なわれる – 負荷分散、CDN、マルウェア対策、コンテンツフィ ルタリング等々に必須な機能 • 人々に絶対に安全であると勘違いさせる – PKIシステムの不全 – 暗号アルゴリズムの危殆化 – 通信経路以外での盗聴、改竄のリスクの存在
  20. 20. HTTP/2.0をhttps(暗号化必須)に限定する? 反対意見 • 適応範囲の問題 – 機密性の少ない一般公開コンテンツにも暗号化 は無駄 – そもそもHTTP/2.0の設計と暗号化は独立した別 問題 – 結局サービスプロバイダーがメールのスキャンな どしているので通信だけ守っても無駄
  21. 21. HTTP/2.0をhttps(暗号化必須)に限定する? 反対意見 • 倫理/ポリシーの問題 – 暗号化は一部のネット大手が通信の干渉を嫌っ てしていること – ユーザの同意なしに全部暗号化するのは問題 – ネット監視は技術的な問題ではなく政治的な問題 • 実質的な問題 – 証明書コスト、システム負荷の増加 – IoT(Internet of Things)に暗号化は不要な機能 – 平文通信が必要なら仕様に関係なく使い始める
  22. 22. HTTP/2.0 わかれる議論 SSLに限定  非暗号化も許す 技術的な優劣の判断になりにくい。 新たな提案: • 非暗号化用に http2://~ +新TCPポート を新設しよう か? • HTTP/2.0仕様の枠内で新規に暗号化を行うよう仕様 を追加するか? まだどこに落ち着くか全く見通せない。 しかし、 HTTP/2.0の動向がインターネットサービスのセ キュリティ動向に大きく影響を与えるのは間違いない。
  23. 23. デモンストレーション • HTTP/2.0は開発中であるため、SPDYでデモン ストレーションを行います。 • SSL、SPDY, SPDY+サーバプッシュ の3通りで同 じコンテンツをアクセスしてみます。 • 違いがわかるでしょうか?
  24. 24. 質問タイム
  25. 25. 視聴者からの素朴な質問 (その1:Q) Q: バイナリープロトコルだと telnet でアクセス できなくなっちゃうんですけど・・・
  26. 26. 視聴者からの素朴な質問 (その1:QA) • Q: バイナリープロトコルだと telnet でアクセ スできなくなっちゃうんですけど・・・ • A: あきらめてください。 テキストプロトコルに よる弊害(曖昧さ、パースのオーバヘッド)の 方が大きいからです。きっと便利なツールが 出てくるでしょう。
  27. 27. 視聴者からの素朴な質問 (その2:Q) Q: HTTP/2.0 は複雑過ぎて、流行らないんじゃ ないか?
  28. 28. 素朴な疑問(その2:QA) Q: HTTP/2.0 は複雑過ぎて、流行らないんじゃ ないか? A: はい、流行りません。 一部のサービス大手 のための利用が主目的ですから。
  29. 29. アンケートにご協力ください! あなたのフィードバックが、 html5jの活動を支えています! http://bit.ly/html5C201311 アンケートへ答えた方にもれなく記念品プレゼント! (アンケートの完了画面を1F受付にてご提示ください) お知らせ: 最終スペシャルセッションの開始時刻が変更になりました(18:30→18:20) 10分早まっています。ご注意ください!

×