IIJ Technical WEEK HTTP/2.0で変わるWebの世界

Transcription

1 HTTP/2.0で 変 わるWebの 世 界 IIJプロダクト 本 部 戦 略 的 開 発 部 大 津 繁 樹 IIJ Technical Week 年 11 月 21 日 1

2 HTTP 転 送 サイズとリクエスト 数 の 遷 移 (2012/11~2013/11) 111 年 で 転 送 サイズ:30% 増 リクエスト 数 :8% 増 2

3 回 線 帯 域 を 増 速 していくと 3500 HTTP 経 由 のダウンロード 時 間 [ms] ページの 表 示 時 間 は こ れ 以 上 短 縮 できない 回 線 帯 域 [MBps] More Bandwidth does nt matter よりデータ 引 用 3

4 RTT(Round Trip Time)を 小 さくしていくと HTTP 経 由 のダウンロード 時 間 [ms] ちゃんと 下 がる RTT[ms] Webページの 表 示 速 度 を 速 くするには 回 線 速 度 増 強 よりRTT(の 影 響 )を 小 さくするかが 重 要 More Bandwidth does nt matter よりデータ 引 用 4

5 SPDY(スピーディ)とは SPDYは Googleの 社 内 プロジェクトから 生 ま れ Webページの 表 示 速 度 を 速 くするための プロトコルである 既 に2 年 以 上 に 渡 りGoogleの 全 サービスで 利 用 され TwitterやFacebook LINEなど 大 規 模 なシステムへSPDYの 導 入 が 始 まっている SPDYは HTTPの 次 期 バージョン (HTTP/2.0)のベース 仕 様 として 採 用 され 現 在 標 準 化 の 議 論 が 進 められている 5

6 SPDYを 見 るには? SPDY Indicator ブラウザの 拡 張 プラグ インを 使 うとSPDYを 使 っ ているサイトがわかる 6

7 SPDYを 見 るには? chrome://net-internals/#spdy 利 用 しているSPDYセッション をリアルタイムで 見 れる 7

8 SPDYの 歩 み 2009/11 spdy/1 仕 様 公 開 2010/01 TLS NPN 拡 張 仕 様 のドラフトリリース 2010/02 spdy/2 仕 様 公 開 2010/09 Chrome6 安 定 版 リリース SPDYがデフォルトで 有 効 になる 2011/01 Google サービスの90%がSPDY 化 完 了 のアナウンス 2011/05 spdy/3 仕 様 公 開 2011/12 FireFox11 開 発 版 に SPDY 実 装 される 2012/03 Twitter SPDY 化 開 始 2012/08 wordpress.com が SPDY 対 応 開 始 2013/01 LINEがSPDYを 利 用 していることを 公 表 Facebook が SPDY 対 応 開 始 2013/06 Win8.1 の IE11 (preview)で SPDY 対 応 していることが 判 明 2013/09 SPDY/3.1 仕 様 公 開 8

9 Chrome FireFox Opera ブラウザのSPDY 対 応 状 況 ブラウザ デスクトップ 版 モバイル 版 対 応 (Ver. 6 以 上 ) 対 応 (Ver. 13 以 上 ) 対 応 (Ver 以 上 ) 対 応 (Ver. 18 以 上 ) 対 応 (Ver.15 以 上 ) 対 応 (Ver 以 上 ) Android 標 準 ブラウザ ---- 対 応 (Ver. 3 以 上 ) Safari 未 対 応 未 対 応 Internet Explore 対 応 (Ver. 11 on WIn8.1 以 上 )? ( 標 準 でSPDYが 有 効 になったバージョンを 記 載 ) 9

10 サーバソフトのSPDY 対 応 状 況 サーバソフト node-spdy spdylay apache mod_spdy Jetty nginx(proxy 用 途 ) 言 語 Node.js C C Java C( 現 状 ver.2のみ) ( 他 に python, ruby 実 装 も) 10

11 SPDYの 利 点 1. ブラウザへのWebサイトのページ 読 み 込 み 時 間 を 短 縮 する 2. Webコンテンツの 変 更 を 必 要 としない 3. 既 存 のHTTPサーバと 互 換 性 を 保 ちつつ 簡 単 に 順 次 デプロイ(Drop-in replacement)が 可 能 である 11

12 SPDYの 特 徴 TLSと 連 携 してプロトコルを 自 動 選 択 HTTPヘッダデータの 圧 縮 優 先 度 付 全 2 重 多 重 化 通 信 サーバプッシュ 機 能 12

13 単 純 なSPDYのストリームフロー SSLハンドシェイク NPN (Next Protocol Negotiation) を 使 って SPDY 利 用 バージョンを 交 換 SYN_STREAM HTTPリクエストヘッダ 情 報 を 送 信 SYN_REPLY HTTPレスポンスヘッダ 情 報 を 送 信 クライアント DATA Frame HTTPレスポンスボディを 送 信 GOAWAY サーバー SPDYストリーム 利 用 停 止 を 通 知 13

14 SSL(HTTP/1.1)のHTTPタイムライン クライアントからサーバへの 同 時 接 続 数 が6に 制 限 14

15 SPDY/3のHTTPタイムライン 1つのTCP 接 続 上 でHTTPリクエストを 多 重 化 15

16 SPDYに 向 かないサイト 1. 多 数 のドメインに 分 割 してコンテンツを 配 置 しているサイト 2. 一 度 にダウンロードするコンテンツの 量 があ まり 多 くないサイト 3. クライアントからの 通 信 経 路 の 品 質 があまり にも 悪 いサイト 16

17 HTTP/2.0とは HTTP/1.1 の 策 定 (1999 年 ) から14 年 IETF httpbis WG で HTTP/1.1 の 仕 様 の 整 理 の 見 込 みがたった 新 しい 仕 様 を 作 る 動 きが 開 始 従 来 のHTTP/1.1のセマン ティクス 維 持 互 換 性 保 持 HTTP/1.1 Semantics HTTP/2.0 Frame Layer TLS TCP IP(v4/v6) Ethernet 17

18 年 月 HTTP/2.0 これまでの 歩 み トピック 2012 年 1 月 IETF httpbis WGでHTTP/2.0の 仕 様 検 討 開 始 することを 決 定 2012 年 11 月 3つの 候 補 案 からSPDY 仕 様 をベースにすることを 決 定 draft-00(spdy/3 仕 様 をそのまま)リリース 2013 年 1 月 第 1 回 中 間 会 議 ( 東 京 ) draft-01リリース(httpからのupgrade 方 法 を 追 加 ) 2013 年 4 月 draft-02リリース(フレームフォーマット タイプの 大 幅 な 変 更 ) 2013 年 5 月 draft-03リリース( 中 間 会 議 に 向 けて 修 正 点 の 整 理 まとめ) 2013 年 6 月 第 2 回 中 間 会 議 (サンフランシスコ) 2 候 補 案 を 合 わせたヘッダ 圧 縮 仕 様 の 採 用 を 決 定 2013 年 7 月 draft-04リリース( 最 初 の 実 装 仕 様 ) 2013 年 8 月 第 3 回 中 間 会 議 (ハンブルグ) 最 初 のHTTP/2.0 相 互 接 続 試 験 を 実 施 draft-05リリース( 接 続 試 験 結 果 を 反 映 ) draft-06リリース( 次 の 相 互 接 続 試 験 向 け 実 装 仕 様 ) 2013 年 10 月 第 4 回 中 間 会 議 (シアトル) 2 回 目 の 相 互 接 続 試 験 を 実 施 draft-07リリース( 中 間 会 議 の 議 論 を 反 映 ) 18

19 HTTP-draft-06/2.0 対 応 相 互 接 続 試 験 実 装 リスト (2013/10 時 点 ) 名 称 実 装 言 語 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 10 Ericcson MSP C proxy ( より 引 用 ) 19

20 HTTP/2.0の 特 徴 HTTP/1.1のセマンティックスは 変 えない SPDYのプロトコルアーキテクチャはそのまま 利 用 無 駄 なヘッダフィールドやフレームタイプを 統 廃 合 し 簡 略 化 SPDY/3の 実 運 用 で 明 らかとなったフロー 制 御 優 先 度 制 御 といった 課 題 へ 対 応 する TLS 利 用 を 前 提 とするSPDYに 対 し HTTP/2.0は TLS 以 外 の 接 続 も 利 用 可 能 にする CRIME 脆 弱 性 対 策 として 新 しくHTTPヘッダ 送 受 信 仕 様 を 策 定 する(ヘッダ 差 分 変 更 を 通 知 ) 20

21 HTTP/2.0 初 期 ニゴシエーション 3 種 類 で2 段 階 (その1) (1) TLS + ALPN TLS 接 続 時 にALPN 拡 張 フィールドを 利 用 して HTTP/2.0に 接 続 を 行 う (2) HTTP Upgrade HTTP/1.1の 接 続 後 Upgradeヘッダを 使 って HTTP/2.0 に 接 続 をアップグレードする (3) Direct 接 続 あらかじめサーバがHTTP/2.0 対 応 とわかってい る 場 合 直 接 第 2 段 階 の 接 続 方 法 を 行 う (DNSレコードや HTTPヘッダによるリダイレクト) 21

22 ALPN (Application Layer Protocol Negotiation) TLSハンドシェイク 1. ClientHello + ALPN 拡 張 プロトコルリストをサーバに 送 信 http/2.0,spdy/3.1,http/ ServerHello + ALPN 拡 張 クライアント サーバ 側 でプロトコルを 決 定 し 通 知 する http/ TLS 証 明 書 暗 号 化 情 報 交 換 サーバー HTTP/2.0で 通 信 22

23 ご 注 意 ください ALPN 利 用 時 の 不 具 合 発 生 例 TLSハンドシェイク 1. ClientHello + ALPN 拡 張 プロトコルリストをサーバに 送 信 http/2.0,spdy/3.1,http/1.1 クライアント ClientHelloが 255byteより 大 きい のサイズになると 接 続 がハング アップ 負 荷 分 散 装 置 サーバー 23

24 HTTP/2.0 初 期 ニゴシエーション 3 種 類 で2 段 階 (その2) PRI * HTTP/2.0 r n r n SM r n r n a f322e300d0a0d0a534d0d0a0d0a SETTINGS ( 初 期 ウィンドウサイズ ストリームの 最 大 同 時 オープン 数 等 の 設 定 情 報 を 含 む) クライアントから 謎 の24byteのマジックコードをサー バに 送 り 初 期 情 報 (SETTINGSフレームを 交 換 する) 24

25 HPACK: 新 しいヘッダ 圧 縮 仕 様 http で servera へx-hoge: hoge 付 けて GET / したいなぁ ヘッダテーブル 0, :scheme, http 1, : scheme, https 2, :host, 3, :path, / 4, :method, GET 38, x-hoge, hoge 1. 0 番 そのまま 使 う 2. 2 番 serveraに 書 き 換 えるよ 3. 3 番 そのまま 使 う 4. 4 番 そのまま 使 う 5. x-hogeは 新 しく 採 番 してhogeを 入 れ 込 む (ヘッダ 差 分 情 報 をやり 取 りする) 0x81 0x04 0x03 0x07 servera 0x83 0x84 0x40 0x06 x-hoge 0x04 hoge ( 実 際 に 送 信 するヘッダ 情 報 ) ヘッダテーブル 0, :scheme, http 1, : scheme, https 2, :host, 3, :path, / 4, :method, GET 38, x-hoge, hoge 25

26 いよいよ 本 題 HTTP/2.0でWebはどう 変 わるのか? 26

27 実 は 何 も 変 わらない 2011 年 1 月 よりGoogleサービスは 全 面 SPDY 化 Chrome ユーザは その 違 いに 気 づいただろう か? 確 かに 昔 より 表 示 が 速 く スムーズになったよう な 感 じはある いろんな 最 適 化 の 複 合 要 因 であ ろう 標 準 化 で 多 種 ブラウザーが 対 応 するだろう 27

28 サービスインフラ 視 点 では? 大 規 模 システムでは *おそらく* 変 わるので はないか? ( 手 元 に 定 量 的 なデータがない) SPDYでは TLS 利 用 によるオーバヘッドより 性 能 向 上 効 果 が 上 回 ったとの 話 も サーバリソース ネットワークリソースを 効 率 的 に 利 用 できるので 大 規 模 サービスになればなる ほどその 効 果 を 享 受 できるのではないか? 28

29 実 は 単 純 導 入 だけでは 無 理? ブラウザが 決 めるリソース 取 得 の 優 先 度 にど う 対 応 する? プロキシ 構 成 などで 異 なるトラフィックをフ ロー 制 御 して 最 適 化 を 図 れるのか? 細 かいチューニング 手 法 は 未 知 数 運 用 して サイトにあった 構 成 を 日 々の 測 定 が 大 事 29

30 その 先 の 使 い 方 ブラウザー 以 外 の 利 用 への 展 開 {key,value} + data をやり 取 りする 独 自 アプリ(LINEな ど) 原 理 的 には 接 続 後 サーバ 側 からリクエストも 可 能 ( 双 方 向 化 ) いろんな 付 加 情 報 をあらかじめ 送 りつける(DNS, Proxy, NTP 等 々) 30

31 今 後 は Internet Giants を 中 心 にHTTP/2.0の 導 入 が 進 む ( 先 行 者 利 益 を 享 受 ) 小 規 模 サイト 一 般 ユーザの 移 行 メリットは 少 な いだろう HTTP/1.1はなくならない ( 二 極 化 ) ブラウザ 側 の 対 応 も 進 み ますますHTTP/2.0に 最 適 化 されるであろう 特 にモバイル 環 境 での 性 能 改 善 に 期 待 がかか る 31