Contenu connexe Plus de shigeki_ohtsu (6) 2. HTTP/2 これまでの歩み
年月
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年6月
第2回中間会議(サンフランシスコ) 新ヘッダ圧縮仕様の採用を決定
2013年7月
draft-04リリース(最初の実装ドラフト）
2013年8月
第3回中間会議(ハンブルグ) 最初のHTTP/2.0相互接続試験を実施
draft-06リリース（実装ドラフト)
2013年10月 第4回中間会議(シアトル) 2回目の相互接続試験を実施
2013年12月 draft-09リリース(実装ドラフト）
2014年1月
第5回中間会議(チューリッヒ) 開催
今ココ
3. 第５回 httpbis interim@チューリッヒ
2014 1/22～24
スイスは
物価高過ぎ！
名物チーズ
フォンデュ
私は、
•
•
•
•
Cisco Systems がホスト
ではありませんよ。
２０数名が集まる (F5など新参組も)
最終日は TLS WG と Joint (WG chairも参加）
Application/Security AD達が集まる豪勢なinterim
6. チューリッヒ interim 概要
• issue の議論と方針決め
• Priority Leveling 仕様の議論 （最後の大物）
• Security Discussion （一応スコープ外で決着）
7. issue議論の結果
draft10の変更点（見た目編）
• Editorが転職 (MS Open Tech→Mozilla)
• マイナーバージョンの廃止 (HTTP/2, ALPNではh2)
– 2.0←→2.1といった互換通信をしない。
– 次は HTTP/3 にすぐ取り掛かる。(短期にバージョンアップ）
• GOAWAY→GTFO(General Termination of Future Operations)
– Google の Hasan と Editor の Martin によるシャレ → 1/29に revert
• FrameType、エラーコード、SETTINGSのリナンバー
– LastCall に向けた準備
• SETTINGSフレーム構造の変更. 5(1+4)バイト毎に
8. もうチョイ深いdraft10変更点（その１）
• FlowControl停止設定の廃止
– どっちみち DoS対策でフロー制御が必要だよね。
– 最大値(31bit)に設定すればいいじゃん。
• DATAフレームにEND_MESSAGEフラグの新設(*)
– この後にWebSocketを入れられるようにしようか。
– hybiとジョイント WGをしてＷＳの検討しよう。
• 負荷分散について記述追加(*)
– ＴＣＰ張りっぱなしだから負荷分散がしにくい
– Alt-Svcヘッダ使って分散する方法の記述を検討
(*) 1/28時点まだ未修整
10. HPACK-06の変更点
• Request/Response の Huffman Tableの共通化(*)
– チョット最適化が悪くなるがそれほどでもない
– コンテキストで共通化,サーバプッシュにメリット
• cookie/set-cookie用の Huffman Tableの新設(*)
– base64エンコードにして最適化を進めよう
• エンコーダー側からのTableSize指定
– index:0を使おう。reference set消去とかぶるよ（涙）
– FrameHeader Flagじゃあかん。bit flag を変更しようか(*)
– SETTINGS-ACKとは独立。問題があるならエラーに。
• draftはHTTP/2と別々に進めよう。先にセキュリティレ
ビューなどしてもらってもいいし。 (*) 1/28時点まだ未修整
11. 最後の大物 Priority Dependency
ユースケースの例
• ダウンロード順が決められてるもの
– jQueryロードしてから、JS実行コード
– 分割ビデオやオーディオファイル（１章、２章…）
• DOM Parseに影響するもの
– document.write はDOM Parseをブロックするので早く取得
• ユーザ行動
– タブ切り替え、ViewPort変更（優先度変更）
• Server Pushのヒント
– 依存性で次にリクエストするファイルが分かるのでプッ
シュに有用（そもそもサーバ側が情報持っているジャン）
ユーザ視点の高速化に大きく利点、SPDY時代からの課題だが
複雑過ぎてGoogleがこれまで取り組めなかった。
13. Weighted Dependency Group
Priority Group
ID: 1234(24bit), Weight: 255(8bit)
X
0
A
F
B
C
D
E
G
木構造に
しないよ
ストリーム
Priority Group(24)
Weight(8)
Stream Dependency(31)
• Priority用のGroupを新設
• Group内で0を頂点としたスト
リーム依存性を定義
• グループ間はWeight比でリ
ソース割り当て
• default はID下24bit, 重み16,
stream_id:0に依存
これから議論、検証です。
15. Security Discussion
• HTTP/2 を TLS に限定する提案
– 従来通り HTTP でも利用できるようにする。
• Explicit Proxy(PolicyFilter、VirusScan , etc.用途 )
– HTTP/2のスコープ外にして、継続議論
• http:// の opportunistic(日和見）暗号化
– HTTP/2の進捗に影響ない範囲で検討継続
• コネクション集約
– Client証明書、 subjectAltName対応など問題あり
16. Security Discussion
結論：HTTP/2 はTLSに限定しない
• HTTP/2は仕様的に、http/https両方使える。
• どう対応するかはマーケットに任せる。
• Firefox/Chrome は httpsのみ、IEは http もサポー
トするといったちぐはぐが起こる。
ユーザ側のHTTP/2対応に混乱、問題は生じない
か？
個人情報を扱うサイトは、HSTS/Key pinning などで
フルHTTPS化推進へ
17. Security Discussion
HTTP/2の http:// に日和見暗号を！
• そもそも必要、不要？ （このまま何もしないわけにはい
かない）
• サーバ認証は？
– する(httpsと実質同じ）
– しない（Active MITMには無力)
– 別の仕組み(DNSSECを使うDANE、TLS拡張を使うTACK
等々）
• 切り替え方法は？ （対ダウングレードアタック）
– ALPNみたいなヒント交換、 DNSレコード、HTTP/2フ
レーム内で暗号化ハンドシェイク、既存の443ポート
を使ってSETTINGSで交換
18. 今後の予定
• 2/7 （最悪2/14)までに draft10 をリリース
– みんな仕事速い！ほとんど修正済
• IETF London(3/2-7)翌日3/8にhttpbisの非公式
interimを開催(正式な interopはやらない）
• 6月上旬米国東海岸で第６回interimを開催
まだまだあきらめまへん
• 4月 HTTP/2 の WG Last Call
• 8月 IETF Last Call を目指す。
