ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先

Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
ウェブを速くするために
DeNAがやっていること
HTTP/2と、さらにその先
DeNA Co., Ltd.
Kazuho Oku
1

DeNAは○○の会社
2ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先

DeNAはウェブの会社

 ウェブ技術を使ったサービス群
⁃ Mobage
⁃ DeNAショッピング・モバオク
⁃ DeNA Palette
⁃ …
 スマホアプリも HTTP や WebView を使用

(まあ、だいたい)

ウェブ基盤技術の研究開発

ウェブ基盤技術の研究開発
 ２種類のアプローチ
⁃ スループットの最適化
⁃ レスポンスタイムの高速化
 メリットは何?

スループットの最適化＝コスト削減
 HandlerSocket
⁃ DeNA の樋口が開発
⁃ MySQL Conference Community Awards 2011 受賞
 HandlerSocket とは?
⁃ MySQL サーバむけ KVS プロトコル実装
⁃ 単純なクエリに SQL を使わないことにより、大量の
接続を高速に処理
⁃ 効果:
• スレーブ台数とネットワーク負荷を削減
• サーバが数千台規模だと、削減コスト>>開発費

レスポンスタイム削減＝売上増大
出典: http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html

本日のテーマ
 HTTP/2 の基本
 HTTP/2 の最適化
⁃ レスポンスタイム最適化
⁃ スループット最適化
 H2O と他ソフトウェアの実装の話を織り交ぜつつ

H2O
 DeNA で開発している HTTP/2 サーバ
⁃ 中の人: Kazuho Oku (me)
 タイムライン:
⁃ 2014年7月: 開発開始
⁃ 2014年12月: 初回リリース (0.9.0)
⁃ 2014年2月: 1.0リリース
• HTTP/2策定作業の完了と同時
⁃ 現在: 1.7.0beta-4
 スループットとレスポンスタイムの双方で、おそらく世
界最速の HTTP/2 実装

HTTP/2 誕生の背景

転送データ量は増大中
出典: http://httparchive.org/trends.php?s=All&minlabel=Aug+1+2011&maxlabel=Aug+1+2015#bytesTotal&reqTotal

バンド幅も増大中
 エンドユーザのバンド幅は年率50%で増加（ニールセン
の法則）
出典: http://www.nngroup.com/articles/law-of-bandwidth/

未来はバラ色？

ページロード時間はバンド幅に比例しない
出典: More Bandwidth Doesn't Matter - 2011 Mike Belshe (Google)
※実効バンド幅は1.6Mbps程度で頭打ちに

ページロードはレイテンシが小さいほど速い
出典: More Bandwidth Doesn't Matter - 2011 Mike Belshe (Google)

Why?

HTTP/1.1は多重性がない
RTT
request
response
request
response
client server
…
RTT
 HTTP/1.1では、1RTTあたり1リクエスト/レスポンスし
か送受信できない
⁃ RTT=ラウンドトリップタイム
• レイテンシの大きさを表す値
 緩和策:複数のTCP接続を使う
⁃ 同時6本が一般的
• 1RTTあたり6リクエスト!!!
• それでも遅い

HTTP/1.1パイプラインの問題
RTT
requests
responses
client server
 仕様上、レスポンス受信前に次のリクエストを送信可能
 問題:
⁃ 切断時に、レスポンス未受信のリクエストを再送信し
ていいかわからない
• サーバが同じリクエストを複数回処理する可能性
⁃ 先行リクエストの処理に時間がかかると後続が詰まる
(head-of-line blocking)
⁃ バグのあるサーバ実装が多い

レイテンシは今後も小さくならない
 光の速度はかわらない
⁃ アメリカまで光ファイバーで往復すれば80ミリ秒
 携帯回線はレイテンシが大きい
⁃ LTE ~ 50ms

やばい！ウェブが遅くなってきた！

どうしよう？

解決策：レイテンシに負けないプロトコルを作る

HTTP/2!

HTTP/2
 RFC 7540 (2015/5)
⁃ Google の QUIC プロトコルの実験を参考に規格化
 基本的な技術要素
⁃ バイナリプロトコル
⁃ 多重化
⁃ ヘッダ圧縮

バイナリプロトコルな理由
 脆弱性を防ぐ
⁃ HTTP Request/Response Splitting Attack
• HTTP/1.1のパーサによる解釈の差をつく攻撃
 転送データ量の低減
⁃ 細かな粒度でレスポンスの順序を変更したい
• 転送単位が小さいなら、その単位毎につけるヘッダは小さ
くないといけない → バイナリにするしかない
⁃ ヘッダ圧縮
• 圧縮するんだから、どのみちバイナリ
 全てのデータは、「フレーム」に分解して送受信

典型的な通信フロー
（クライアントが送信）
GET / HTTP/1.1
Host: example.com
User-Agent: MySuperClient/1.0
（サーバが送信）
HTTP/1.1 200 OK
Date: Thu, 20 Aug 2015 06:48:36 GMT
Server: Apache/2.2.29 (Unix)
Last-Modified: Wed, 12 Mar 2014 05:03:17…
ETag: "50b5e5-33a-4f461c1300f40"
Content-Length: 826
Content-Type: text/html
<html>
…
HEADERSフレーム（クライアント送信）:
:method: GET
:scheme: https
:authority: example.com
:path: /
user-agent: MySuperClient/1.0
HEADERSフレーム（サーバ送信）:
:status: 200
date: Thu, 20 Aug 2015 06:48:36 GMT
server: Apache/2.2.29 (Unix)
last-Modified: Wed, 12 Mar 2014 05:03:…
etag: "50b5e5-33a-4f461c1300f40"
content-length: 826
content-type: text/html
DATAフレーム（サーバ送信）:
<html>…

多重化
 同時に100以上のリクエストを発行可能
 任意のタイミングでリクエスト送信可能
 レスポンスの順序に制限なし
 レスポンスを織り交ぜ可能
⁃ DATAのstream IDを見よ
client server
…

ヘッダ圧縮 (1)
 HTTP/1.1のヘッダは大きい
⁃ リクエスト:
• 最低でも300バイト程度
• Google Analytics使うとCookieで+200バイトなど
⁃ レスポンスも通常300バイト程度
 100個レスポンスを受け取るなら、それだけで30KB
⁃ レイテンシがなくなるなら、ヘッダサイズも小さくし
たい
• 大量に 304 Not Modified を返すこととかありますよね

ヘッダ圧縮 (2)
 HPACK (RFC 7541) として規定
 技術要素
⁃ 初見の文字列は、静的ハフマン圧縮
⁃ ２回目以降は、前回出現時からのオフセットで表現
⁃ 頻出文字列は、固定テーブルのインデックスで表現

ヘッダ圧縮 (3)
 想定例:
⁃ https://example.com/ にアクセス
⁃ 参照されている /banner.jpg と /icon.png をロード

ヘッダ圧縮 (4)
 / へのリクエスト
(圧縮前: 291バイト)
:method: GET
:scheme: https
:path: /
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:40.0) Gecko/…
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language: ja,en-US;q=0.7,en;q=0.3
accept-Encoding: gzip, deflate
(圧縮後: 147バイト)
02 # :method: GET
07 # :scheme: https
41 88 2f 91 d3 5d 05 5c 87 a7 # :authority: example.com
04 # :path: /
7a bc d0 7f 66 a2 81 b0 da e0 53 ...(46 bytes) # user-agent: ...
53 b0 49 7c a5 89 d3 4d 1f 43 ae ...(50 bytes) # accept: ...
51 93 e8 3f a2 d4 b7 0d df 7d a0 ...(21 bytes) # accept-language: ...
10 # accept-encoding: ...

ヘッダ圧縮 (5)
 /banner.jpg へのリクエスト
:method: GET
:scheme: https
:path: /banner.jp
accept: image/png,image/*;q=0.8,*/*;q=0.5
accept-encoding: gzip, deflate
referer: https://example.com/
02 # :method: GET
07 # :scheme: https
c1 # :authority: example.com
44 89 62 31 d5 51 6c 5f a5 73 7f # :path: /banner.jpg
c1 # user-agent: …
53 9a 35 23 98 ac 57 54 df 46 a4 ...(28 bytes) # accept: ...
c0 # accept-language: ...
73 8f 9d 29 ad 17 18 60 be 47 4d ...(17 bytes) # referer: ...

ヘッダ圧縮 (6)
 /icon.png へのリクエスト
:method: GET
:scheme: https
:path: /icon.png
accept: image/png,image/*;q=0.8,*/*;q=0.5
accept-encoding: gzip, deflate
referer: https://example.com/
02 # :method: GET
07 # :scheme: https
c4 # :authority: example.com
44 87 60 c4 3d 4b d7 54 df # :path: /icon.png
c4 # user-agent: …
c0 # accept: ...
c2 # accept-language: ...
bf # referer: ...

ヘッダ圧縮 (7)
 最初のリクエストでもそこそこ圧縮される
 画像等アセットへのリクエストが繰り返すとすごい縮む
⁃ レスポンスも同様
リクエストパスヘッダサイズ（圧縮前，バイト）ヘッダサイズ（圧縮後，バイト）圧縮率
/ 291 147 50.5%
/banner.jpg 300 62 20.7%
/icon.png 298 17 5.7%

ここまでのまとめ
 HTTP/2の基本
⁃ 多重化によりレイテンシの影響を低減
⁃ ヘッダ圧縮により通信量を低減
 上記２点を体感できるデモ
⁃ https://www.symfony.fi/entry/compare-
resource-loading-between-http-2-and-http-1-1

HTTP/2 におけるレスポンスタイム最適化

HTTP/2のレスポンスタイムベンチマーク
 コンテンツ系ウェブサイトが表示されるまでの時間測定
 初期描画(first-paint)までの時間に大差、H2O が最短

差が出た理由: 優先度制御

HTTP/2 の規定する優先度制御
 クライアントがリクエスト毎に優先度を指定する
⁃ ２種類の制御手法の組み合わせ
• 重みづけ (weight)
⁃ 値に比例したバンド幅の配分
• 依存関係 (dependency)
⁃ 依存されているレスポンスを先に送信
⁃ グループ化にも利用
 サーバは指定された優先度を「参考にする」

Firefox の優先度制御実装

Firefox の優先度制御
Root
Leader
weight: 201
Follower
weight: 1
Unblocked
weight: 101
 1. 初期状態（接続直後）

Root
Leader
weight: 201
Follower
weight: 1
HTML
weight: 32
Unblocked
weight: 101
 2. HTML受信開始

Root
Leader
weight: 201
Follower
weight: 1
HTML
weight: 32
CSS
weight: 32
JS (HEAD)
weight: 32
Unblocked
weight: 101
 3. <HEAD>にあったCSSとJavaScriptをリクエスト
⁃ CSS/JSを圧倒的に優先
• Follower vs. CSS/JS の weight は 1:32:32:32…

Root
Leader
weight: 201
Follower
weight: 1
HTML
weight: 32
Unblocked
weight: 101
 4. CSSとJavaScriptの受信完了
⁃ HTMLの<BODY>部も届き始める
⁃ first paint (ウェブページをレンダリングできるぞ！)

Root
Leader
weight: 201
Follower
weight: 1
HTML
weight: 32
Image
weight: 22
Image
weight: 22
Image
weight: 22
Unblocked
weight: 101
 5. <BODY>にあった<IMG>の画像をリクエスト
⁃ 画像はHTMLよりちょっと低めのweight
• ブラウザ画面では画像がじわじわ表示

Root
Leader
weight: 201
Follower
weight: 1
HTML
weight: 32
Image
weight: 22
Image
weight: 22
Image
weight: 22
Unblocked
weight: 101
JS (BODY)
weight: 32
 6. <BODY>末尾のJavaScriptは別の優先度で

Root
Leader
weight: 201
Follower
weight: 1
Image
weight: 22
Image
weight: 22
Image
weight: 22
Unblocked
weight: 101
JS (BODY)
weight: 32
 7. HTMLの配信完了

Root
Leader
weight: 201
Follower
weight: 1
Image
weight: 22
Image
weight: 22
Unblocked
weight: 101
 8. JavaScriptの配信も完了
⁃ DOMContentLoaded

Root
Leader
weight: 201
Follower
weight: 1
Unblocked
weight: 101
 9. 全てのダウンロードが完了
⁃ onload event

Root
Leader
weight: 201
Follower
weight: 1
HTML
weight: 32
Image
weight: 22
Image
weight: 22
Image
weight: 22
CSS
weight: 32
JS (HEAD)
weight: 32
Unblocked
weight: 101
JS (BODY)
weight: 32
 まとめ:
⁃ 優先度（図の縦方向）と重みづけを併用
⁃ リソースの「利用形態」にあわせて優先度を設定

H2O の優先度制御実装

 H2O は
⁃ Webブラウザの指示に従い、バンド幅を配分
• 割当は HTTP/2 の規定どおり
⁃ 優先度制御の粒度が細かい
• 16KB単位でストリームを切り替え
• 約64KB単位でバッファリング
 全ての HTTP/2 サーバが優先度制御を（正しく）実装し
ているわけではない

 優れた優先度制御の要件: weighted fair queuing
⁃ 次に送信すべきストリームを、queue の中から
• 重み (weight) に基づいて
• 公平 (fair) に選択
 H2O の wfq は、リングバッファを使用した O(1) 実装
⁃ ツリーの深さに対しては高速な O(n)
• タイトなループなので高速
⁃ 高速な実装 → 細粒度で送信ストリームを切替可能
 他の HTTP/2 実装も wfq を採用へ
⁃ nghttp2, Apache (mod_h2), hyper, ...

他のWebブラウザの優先度制御実装

優先度制御 (Chromeの場合)
 重みづけのみを使用（依存関係は未使用）
 HTTP/2でfirst-paintは劣化
0 0.5 1 1.5 2 2.5 3
Nginx (HTTP/1.1)
Nginx (SPDY/3.1)
H2O (HTTP/2)
Chrome/43
Download Timing (unit: seconds, latency: 100ms)
first paint load complete

 1. HTMLを受信開始
Root
HTML
weight: 256

 2. <HEAD>をパース、CSSとJSをリクエスト
Root
HTML
weight: 256
CSS
weight: 220
JS
weight: 183

 3. <BODY>が徐々に到着、画像もリクエスト
⁃ この時点でのバンド幅の配分は？
• HTML:CSS:JS:Image*3 = 256:220:183:330
• CSSやJSよりも画像のほうがバンド幅を食ってる
⁃ これではfirst-paint が早くならない
Root
HTML
weight: 256
CSS
weight: 220
JS
weight: 183
Image
weight: 110
Image
weight: 110
Image
weight: 110

優先度制御 (他のウェブブラウザの場合)
 Edge – 優先度制御なし
 Safari – 優先度制御なし
 サーバ側でなんとかしないと…
Root
HTML
weight: 16
CSS
weight: 16
JS
weight: 16
Image
weight: 16
Image
weight: 16
Image
weight: 16

H2O による優先度の書き換え
 クライアントが依存関係ツリーを構築しない場合に
 レンダリングをブロックしそうな content-type のレス
ポンスを最優先で配信
Root
HTML
weight: 16
CSS
weight: max
JS
weight: max
Image
weight: 16
Image
weight: 16
Image
weight: 16
(internal root)

H2O の reprioritize-blocking-assets オプション
 first paint が大幅に改善
0 0.5 1 1.5 2 2.5 3
Nginx (HTTP/1.1)
Nginx (SPDY/3.1)
H2O (HTTP/2)
H2O+repriori ze (HTTP/2)
Chrome/43
Download Timing (unit: seconds, latency: 100ms)
first paint load complete

優先度制御まとめ
 ユーザの体感速度を大幅に向上させる技術
⁃ first-paint time が改善するため
 クライアント側:
⁃ Firefox – すばらしい
⁃ 他のWebブラウザ – 要改善
 サーバ側:
⁃ 実装状況がまちまち
⁃ H2O は Firefox 以外のブラウザむけの最適化も実装

サーバプッシュ

 HTTP/2はRTTを隠蔽する技術
 でも、1RTT（リクエストを投げてからレスポンスを受け
取るまで）は絶対かかるよね？
 それ、0RTTでできるよ！
⁃ サーバが、クライアントの発行するリクエストを予測
して、レスポンスをプッシュすればいい
※これ以外の目的でも使える技術ですが、今回はウェブブラ
ウザのレスポンスタイムに絞った議論をします

 例: RTT=50ms, アプリサーバの処理時間=200ms
req.
processrequest
push-asset
HTML
push-asset
push-asset
push-asset
req.
processrequest
asset
HTML
asset
asset
asset
req.
450ms(5RTT+processingme)
250ms(1RTT+processingme)
without push with push

 CDNによるウェブ高速化にも応用可能
⁃ アプリサーバの応答を待つ間も回線を有効活用可能
⁃ アプリ提供者は、その分、アプリサーバの設置拠点を
減らすことが可能に
req.
push-asset
HTML
push-asset
push-asset
push-asset
client edge server (CDN) app. server
req.
HTML

 実用にむけた課題:
⁃ （クライアントに頼らない）優先度制御
⁃ プッシュの起動方法
⁃ ブラウザキャッシュとの兼ね合い

サーバプッシュと優先度制御
 RFC どおり実装してあっても、あまり役に立たない
⁃ プッシュされるレスポンスは、プッシュを
起動したレスポンスに依存する形でスケ
ジュールされるから
 H2O は、プッシュの mime-type を見て優先度を決定
⁃ reprioritize-blocking-assets と同様
HTML
weight: ??
CSS (pushed)
weight: 16

サーバプッシュの使い方 (1)
 Link: rel=preload ヘッダ
⁃ アプリサーバが返す Link ヘッダを認識してプッシュ
HTTP/1.1 200 OK
Content-Type: text/html
Link: </style.css>; rel=preload # このヘッダ!!!
⁃ H2O, nghttpx (nghttp2), mod_h2 (Apache) が対応
⁃ 問題: アプリサーバが応答を返すまでプッシュ不可能

サーバプッシュの使い方 (2)
 H2O では、アプリサーバへリクエストを転送する前にプ
ッシュを開始可能
# 1. mrubyハンドラでプッシュを開始 (Linkヘッダをセット)
mruby.handler: |
Proc.new do |env|
[399, { "Link" => "</style.css>; rel=preload" }, []]
end
# 2. リバースプロキシハンドラがアプリサーバにリクエストを転送
proxy.reverse.url: http://app.example.com:8080/

サーバプッシュ vs. ブラウザキャッシュ
 キャッシュ済のファイルはプッシュしたくない
⁃ バンド幅（と場合によっては時間）のムダ
 キャッシュの有無を判断する方法は?
⁃ ブラウザキャッシュ内の状況を確認するためにリクエ
スト/レスポンスを送信してはいけない
• そのために1RTTかかるとプッシュのメリットがなくなる

cache-aware server-push
 H2O 1.5 以降で実装 (experimental)
 ブラウザキャッシュ内の CSS, JS を fingerprinting
⁃ Golomb coded sets (bloom filterの圧縮版) を使用
 fingerprint を全てのリクエストに cookie として添付
⁃ cookie サイズは100バイト程度
• さらに HPACK による圧縮が効く
⁃ ServiceWorker を使った実装も開発中 (jxck氏)
 H2O は fingerprint を基に、ウェブアプリの要求するプ
ッシュを実際に行うか判定
⁃ プッシュした場合は fingerprint を更新

 cookieを使うアプローチの問題:
⁃ Webブラウザキャッシュに何が入ってるか、ブラウザ
以外には正確には分からない
⁃ cookieは消される可能性／細かな更新が困難
 理想的には、Webブラウザが fingerprint を送信すべき
↓
 2014/10: 関係者と議論 @ http2/quic meetup
 2015/01: インターネットドラフト(RFC化の提案)を提出
(共著者: Mark Nottingham)
mod_h2 (Apache) がドラフトを実装

 fingerprint を含むリクエストの例
:method: GET
:scheme: https
:path: /
cache-digest: IdrjaOrSB4wfpbxdx5Q/
⁃ この cache-digest ヘッダは、以下12の URL がキャ
ッシュ済であることを示している
https://example.com/assets/css/bootstrap.min.css,
https://example.com/assets/css/font-awesome.css,
https://example.com/assets/css/header.css,
https://example.com/assets/css/magnific-popup.css,
https://example.com/assets/css/main.css,
https://example.com/assets/css/pinstrap.css,
https://example.com/assets/css/pinterest.css,
https://example.com/js/bootstrap.min.js, https://example.com/js/jquery-1.11.0.js,
https://example.com/js/jquery-ui.min.js, https://example.com/js/jquery.magnific-
popup.js, https://example.com/js/pinterest.js 76ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先

サーバプッシュまとめ
 ポテンシャルはあるが使いにくい（と思われてきた）
⁃ H2O がそれらの問題を解決
⁃ 今後の期待:
• 仕様の標準化
• ウェブブラウザや、他のサーバでの実装

レスポンスタイム最適化まとめ
 HTTP/2 はユーザの待ち時間を最適化
⁃ ユーザ体験向上と売上増加につながると考えられる
 HTTP/2 の基本要素
⁃ 多重化によるレイテンシの隠蔽
⁃ バイナリ化による通信データ量の削減
 どれだけ高速になるかはサーバの実装依存
⁃ 優先度制御
⁃ サーバプッシュ

HTTP サーバのスループット最適化

ベンチマーク:静的ファイルの配信
 ベンチマーク環境: AWS c3.8xlarge (2台)
⁃ クライアントとサーバは、同一network placement
 ファイルサイズ: 612バイト (デスクリプタキャッシュ:on)

HTTP/2 は高スループットなプロトコル
 HTTP/2 over TLS は、暗号化のない HTTP/1 と同等か
より高速
⁃ TLS の負荷は HTTPS に移行しない理由にならない

なぜ H2O は速いのか
 ステートマシンを極力廃した設計
 SIMD 命令でチューニングされた HTTP/1 パーサ
 HTTP/2 と TLS を前提にした設計
⁃ ヘッダを文字列ではなく、ポインタ演算で比較
⁃ 大量のレスポンスをマージして、できるだけ少ないシ
ステムコールで送信

H2O - その他の特徴
 (m)rubyによるスクリプティング:
⁃ mod_rewriteよりも保守しやすい
⁃ Rack 標準に則っている → ベンダロックインが発生
しない
 先進のTLSサポート:
⁃ セッションキャッシュのサーバ間共有
⁃ セッションチケットのマスター鍵の自動更新
⁃ レコードサイズの最適化
⁃ 自動化されたOCSPステープリング

まとめ

まとめ
 HTTP/2 が約束する未来はバラ色
⁃ より短いレスポンスタイム
⁃ より高いスループット
 H2O が、HTTP/2 サーバ実装の競争をリード
⁃ 優先度制御／サーバプッシュ／スループット
 DeNA は、H2O の成果を社会に還元
⁃ OSS として世界と共有
• H2O は DeNA 単独ではなく OSS コミュニティの成果
⁃ IETF 等での標準化

ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先

More Related Content

What's hot

Viewers also liked

Similar to ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先

More from Kazuho Oku

ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先

Editor's Notes