SlideShare uma empresa Scribd logo
1 de 27
https://lepidum.co.jp/ Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.
h2-14はどう変わる
IETF90レポート
株式会社レピダム
前田 薫 (@mad_p)
http2 勉強会 #5 2014/07/30
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
目次
 draft-14, HPACK-09の変更点(予想)
 前回の報告からの差分
 前回: http2 hackathon #2 2014/5
 draft-12, HPACK-07
 IETF90報告
 proxy
 その他
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
h2-14 はどう変わる
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
HTTP/2基本仕様ドラフト
 IETFドラフトの最近の歴史
 draft-ietf-httpbis-http2 (h2)
 日本語訳 http://summerwind.jp/docs/draft-ietf-httpbis-http2-13/
 draft-ietf-httpbis-header-compression (HPACK)
http2study #5 2014/07/29
Date h2 HPACK http2studyでの解説 備考
2014/02/13 10 06 #4 (2014/3)
2014/04/03 11 07
2014/04/23 12 hackerthon #2 (2014/5) HPACK更新なし
2014/06/17 13 08
近日中?? 14 09 #5 (2014/07) 現時点での予測
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
h2-13, HPACK-08までの変更点
 全体
 拡張性が復活(-09でなくなったもの)
 フレームタイプ、SETTINGに拡張を許す
 既存部分の意味を変える拡張は事前にSETTINGSによ
るネゴシエーションをしてから使う
 例: per-frame gzip, big frame
 ストリーム優先度: dependency-based priority
 参考: https://nghttp2.org/blog/2014/04/27/how-
dependency-based-prioritization-works
 close後のストリームにもPRIORITY適用可能に
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
接続確立まで
 バージョン識別子「h2c」(c = cleartext)
 暗号化されていないTCP接続上のHTTP/2
 TLS暗号スイートを限定
 AEADモードの強制
 Connection Preface
 Connection Headerから名前変更
 AltSvcは拡張仕様に
 ALTSVCフレームも拡張に
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Frame全般
 Frame Types
 ALTSVC 削除 (拡張仕様に)
 BLOCKED 削除 (元々-12だけの予定だった)
 パディング
 256オクテットまで
 PAD_LOW, PAD_HIGH → PADDING
 PUSH_PROMISEに追加、CONTINUATIONから削除
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
DATA Frame
 per-frame GZip圧縮
 拡張に追い出して削除
 content-encodingヘッダの要件も合わせて削除
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
HPACK
 リテラル文字列に「ヘッダテーブルに追加
しない」オプション
 圧縮率観測攻撃の対象になるヘッダで使用
 例: Authorization Basic
 主にプロキシに対する指示
 ハフマンテーブルの更新
 static headerテーブルの更新
 SETTINGS_HEADER_TABLE_SIZE 変更後に最大
テーブルサイズをHPACK層でも送る
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
draft-14, HPACK-09の変更点(予想)
 Editor's copy
 http://http2.github.io/http2-spec/index.html
 http://http2.github.io/http2-spec/compression.html
 6月のInterimその前後のMLでの議論を反映
 IETF90では議論がなかった
 h2-14がWorking Group Last Call (WGLC)になる
気配
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
変更点予想一覧
 h2-14
 HTTPレスポンスコード 1xx が復活
 フレームサイズ上限→16M octets (Large Frames)
 SETTINGS_MAX_HEADER_LIST_SIZE
 pseudo headers(「:」で始まるもの)は最初に
 segment削除
 HPACK-09
 reference set削除
 同一ヘッダ名の値結合ルールも合わせて削除
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
reference set削除(YATTA!)
 reference setとは
 前回のHEADERSの中身を覚えておき、差分だけ送信
 同一のヘッダフィールドは送らない
 まったく同一の場合は空のHEADERSフレームを送る
 reference setの問題点
 最後まで読まないと中身がわからない
 接続先(:authority, :scheme)が不明
 ヘッダの順番が保たれない
 圧縮率に貢献するというデータがない
 実装がややこしくなりバグの元
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Large Frames (1/2)
 フレームの最大長を 2^24 - 1 (16M octets)に
 Frame HeaderのLengthフィールドは24bitに
 理由: でかいデータを速い回線で送りたい
http2study #5 2014/07/29
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-+-----------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Large Frames (2/2)
 受信可能なフレーム最大長のSETTINGS項目
 SETTINGS_MAX_FRAME_SIZE
 受信側が「自分は受け取れるよ」と宣言
 デフォルトは 2^14 (16384=16K octets)
 相手がこれを送ってくるまでは 16384 を超える大き
さのフレームを送ってはいけない
 処理系は16384 octetを処理できなければならない
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
pseudo headers (:headers)
 :authority, :pathなどはサーバー動作を決め
るために早めにほしい
 reference setがあるとどっちにしろヘッダブ
ロックを全部読まないとわからなかった
 :authorityはほぼ変わらない
 reference setがなくなったので、ヘッダはス
トリーミング処理したい
 → 先頭にまとめて送る
 オレオレ:headerを作るのも禁止。拡張でやれ
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
SETTINGS_MAX_HEADERS_LIST_SIZE
 HPACK後、1フレームにおさまらないヘッダ
は分割
 HEADERS, CONTINUATION, ...
 PUSH_PROMISE, CONTINUATION, ...
 これらのフレームの間に他のstreamを送っては
いけない → head-of-line blockingが発生し得る
 受信できる最大ブロック長を相手に知らせ
る(advisory)
 受信できないサーバーは431を返す
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
IETF90レポート
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
IETF90概要
 Toronto
 2014/07/20-25
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
httpbis WG
 Monday
 proxyに関する議論
 Tuesday
 その他の議論
 議事録
 https://github.com/httpwg/wg-materials/blob/gh-
pages/ietf90/minutes.md
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
プロキシの現状について
 HTTP/2におけるプロキシについて(Adam)
 SPDYではプロキシがあって通過できない人がい
る
 コンテンツfilteringはクライアントでやるべき
 Trusted Proxyとコスト(Peter)
 ネットが遅い地域ではOpera Miniが普及
 サーバー側でTLSをほどき、高圧縮で送信
 CDNではラストマイルはサポートできない
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Explicitly Authenticated Proxy(Salvatore)
 userのexplicit consent下で動くプロキシ
 これまでとは別のカテゴリのプロキシ
 reduce data usage
 content filtering
 accessには干渉しないが、optional servicesを提
供するもの
 Proxy Certificate
 opt outの必要性
 per requestではなくブラウザ設定で
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
そもそもProxyって何だ(mnot)
 HTTP/1.1ではどう定義されているか
 explicitly allows transformation and cache
 explicitly configured by clients
 HTTPS request is end-to-end
 これらのプロキシの定義を変えるのは大変
 機能追加ではなく現在のコンセンサスの変更である
 IETFは政治的にはサイドを取らないが、↑を選ぶとサイドを
取ることになる
 What can we do?
 publish "proxy problem" draft
 standardize proxy.pac
 find other ways to address underlying use cases
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
プロキシのディスカッション
 MITMプロキシの問題
 オリジンサーバーの証明書を渡せない
 end-2-endセキュリティーではない
 「HTTPがMITMを許容」なんて見出し見たいか?
 保護の必要なコンテンツの分離
 サーバーが秘匿性を表明したい
 ムービーだから内容は秘密じゃない
 フレームごと暗号化は考えたけど複雑すぎ
 トレードオフと選択は選択者によって違う
 検閲は分けて考えないといけない
 アフォーダンスが必要だ。選択肢だけではダメ
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
プロキシディスカッションまとめ
 Mark
 HTTPS is inviolate
 Maybe some interest in opt in to soften that
 Some interest in adorning TLS
 Interest in normalizing what an intercepting proxy is
 Interest in encrypted caching.
 Open issue on how opportunistic security interacts
with a proxy
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
HTTP/2以外の仕様
 HTTP/1.1 → RFC7230-5
 RFC2616を分割、6つのRFCになった。http/2ではそのうちの1
つだけを置きかえる(wire format)
 goals: wire formatとそれ以外を分離
 他の仕様にあったものでbase RFCにあるべきだったものを
cherry-pickingした
 RFC7238: 308 permanent redirect
 expirimental → proposed standard
 RFC5987: character set
 UTF-8だけを要求すればよく、ISO-8859-1 必須はドロップしてよい
 RFC6266: Use of the Content-Disposition Header Field
 Proposed Standard → Internet Standard.
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
その他の文書の検討
 draft-nakajima-httpbis-http2-interop-survey
 draft-ietf-httpbis-alt-svc
 拡張になったAltSvcのissuesについて
 draft-ietf-http2-encryption
 日和見暗号とHTTP/2の関係
 draft-hutton-httpbis-connect-protocol
 WebRTCがHTTP/2トンネルを使って送信されて
いることがわかるようにしてほしい → 炎上
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
今後の予定
 8月 WG Last Call
 次のinterimはあるのか?

Mais conteúdo relacionado

Mais procurados

爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechcon
爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechcon爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechcon
爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechconYosaku Toyama
 
雑談会議2021 Azure関連臨時LT大会
雑談会議2021 Azure関連臨時LT大会雑談会議2021 Azure関連臨時LT大会
雑談会議2021 Azure関連臨時LT大会Dai Iwai
 
JAZUG 8周年イベント登壇資料
JAZUG 8周年イベント登壇資料JAZUG 8周年イベント登壇資料
JAZUG 8周年イベント登壇資料Dai Iwai
 
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月VirtualTech Japan Inc.
 
Webアプリケーションは難しい
Webアプリケーションは難しいWebアプリケーションは難しい
Webアプリケーションは難しいTakafumi ONAKA
 
NAT配下からIPv6でアクセスするEzoScapeはTeredo通信だった
NAT配下からIPv6でアクセスするEzoScapeはTeredo通信だったNAT配下からIPv6でアクセスするEzoScapeはTeredo通信だった
NAT配下からIPv6でアクセスするEzoScapeはTeredo通信だったShinichi Hirauchi
 
CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜
CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜
CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜Drecom Co., Ltd.
 
iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜
iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜
iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜Kentaro Matsumae
 
商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのことNTT DATA OSS Professional Services
 
クイズを支える技術
クイズを支える技術クイズを支える技術
クイズを支える技術Satoshi Hirata
 
Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)
Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)
Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)v6app
 
30分でわかる! コンピュータネットワーク
30分でわかる! コンピュータネットワーク30分でわかる! コンピュータネットワーク
30分でわかる! コンピュータネットワークTrainocate Japan, Ltd.
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾外道 父
 
Pの付く言語の話
Pの付く言語の話Pの付く言語の話
Pの付く言語の話Satoshi Hirata
 
Inside mobage platform
Inside mobage platformInside mobage platform
Inside mobage platformToru Yamaguchi
 
re:Invent 2015 参加報告
re:Invent 2015 参加報告re:Invent 2015 参加報告
re:Invent 2015 参加報告Satoshi Hirata
 
GTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテック
GTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテックGTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテック
GTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテックGame Tools & Middleware Forum
 
情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦
情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦
情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦Sho Yoshida
 

Mais procurados (20)

爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechcon
爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechcon爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechcon
爆速でAndroidアプリを ビルドするための仕組み DeNA TechCon #denatechcon
 
雑談会議2021 Azure関連臨時LT大会
雑談会議2021 Azure関連臨時LT大会雑談会議2021 Azure関連臨時LT大会
雑談会議2021 Azure関連臨時LT大会
 
JAZUG 8周年イベント登壇資料
JAZUG 8周年イベント登壇資料JAZUG 8周年イベント登壇資料
JAZUG 8周年イベント登壇資料
 
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
 
Webアプリケーションは難しい
Webアプリケーションは難しいWebアプリケーションは難しい
Webアプリケーションは難しい
 
NAT配下からIPv6でアクセスするEzoScapeはTeredo通信だった
NAT配下からIPv6でアクセスするEzoScapeはTeredo通信だったNAT配下からIPv6でアクセスするEzoScapeはTeredo通信だった
NAT配下からIPv6でアクセスするEzoScapeはTeredo通信だった
 
CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜
CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜
CEDEC 2015 Cocos2d-x と社内基盤の付き合い方 〜アップストリームファーストを目指して〜
 
activerecord-turntable
activerecord-turntableactiverecord-turntable
activerecord-turntable
 
iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜
iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜
iOSレガシーコード改善ガイド〜マンガボックス開発における事例〜
 
商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと
 
クイズを支える技術
クイズを支える技術クイズを支える技術
クイズを支える技術
 
Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)
Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)
Lightweight Language Diverプレゼン資料:アプリケーションのIPv6対応のススメ(LL編)
 
30分でわかる! コンピュータネットワーク
30分でわかる! コンピュータネットワーク30分でわかる! コンピュータネットワーク
30分でわかる! コンピュータネットワーク
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾
 
Pの付く言語の話
Pの付く言語の話Pの付く言語の話
Pの付く言語の話
 
Inside mobage platform
Inside mobage platformInside mobage platform
Inside mobage platform
 
re:Invent 2015 参加報告
re:Invent 2015 参加報告re:Invent 2015 参加報告
re:Invent 2015 参加報告
 
ひとりLT大会
ひとりLT大会ひとりLT大会
ひとりLT大会
 
GTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテック
GTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテックGTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテック
GTMF 2016:「KiQ」が拓くゲームサーバの未来 株式会社アトミテック
 
情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦
情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦
情熱Smalltalker SmalltalkとAWSでクラウドサービスを実現するための挑戦
 

Semelhante a HTTP/2 draft 14 preview and IETF90 httpbis WG Report

IETF89 HTTP関連WG報告 #isocjp
IETF89 HTTP関連WG報告 #isocjpIETF89 HTTP関連WG報告 #isocjp
IETF89 HTTP関連WG報告 #isocjpKaoru Maeda
 
IETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUICIETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUICKaoru Maeda
 
IETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG ReportIETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG ReportKaoru Maeda
 
Ietf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauthIetf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauthKaoru Maeda
 
IETF96 Update oauth tokbind
IETF96 Update oauth tokbindIETF96 Update oauth tokbind
IETF96 Update oauth tokbindKaoru Maeda
 
Perl で作るメディアストリーミングサーバー
Perl で作るメディアストリーミングサーバーPerl で作るメディアストリーミングサーバー
Perl で作るメディアストリーミングサーバーHideo Kimura
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014Nov Matake
 
認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤Masahiro Kiura
 
20120822_dstn技術交流会_dstnのご紹介と最新技術情報
20120822_dstn技術交流会_dstnのご紹介と最新技術情報20120822_dstn技術交流会_dstnのご紹介と最新技術情報
20120822_dstn技術交流会_dstnのご紹介と最新技術情報dstn
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割Toru Yamaguchi
 
CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)J-Stream Inc.
 
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門Hiroshi Tokumaru
 
Cloudera impala
Cloudera impalaCloudera impala
Cloudera impala外道 父
 
DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)
DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)
DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)VirtualTech Japan Inc.
 
HTML5 と次世代のネットワーク プロトコル
HTML5 と次世代のネットワーク プロトコルHTML5 と次世代のネットワーク プロトコル
HTML5 と次世代のネットワーク プロトコル彰 村地
 
"Up" with vagrant and docker
"Up" with vagrant and docker"Up" with vagrant and docker
"Up" with vagrant and dockerHiroshi Miura
 
H2O - making HTTP better
H2O - making HTTP betterH2O - making HTTP better
H2O - making HTTP betterKazuho Oku
 
CometPub20070223
CometPub20070223CometPub20070223
CometPub20070223Hiroshi Ono
 

Semelhante a HTTP/2 draft 14 preview and IETF90 httpbis WG Report (20)

IETF89 HTTP関連WG報告 #isocjp
IETF89 HTTP関連WG報告 #isocjpIETF89 HTTP関連WG報告 #isocjp
IETF89 HTTP関連WG報告 #isocjp
 
Ietf95 http2
Ietf95 http2Ietf95 http2
Ietf95 http2
 
IETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUICIETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUIC
 
IETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG ReportIETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG Report
 
Ietf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauthIetf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauth
 
IETF96 Update oauth tokbind
IETF96 Update oauth tokbindIETF96 Update oauth tokbind
IETF96 Update oauth tokbind
 
Perl で作るメディアストリーミングサーバー
Perl で作るメディアストリーミングサーバーPerl で作るメディアストリーミングサーバー
Perl で作るメディアストリーミングサーバー
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
 
認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤
 
HTTP/2.0と標準化
HTTP/2.0と標準化HTTP/2.0と標準化
HTTP/2.0と標準化
 
20120822_dstn技術交流会_dstnのご紹介と最新技術情報
20120822_dstn技術交流会_dstnのご紹介と最新技術情報20120822_dstn技術交流会_dstnのご紹介と最新技術情報
20120822_dstn技術交流会_dstnのご紹介と最新技術情報
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割
 
CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)
 
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
 
Cloudera impala
Cloudera impalaCloudera impala
Cloudera impala
 
DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)
DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)
DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)
 
HTML5 と次世代のネットワーク プロトコル
HTML5 と次世代のネットワーク プロトコルHTML5 と次世代のネットワーク プロトコル
HTML5 と次世代のネットワーク プロトコル
 
"Up" with vagrant and docker
"Up" with vagrant and docker"Up" with vagrant and docker
"Up" with vagrant and docker
 
H2O - making HTTP better
H2O - making HTTP betterH2O - making HTTP better
H2O - making HTTP better
 
CometPub20070223
CometPub20070223CometPub20070223
CometPub20070223
 

Mais de Kaoru Maeda

Emacs TypeScript
Emacs TypeScriptEmacs TypeScript
Emacs TypeScriptKaoru Maeda
 
IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)Kaoru Maeda
 
IETF102 Report Authorization
IETF102 Report AuthorizationIETF102 Report Authorization
IETF102 Report AuthorizationKaoru Maeda
 
IETF97 Update oauth tokbind
IETF97 Update oauth tokbindIETF97 Update oauth tokbind
IETF97 Update oauth tokbindKaoru Maeda
 
http2study 20160423 IETF95 Report
http2study 20160423 IETF95 Reporthttp2study 20160423 IETF95 Report
http2study 20160423 IETF95 ReportKaoru Maeda
 
From an Experience of Vulnerability Reporting
From an Experience of Vulnerability ReportingFrom an Experience of Vulnerability Reporting
From an Experience of Vulnerability ReportingKaoru Maeda
 
HTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのかHTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのかKaoru Maeda
 
IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方Kaoru Maeda
 
IETF91報告arcmedia-mcic
IETF91報告arcmedia-mcicIETF91報告arcmedia-mcic
IETF91報告arcmedia-mcicKaoru Maeda
 
HTTP/2 Local activities in Japan
HTTP/2 Local activities in JapanHTTP/2 Local activities in Japan
HTTP/2 Local activities in JapanKaoru Maeda
 
HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜Kaoru Maeda
 
Rubyコードゴルフ「ぐるぐる渦巻き」に参加してみた
Rubyコードゴルフ「ぐるぐる渦巻き」に参加してみたRubyコードゴルフ「ぐるぐる渦巻き」に参加してみた
Rubyコードゴルフ「ぐるぐる渦巻き」に参加してみたKaoru Maeda
 
Fizzbuzz in Complex Plane
Fizzbuzz in Complex PlaneFizzbuzz in Complex Plane
Fizzbuzz in Complex PlaneKaoru Maeda
 
Lightning Talks日本上陸
Lightning Talks日本上陸Lightning Talks日本上陸
Lightning Talks日本上陸Kaoru Maeda
 

Mais de Kaoru Maeda (15)

Emacs TypeScript
Emacs TypeScriptEmacs TypeScript
Emacs TypeScript
 
IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)
 
IETF102 Report Authorization
IETF102 Report AuthorizationIETF102 Report Authorization
IETF102 Report Authorization
 
IETF97 Update oauth tokbind
IETF97 Update oauth tokbindIETF97 Update oauth tokbind
IETF97 Update oauth tokbind
 
http2study 20160423 IETF95 Report
http2study 20160423 IETF95 Reporthttp2study 20160423 IETF95 Report
http2study 20160423 IETF95 Report
 
From an Experience of Vulnerability Reporting
From an Experience of Vulnerability ReportingFrom an Experience of Vulnerability Reporting
From an Experience of Vulnerability Reporting
 
HTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのかHTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのか
 
IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方
 
Tokbind-fido
Tokbind-fidoTokbind-fido
Tokbind-fido
 
IETF91報告arcmedia-mcic
IETF91報告arcmedia-mcicIETF91報告arcmedia-mcic
IETF91報告arcmedia-mcic
 
HTTP/2 Local activities in Japan
HTTP/2 Local activities in JapanHTTP/2 Local activities in Japan
HTTP/2 Local activities in Japan
 
HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜
 
Rubyコードゴルフ「ぐるぐる渦巻き」に参加してみた
Rubyコードゴルフ「ぐるぐる渦巻き」に参加してみたRubyコードゴルフ「ぐるぐる渦巻き」に参加してみた
Rubyコードゴルフ「ぐるぐる渦巻き」に参加してみた
 
Fizzbuzz in Complex Plane
Fizzbuzz in Complex PlaneFizzbuzz in Complex Plane
Fizzbuzz in Complex Plane
 
Lightning Talks日本上陸
Lightning Talks日本上陸Lightning Talks日本上陸
Lightning Talks日本上陸
 

HTTP/2 draft 14 preview and IETF90 httpbis WG Report

  • 1. https://lepidum.co.jp/ Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved. h2-14はどう変わる IETF90レポート 株式会社レピダム 前田 薫 (@mad_p) http2 勉強会 #5 2014/07/30 http2study #5 2014/07/29
  • 2. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 目次  draft-14, HPACK-09の変更点(予想)  前回の報告からの差分  前回: http2 hackathon #2 2014/5  draft-12, HPACK-07  IETF90報告  proxy  その他 http2study #5 2014/07/29
  • 3. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ h2-14 はどう変わる http2study #5 2014/07/29
  • 4. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ HTTP/2基本仕様ドラフト  IETFドラフトの最近の歴史  draft-ietf-httpbis-http2 (h2)  日本語訳 http://summerwind.jp/docs/draft-ietf-httpbis-http2-13/  draft-ietf-httpbis-header-compression (HPACK) http2study #5 2014/07/29 Date h2 HPACK http2studyでの解説 備考 2014/02/13 10 06 #4 (2014/3) 2014/04/03 11 07 2014/04/23 12 hackerthon #2 (2014/5) HPACK更新なし 2014/06/17 13 08 近日中?? 14 09 #5 (2014/07) 現時点での予測
  • 5. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ h2-13, HPACK-08までの変更点  全体  拡張性が復活(-09でなくなったもの)  フレームタイプ、SETTINGに拡張を許す  既存部分の意味を変える拡張は事前にSETTINGSによ るネゴシエーションをしてから使う  例: per-frame gzip, big frame  ストリーム優先度: dependency-based priority  参考: https://nghttp2.org/blog/2014/04/27/how- dependency-based-prioritization-works  close後のストリームにもPRIORITY適用可能に http2study #5 2014/07/29
  • 6. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 接続確立まで  バージョン識別子「h2c」(c = cleartext)  暗号化されていないTCP接続上のHTTP/2  TLS暗号スイートを限定  AEADモードの強制  Connection Preface  Connection Headerから名前変更  AltSvcは拡張仕様に  ALTSVCフレームも拡張に http2study #5 2014/07/29
  • 7. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Frame全般  Frame Types  ALTSVC 削除 (拡張仕様に)  BLOCKED 削除 (元々-12だけの予定だった)  パディング  256オクテットまで  PAD_LOW, PAD_HIGH → PADDING  PUSH_PROMISEに追加、CONTINUATIONから削除 http2study #5 2014/07/29
  • 8. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ DATA Frame  per-frame GZip圧縮  拡張に追い出して削除  content-encodingヘッダの要件も合わせて削除 http2study #5 2014/07/29
  • 9. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ HPACK  リテラル文字列に「ヘッダテーブルに追加 しない」オプション  圧縮率観測攻撃の対象になるヘッダで使用  例: Authorization Basic  主にプロキシに対する指示  ハフマンテーブルの更新  static headerテーブルの更新  SETTINGS_HEADER_TABLE_SIZE 変更後に最大 テーブルサイズをHPACK層でも送る http2study #5 2014/07/29
  • 10. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ draft-14, HPACK-09の変更点(予想)  Editor's copy  http://http2.github.io/http2-spec/index.html  http://http2.github.io/http2-spec/compression.html  6月のInterimその前後のMLでの議論を反映  IETF90では議論がなかった  h2-14がWorking Group Last Call (WGLC)になる 気配 http2study #5 2014/07/29
  • 11. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 変更点予想一覧  h2-14  HTTPレスポンスコード 1xx が復活  フレームサイズ上限→16M octets (Large Frames)  SETTINGS_MAX_HEADER_LIST_SIZE  pseudo headers(「:」で始まるもの)は最初に  segment削除  HPACK-09  reference set削除  同一ヘッダ名の値結合ルールも合わせて削除 http2study #5 2014/07/29
  • 12. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ reference set削除(YATTA!)  reference setとは  前回のHEADERSの中身を覚えておき、差分だけ送信  同一のヘッダフィールドは送らない  まったく同一の場合は空のHEADERSフレームを送る  reference setの問題点  最後まで読まないと中身がわからない  接続先(:authority, :scheme)が不明  ヘッダの順番が保たれない  圧縮率に貢献するというデータがない  実装がややこしくなりバグの元 http2study #5 2014/07/29
  • 13. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Large Frames (1/2)  フレームの最大長を 2^24 - 1 (16M octets)に  Frame HeaderのLengthフィールドは24bitに  理由: でかいデータを速い回線で送りたい http2study #5 2014/07/29 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+
  • 14. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Large Frames (2/2)  受信可能なフレーム最大長のSETTINGS項目  SETTINGS_MAX_FRAME_SIZE  受信側が「自分は受け取れるよ」と宣言  デフォルトは 2^14 (16384=16K octets)  相手がこれを送ってくるまでは 16384 を超える大き さのフレームを送ってはいけない  処理系は16384 octetを処理できなければならない http2study #5 2014/07/29
  • 15. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ pseudo headers (:headers)  :authority, :pathなどはサーバー動作を決め るために早めにほしい  reference setがあるとどっちにしろヘッダブ ロックを全部読まないとわからなかった  :authorityはほぼ変わらない  reference setがなくなったので、ヘッダはス トリーミング処理したい  → 先頭にまとめて送る  オレオレ:headerを作るのも禁止。拡張でやれ http2study #5 2014/07/29
  • 16. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ SETTINGS_MAX_HEADERS_LIST_SIZE  HPACK後、1フレームにおさまらないヘッダ は分割  HEADERS, CONTINUATION, ...  PUSH_PROMISE, CONTINUATION, ...  これらのフレームの間に他のstreamを送っては いけない → head-of-line blockingが発生し得る  受信できる最大ブロック長を相手に知らせ る(advisory)  受信できないサーバーは431を返す http2study #5 2014/07/29
  • 17. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ IETF90レポート http2study #5 2014/07/29
  • 18. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ IETF90概要  Toronto  2014/07/20-25 http2study #5 2014/07/29
  • 19. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ httpbis WG  Monday  proxyに関する議論  Tuesday  その他の議論  議事録  https://github.com/httpwg/wg-materials/blob/gh- pages/ietf90/minutes.md http2study #5 2014/07/29
  • 20. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ プロキシの現状について  HTTP/2におけるプロキシについて(Adam)  SPDYではプロキシがあって通過できない人がい る  コンテンツfilteringはクライアントでやるべき  Trusted Proxyとコスト(Peter)  ネットが遅い地域ではOpera Miniが普及  サーバー側でTLSをほどき、高圧縮で送信  CDNではラストマイルはサポートできない http2study #5 2014/07/29
  • 21. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Explicitly Authenticated Proxy(Salvatore)  userのexplicit consent下で動くプロキシ  これまでとは別のカテゴリのプロキシ  reduce data usage  content filtering  accessには干渉しないが、optional servicesを提 供するもの  Proxy Certificate  opt outの必要性  per requestではなくブラウザ設定で http2study #5 2014/07/29
  • 22. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ そもそもProxyって何だ(mnot)  HTTP/1.1ではどう定義されているか  explicitly allows transformation and cache  explicitly configured by clients  HTTPS request is end-to-end  これらのプロキシの定義を変えるのは大変  機能追加ではなく現在のコンセンサスの変更である  IETFは政治的にはサイドを取らないが、↑を選ぶとサイドを 取ることになる  What can we do?  publish "proxy problem" draft  standardize proxy.pac  find other ways to address underlying use cases http2study #5 2014/07/29
  • 23. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ プロキシのディスカッション  MITMプロキシの問題  オリジンサーバーの証明書を渡せない  end-2-endセキュリティーではない  「HTTPがMITMを許容」なんて見出し見たいか?  保護の必要なコンテンツの分離  サーバーが秘匿性を表明したい  ムービーだから内容は秘密じゃない  フレームごと暗号化は考えたけど複雑すぎ  トレードオフと選択は選択者によって違う  検閲は分けて考えないといけない  アフォーダンスが必要だ。選択肢だけではダメ http2study #5 2014/07/29
  • 24. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ プロキシディスカッションまとめ  Mark  HTTPS is inviolate  Maybe some interest in opt in to soften that  Some interest in adorning TLS  Interest in normalizing what an intercepting proxy is  Interest in encrypted caching.  Open issue on how opportunistic security interacts with a proxy http2study #5 2014/07/29
  • 25. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ HTTP/2以外の仕様  HTTP/1.1 → RFC7230-5  RFC2616を分割、6つのRFCになった。http/2ではそのうちの1 つだけを置きかえる(wire format)  goals: wire formatとそれ以外を分離  他の仕様にあったものでbase RFCにあるべきだったものを cherry-pickingした  RFC7238: 308 permanent redirect  expirimental → proposed standard  RFC5987: character set  UTF-8だけを要求すればよく、ISO-8859-1 必須はドロップしてよい  RFC6266: Use of the Content-Disposition Header Field  Proposed Standard → Internet Standard. http2study #5 2014/07/29
  • 26. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ その他の文書の検討  draft-nakajima-httpbis-http2-interop-survey  draft-ietf-httpbis-alt-svc  拡張になったAltSvcのissuesについて  draft-ietf-http2-encryption  日和見暗号とHTTP/2の関係  draft-hutton-httpbis-connect-protocol  WebRTCがHTTP/2トンネルを使って送信されて いることがわかるようにしてほしい → 炎上 http2study #5 2014/07/29
  • 27. Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 今後の予定  8月 WG Last Call  次のinterimはあるのか?