HTML5 Conference 2015 資料 「HTTP/2の現状とこれから」

1. HTTP/2の現状とこれから
大津 繁樹
株式会社インターネットイニシアティブ(IIJ)
HTML5 Conference
2015年1月25日

2. 自己紹介
• 名前： 大津 繁樹
• 所属： 株式会社インターネットイニシアティブ(IIJ) アプリケーション開発部
• Twitter: @jovi0608
• ブログ： ぼちぼち日記 http://d.hatena.ne.jp/jovi0608/
• GitHub: https://github.com/shigeki/
• 新技術の検証・評価を行ってます。 (Node.js, io.js,SPDY, HTTP/2,HTML5)
• iij-http2の開発を通じてIETFのHTTP/2標準化作業に参画中

3. HTTP/2 はRFC化目前です
• HTTP/2
• IESGレビュー終了。コメントを受け
てドラフトを改訂。その後承認見込
• HPACK
• IESG承認済(1/23)
発行プロセスが順調なら桜が咲く前にはRFC化かも
Ethernet
IP(v4/v6)
TCP
TLS
HTTP/2
Frame Layer
HTTP/1.1
Semantics

4. 内容
• これまで
• HTTP/1.1の問題点のおさらい (+デモ)
• 現状 (SPDY, HTTP/2)
• SPDY, HTTP/2の対応状況
• HTTP/2の最終仕様の概要 (いくつかピックアップ)
• これから
• HTTP/2の拡張 → HTTP/3の展望
• HTTP/2の応用：WebPush + Push API (Service Worker+ Server Push)
• 新プロトコル： QUIC （+デモ）

5. これまで
(HTTP/1.1の問題点のおさらい)

6. HTTPプロトコルの年表
1990 1995 2000 2005 2010 2015
Webの
始まり
HTTP/0.9 HTTP/1.0
RFC1945
HTTP/1.1
RFC2068
HTTP/1.1
RFC2616
HTTP/1.1
RFC7230-5
HTTP/2
SPDY/2
SPDY/3
SPDY/3.1
httpbis WG
暗黒の時代
HTTP-NG
中止

7. HTTP/1.1の問題点のおさらい
1. HTTP Head of Line Blocking
2. ネットワーク通信の利用が非効率
3. 曖昧でテキスト処理が煩雑

8. 1. HTTP Head of Line Blocking
クライアント サーバ
HTTP/1.1
1本のTCP接続
HTTP リクエスト
HTTPレスポンス
待ち時間
HTTP リクエスト

9. HTTP/1.1
ブラウザは最大同時4～6TCP接続に制限
最大同時並列6

10. HTTP/2
100以上の同時リクエストが可能
全部同時

11. HTTP/2の全二重多重化通信
クライアント サーバ
１つの
ＴＣＰ接続
ストリーム(id:1)
フレーム
フレーム
ストリーム(id:3)
フレーム
フレーム
ストリーム(id:5)
フレーム
フレーム
HTTP
リクエスト
レスポンス
HTTP
リクエスト
レスポンス
HTTP
リクエスト
レスポンス
仮想的なストリームチャンネルを生成して多重化を実現
後でデモします。

12. 2. HTTP/1.1はネットワーク通信の利用が非効率
クライアント サーバ
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
それぞれのTCP接続が独立して輻輳制御を行う

13. HTTP/1.1は非効率なプロトコル
0
10
20
30
40
50
60
10 15 20 25 30 35 40 45
輻輳ウィンドウサイズ(mss)
時間(sec)
HTTP/1.1+SSLの輻輳ウィンドウサイズの変遷
SSL1
SSL2
SSL3
SSL4
SSL5
SSL6
6本のTCPがバラバラに
輻輳制御。帯域を有効
に使いきれてない

14. HTTP/2(SPDY)は効率的なプロトコル
0
10
20
30
40
50
60
60 65 70 75 80 85 90 95
輻輳ウィンドウサイズ(mss)
時間(sec)
SPDY利用時の輻輳ウィンドウサイズの変遷
SPDY
1本のTCPで最高速まで利
用。帯域を最大限に効率的
に使っている。

15. 3. HTTP/1.1は処理が煩雑なテキストプロトコル
HTTP/1.1 200 OK
Content-Type: image/jpeg
Transfer-Encoding: chunked
Trailer: Foo
123
{binary data}
0
Foo: bar
Status-Lineは一行目 空白は1つ
ヘッダ名は大文字・小文
字区別せず
ヘッダ領域の区切り
はCRLF一つ
:の後に空白を許可
CRLFで改行、複数行
対応は廃止
レスポンスデータがchunkedであ
り、サイズはまだ不定
一番最後にFooヘッダが付与
されることを宣言
続くデータが123バイト
であることを宣言
データ終了の合図
Trailヘッダ
chunk終了合図
のCRLF

16. HTTP/2はきっちりしたバイナリープロトコル
00 00 00 01
01 04
00 00 1a
88 5c 82 08
・・・・・・
73 ff
00 00 00 01
00 00
00 00 7b
{binary data}
:status = 200
content-length = 123
content-type = image/jpeg
trailer = Foo
HEADERS
DATA
フレーム長：28バイト
フレーム長：123バイト
フレームタイプ：HEADERS, END_HEADERSフラグ
ストリームID: 1
ストリームID: 1
フレームタイプ：DATA, フラグなし
(* 記載スペースの都合上Trailer HEADERSは省いています）
データの
位置・サイズ・型
が明確

17. デモ：
HTTP/2(SPDY)は、本当にHTTP Head of Line Blocking
を回避できているのか？
クライアント
画像サーバA
画像サーバB
Reverse
Proxy
HTTP/2
多重化通信
レスポンスが速い
レスポンスが遅い

18. デモ: SPDY 対 SSL(HTTP/1.1)
HTTP Head of Line Blocking の違い
1. 少数画像 ｖｓ 多数画像。
2. 3枚目の画像毎に3秒のレスポンス遅延を入れる。

19. 現状
(SPDY, HTTP/2)

20. SPDYのブラウザ対応状況
http://caniuse.com/#feat=spdy
ほとんどのブラウザーが対応済。
HTTP/2仕様策定完了後はHTTP/2に移行見込み

21. HTTP/2の対応状況
• Firefox35: デフォルト有効(h2-14)
• Chrome41: デフォルト有効(h2-14)
• IE on Windows10 Technical Preview: h2-14
• Google: h2-14,h2-15
• Twitter: h2-15
(注： h2-15とh2-14は技術的に同じ仕様です)

22. HTTP/2を見るには？
Chrome
chrome://net-internals/#spdy
Firefox
デバッグログ見る
しかない。
利用プロトコル名
はレスポンスヘッ
ダに付与

23. HTTP/2の最終仕様概要
• 前回のHTML5 Conference でも話をしましたので、
http://www.slideshare.net/shigeki_ohtsu/html5-conf2013-http2iijohtsu
更新された中でいくつかトピックスを紹介します。

24. HTTP/2プライオリティ
クライアント Reverse
Proxy
コンテンツ
HTML
画像
CSS, jS
HTML
CSS JS
画像１ 画像2 画像3 画像4
依存性と重みを指定
weight:16 weight:16
プライオリティのユースケース
• ファイルタイプ(HTML/CSS/JS/画像）に応じ
た返答順序の指定
• タブ切り替えによる重みの上げ下げ
• 分割されたビデオデータなど順番が明示的
に決められている場合

25. Firefox38のプライオリティ依存機能(h2-16)
Stream:0x0
Stream:0x3
Leader
Stream:0x5
Unblocked
Stream:0x7
Background
weight:201 weight:1
weight:101
Stream:0xb
Follower
Stream:0x9
Speculative
weight:1
weight:1
css,js
ファイル
html,images等
その他
XHR
非同期js
明示的な
バックグラウンド
リクエスト
beacon等
大きなバック
グラウンド
リクエスト
idle
ストリーム

26. HTTP/1.1セマンティクスと非互換なところ
• ホップ-バイ-ホップ ヘッダの利用禁止
• ホップ-バイ-ホップ間の通信制御はHTTP/2フレームの役割であるため、
HTTPヘッダによる制御を禁止。
• Connection, Transfer-Encoding, TE, Upgrade, Keep-Alive, Proxy-Connection
ヘッダは利用禁止。
• TE: trailers だけ例外
• Status Code: 101 (Switching Protocols) も禁止
クライアント プロキシ プロキシ プロキシ サーバ
hophop hop
End-To-Endヘッダだけ許可

27. TLS利用条件の厳格化
• HTTP/2は、仕様上平文での接続(http://)も規定されており、TLS利用は
必須ではなくなりました。
• ただしChromeやFirefoxではTLS利用したHTTP/2のみサポート。MSが
HTTP/2の平文通信に賛同しているが、IEでの実装はまだ。
• HTTP/2の利用は実質的にTLSを用いたものが中心になる見込み。
• 現行のTLS1.2でもまだセキュリティ的に十分でないのでTLS利用条件を
厳格化して対応
• renegotiation, compressionの禁止
• SNI利用の必須
• PFS(Perfect Forward Secrecy), AEAD利用の必須(RC4,CBCモード利用禁止)
• 検討中のTLS1.3の仕様を先取りしたもの

28. これから
(拡張、応用、新プロトコル)

29. HTTP/2の拡張→HTTP/3の展望
1. ALT-SVCフレーム
• 負荷分散やメンテなどのサーバ切り替え、プロトコルの切り替え
2. WebSocket over HTTP/2
• HTTP/2仕様を拡張してWebSocket多重化を実現
3. 明示的プロキシ機能
• Chrome for Android の DATA Compression機能の仕組みを標準化へ
• プロキシとの間をHTTP/2で接続。 平文http:// のコンテンツキャッシュ
4. 日和見暗号(opportunistic encryption)
• http:// の通信でサーバ認証せずに暗号化を行う。

30. HTTP/2の応用 WebPush
いろんな場面でプッシュ通知は必要
1. ブラウザ上でアプリが動作している時
• チャット等の通常のアプリ通知
2. ブラウザは立ち上げているがアプリは動作していない時
• SNSのメッセージやweb feedを受ける
3. ブラウザも立ち上げていない時
• WebRTCによる入電でウェブアプリを立ち上げる
4. １つのブラウザでアプリを複数インスタンス立ち上げてい
る。又は、異なるブラウザで同一のアプリを動作させてい
る。
• そのうちの１つにだけプッシュ通知したい。
• 全部にプッシュ通知をブロードキャストしたい。
• 複数アカウントでメール利用など。

31. HTTP/2の応用 Service Worker+ Server Push
プッシュサーバ
アプリケーション
サーバ
Webアプリの通信
ＨＴＴＰＳ必須
5. Service Worker上で
Pushイベントが発生。
ArrayBuffer, blob, json,
textの形式でプッシュ
データを取り出せる。
2. HTTP PUTのリクエスト
ボディにプッシュメッ
セージを付けて送信
4. HTTP/2サーバプッシュを利用
してクライアントに通知
3. 複数アプリのプッシュ
通知をチャネルで区別し、
一つの接続上で送信
1. クライアントからプッシュサーバ名と登録IDを通知
Service
Worker
ウェブ
アプリ
ブラウザ
Push API
クライアント

32. Service Workerからこう見える
// 登録されたService Workerのコード
this.onpush = function(event) {
console.log(event.data);
// event.data は、ArrayBuffer, blob, json, text形式
// ここでIndexedDBにdataを書き込んだり、
// 開いているウィンドウにdataを送ったり、
// Notificationを表示したりなどができる。
}
Web Pushは、複数のブラウザ、複数のアプリインスタンス、アプ
リの起動・停止中等様々な場面でもプッシュ通知が行える

33. 新プロトコル: QUIC
(Quic UDP Internet Connections)
IP(IPv4/IPv6)
UDP
TCP
TLS
QUIC
SPDY
HTTP
暗号化・認証
セッション確立、フロー制御
エラー補正, 輻輳制御
• Googleが独自に開発しているプロトコル
• UDP上でTCP+TLS相当＋αの機能を実装
• 最短0-RTTで再接続、暗号通信を必須化
• TCPと同様の輻輳制御で帯域の公平化
• 独自の誤り訂正と再送機能でパケットロス
によるTCPのHead of Line Blockingを回避
• Googleの全サービスで運用中、Chrome
のフィールドテスト中(*)
• Stable版： 0.2%(Desktop), 2%(Android)
• Beta版： 25%(Desktop), 50%(Android)
• 知らない間に使っているかも？
• 今年にライブラリ化を予定
(* 割合は2014/08時点のGoogleの公表値)

34. QUICデモ
パケットロス耐性 QUIC vs SPDY
クライアント
サーバ
Ajax
SPDY over TCP
Ajax
QUIC over UDP
30%パケットロス

35. おわり