More Related Content More from shigeki_ohtsu (6) httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)3. 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, HPACK(header-compression-02)リリース(実装仕様)
2013年10月
第4回中間会議(シアトル)
今ココ
4. interim アジェンダ
• 初日: 自己紹介、実装者フィードバック、テス
トフレームワーク構想の説明、相互接続試験
(自由時間)
• 2日目: github issue の議論
• 3日目午前: issue 議論の続き
6. 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
New
9
Wireshark
C
other
NPN, ALPN
New
C
proxy
nghttp2 + patch
New
10 Ericcson MSP
( https://github.com/http2/http2-spec/wiki/Implementations より引用)
いくつか CONTINUATION や Server Push などの機能を一部実装していないのもあり
7. Node.jsのALPN対応
• Node.jsの9月上旬の master
を fork。
• openssl の ALPNサポートは
未リリース。
• git submodule で openssl の
master を Node でリンクする
よう改良。
• ALPN用の Node APIを追加。
• ALPNとNPNを両方サポート。
ただし両方同時に受け取っ
た場合はNPNを広告しない。
15. 2日目の以降: 主な議論
• HTTP Upgrade を別仕様に分けるか?
– 複雑だし、実装少ないし、テストもできてないし
– Alt-SVC,Alternate-Protocolを別ドラフトで作ってか
ら再検討
• HPACK-03見直し
– Literal Rep. Substitute Indexing の削除
– 初期ヘッダテーブルを静的に(evictionから解放)
– Request/Responesのテーブルを一つに統合
– 頭(index:0)にインクリメントヘッダを導入
– ハフマン符号化の試験しよう
16. 2日目の以降: 主な議論 cont’d
• SETTINGS Ack フラグの新設
– 設定情報の同期(ヘッダテーブルサイズの変更)
– PINGいらなくない? とりあえず様子見。
• CONTINUATIONのEND_STREAM排除
– PUSH_PROMISEでのストリーム終了を回避
• :authority ヘッダの新設
– :hostの廃止。(HTTP/1.1と混同しやすいから)
• HPACKでヘッダ出現順が保存されないことを
明記
• その他細かい修正色々
17. 2日目の以降: 主な議論 cont’d
• ALPNに関して
– 02がLast Call。バンクーバIETFが最後のチャンス
– クライアントが送信できる拡張サイズに懸念
• Stream Dependency
– Tokyo Interim から議論されている課題
– 木やグラフでPriorityの依存性を管理
– タブの切り替え、ビューポートの切り替え、順番維持
が必要なビデオフレーム切り替え、に対して関連する
複数のストリームを一気に repriority できる。
– まだまだ議論中。別ドラフトを作る予定。
• Frame Typeの拡張
– 独自試験する時とかどうする?