Blog

2014.02.21

勉強会メモ「HTTP2.0勉強会 #3」

こんにちは、今年からレピダムにシニアプログラマとしてjoinしました、前田(@mad_p)と申します。 ID関連、HTTP2関連の講演メモや最新トピックなどを技術Blogとして書いていきたいと思います。

今回は2014年01月28日にIIJ 神保町三井ビルで行われたhttp2.0勉強会#3のメモです。 当日ほぼ同じ内容でツダったので、そちらのまとめとあまり変わらないかもしれませんが…。

本文で話題となっているとおり、HTTP2.0はHTTP2と呼称が変わり、すでにdraft-10も出ています。 今後は勉強会の名前も変わるのでしょうか。 2月23日にはhttp2ハッカソン#1も企画されています。興味のある方はぜひご参加ください。

それでは当日のログをどうぞ

http2.0勉強会 #3

開催概要

@summerwind: 「HTTP2を読み解く技術」

  • 資料
  • Moto Ishizawa
    • HTTP/2.0ドラフトの翻訳
    • HPACKの実装
  • 今日はHTTP/2の仕様書を読むにあたって、ここわからんな、というものを解説

ネットワーク関連

  • HoL (head-of-line)ブロッキング
    • キューの先頭につまっているデータがあると後続が送れない
    • HTTP2では、pipeliningで順序が保証されることに起こるレスポンスのつまり
  • Flow control
    • データとりこぼしが発生しないように送信を止めてくれと受信側からお願いする
    • HTTP2ではストリームとコネクションの2つの単位でフロー制御する
    • connectionのwindowは6553バイト固定
    • connectionのwindowが開いた場合はstream id: 0で更新する
  • BDP: bandwidth-delay product
    • 最適なwindow sizeを計算するためによく使われる式。帯域幅×RTTを使うとよいという話

TLS関連

  • ALPN: Application Layer Protocol Negitiation
    • クライアントが自分の使えるプロトコルをサーバーに送る
    • サーバーがその中から選んで決める
    • HTTP2ではhttpsでTLSを張るときにHTTP2を使うことを合意するために使う
    • 実装によってまだ使えないものもある

HTTP/1.1関連

  • 100-continueはHTTP2ではサポートされないよ
    • 100-continueってなんだっけ? → クライアントがExpect: 100-continueを送ると、サーバー側では、ヘッダだけを確認する。受信可能な場合には100 Continueを返す
    • HTTP2ではとりあえず小さいのを送ってみろということになっている
  • CONNECTメソッド:
    • プロキシが指定されたサーバーに中継してくれる仕組み
    • HTTP2では:connectヘッダでリクエスト

参考文献

  • High Performace Browser Networking

Q&A

  • Jxck_: プロキシしたときのDATAフレームの中にGETも全部入れるの?
    • @summerwind: そのままトンネリングするため
    • HTTP2をプロキシするときはCONNECTを使ってはいけない

@jovi0608: 「httpbis interim@チューリッヒ報告」(仮)

  • 会場に聞いてみた
    • HTTP2のドラフト読んだ人 → 20人くらい / 60人くらい
    • SPDY使ってみた人 → あれっ、少ない
  • 資料
    • チューリッヒでのintermのレポート。ドラフト9がわかった上での差分

HTTP2の歴史

  • 始まったのは2012年1月。これからやるぞという宣言。チャーター、要件で1年くらいかかった。SPDYベースに決まったのが2012年11月
  • 2013年1月以降、5か月に1度くらい中間会議(interim)をやっている。今回が第5回
  • 今年の4月にlast callに持っていきたい。今年中には全部カタをつけようね
  • 例を見ないほどアクティブ

httpbis interim@チューリッヒ

  • スイスは物価が高い。マクドナルドが1000円くらい
    • 会う人ごとに「nghttp2ありがとう」と言われて私はtatsuhiro-tではありませんと答えた。次はそういうTシャツ着ていこう
  • security ADの重鎮達が集まったinterim

HTTP-draft-09/2.0 interop

  • 初日がinterop
  • firefoxもtwitterも実装がもう終わってた
  • chromeの人が来ていなかった。人材をさがしている
  • いままでと違って、作ってきて調べようという段階ではなく、事前に試験が終わって、どうしたらいいか議論するフェーズになったということだろう

HTTP2の現状は第4コーナー

  • 第4コーナーに入ったが、まだコーナーは抜けていない。この後ゴールなのかもわからない
  • どうするかの題材は今回のinteropで洗い出してほぼ見えてきた

チューリッヒinterim概要

  • issueはgithubに挙がっている。議論はML。github上で議論するとMLに出せとおこられる。マイルストン管理などをissueで
  • 最後の大物(技術的に大きな課題)だったpriority leveling仕様を決めよう
  • security discussion: HTTP2をTLS必須にするかどうかなどを決めよう
    • ほとんどのものはスコープ外として結着

議論の結果

  • editorが転職
    • MSの人がhttp2の仕様を書いてるのが特徴的だったが使っているのはmacだった。「もじらになったんだよ」。microsoftの協力はacknowledgementに残った
  • マイナーバージョンは廃止
    • 今後は2.0と言わずに「HTTP/2」。ALPNでは「h2」。
    • 2.0と2.1でやり取りすることはもう考えない。次はHTTP/3にしようということ。
    • ブラウザと同じで半年に1回バージョンアップという冗談も?
  • GOAWAY → GTFO (通常のchatや英語圏の「get the f*** out」の略語)
    • General Termination of Future Operations
    • (前田注: この変更は後にキャンセルされています)
  • FrameType、エラーコード、SETTINGSなど各種番号をリナンバーした
    • LastCallが見えてきたので、歯抜けだったところをつめ、連番にした
  • SETTINGSフレーム構造の変更
  • FlowControl停止設定の廃止。
    • 最大値(31bit)に設定すれば実質的に無限という意味になる
  • DATAフレームにEND_MESSAGEフラグを新設
    • POSTデータの終了を示す
    • 暗号化のpaddingを入れたりに使うこともできそう
    • WebSocketも入れられるけど、勝手に決められないよね → IETF89ロンドンで検討
    • @Jxck_: END_MESSAGEを使うとどうしてWebSocketが入れられるの? @jovi0608 HTTP2の通信はここで終わりだよという印で、後のDATAフレームはクライアントとサーバーが合意して使えるということ
    • @Jxck_: DATAフレーム使えばマルチプレクスもできると
    • @lef: TLS-guyはこの話について何か言ってた? @jovi0608: このときはいなかった。WSの構造がいらなくなる
  • 負荷分散について記述を追加
    • 指針、方法論を書いたらいいんじゃないかという提案
    • Alt-Svcヘッダで次にどのサーバーのどのポートに行けと指示、などの方法が検討されている
  • フレームタイプ/SETTINGSの拡張を認めない。
    • 頭初はオレオレ拡張をしやすいように考えていた。
    • DoSの温床になる。TCP拡張のように途中のproxyなどで捨てられやすくなる。
    • ALPNで別のプロトコルとして定義すればいいじゃない
    • ずっともめてて、ハミングから投票なって言っていたが、ガチガチで結着
    • @Jxck_: じゃあIANA登録すんの? @jovi0608: -exp-ほげほげをつければいいじゃない的な話
  • TLSの利用条件を厳しく
    • TLS1.2を必須とする。ちょっとノリで決めちゃった印象? これはセキュリティーグループの人達もいる場で合意
    • DHEじゃなきゃいかんよ、という制限も
  • CRIME/BEAST対策。
    • HPACKが入ったがBODYはそのままなので理論的には見るのが可能になる。
    • ペイロードの先頭にpaddingを入れてマスキングしてやろうという。そのためにフラグを新設

HPACK-06の変更点

  • Request/Responseのハフマンテーブルを共通化。
  • cookieは特徴的なので専用のハフマンテーブルを新設
  • エンコーダー側からのTableSize指定
    • いままではエンコーダ側からこんなでかいの使えないよという指示ができなかった
  • draftはHTTP/2とHPACKで別に進めることになった

Priority Dependency

  • 優先度のユースケース例を追加した
    • ダウンロード順を指定しないとpushされても「そんなの知らん」ってなってしまう
    • backgroundの優先度が高いとforegroundのデータが来ない
  • Googleの提案
    • 優先度 or ストリームの依存、順番を指定
    • クライアントとサーバーでdependency listが同期していないといけない → 複雑すぎる
    • → weighted dependency groupでやってみよう。ツリーでなくグループ間のウェイトだけで制御できるのではないか

Security

  • HTTP/2をTLSに限定するか → HTTPも利用できるように(問題を先送りした)
    • HTTP/2はhttp, httpsどっちも使える(マーケットにまかせる)
    • firefox/chromeはhttpsのみ、IEはhttpもサポート → ちぐはぐに → サーバーでhttpを2.0対応すると、IEでだけアクセス可能になるかも
  • httpに日和見暗号は?
    • そもそも必要?
    • サーバー認証は?
    • 切りかえ方法は

今後の予定

  • 目標
    • 4月 WG Last Call
    • 8月 IETF Last Call

Q&A

  • クッキーのハフマンテーブルで「base64」ってどういうこと? → @jovi0608: base64かけたものをハフマン圧縮すると文字数が減る
    • 勉強会終了後、クッキーをbase64するとアルファベットが減るという話は、クッキーなんてどうせbase64だから、base64前提の頻度テーブル使えば縮むんじゃね、という話ではないか。という指摘があり、@jovi0608 さんからそうだとの返答がありました
  • CRIME/BEAST ってBREACH? → @jovi0608: そう
  • public key pinningは仕様として入ってきそう? → @jovi0608: WGとしては別。MITM対策をHTTP/2の仕様上に出すかどうかは議論になったが、いまいまはないという結論。日和見暗号が入ったときに出るかも
  • TCPを土管として速いHTTPをやろうというのがHTTP2だろうと思うが、TCPについてはカヤの外? CiscoとかF5は何て言ってる? → @jovi0608: 組織を代表してはいないので → @lef: SPDYとか最初のほうでさんざん話したので今さらなんだろう
  • 日和見暗号とは? → サーバ認証が証明書などによってちゃんと本物かどうか確認できていない状況でも、通信路は暗号化しようということ

@kazu_yamamoto: 「HPACK05 の実装と解析」

  • 資料
  • HPACK05を実装して、解析してみましたという話
  • 自己紹介
    • 昔mewとかやってました
    • Haskellerです。GHCの開発に参加してます
    • HTTP/2はわからないけどHPACKを実装してます
  • 圧縮率を調べてみました(符号化する側)
  • 高速化の実装あれこれ(両側)

圧縮率

  • HPACK作ってみたことある人 → 8人くらい
  • HPACKの圧縮技術
    • インデックス: ヘッダ名+値を番号で表現
    • リファレンスセット: ヘッダの差分を計算
    • ハフマン符号: 文字列のまま圧縮
  • インデックス
    • ヘッダ名+値に番号をつけ、次からは番号で参照。すごく圧縮できる
  • リファレンスセット
    • ヘッダ全体をセットとして、行ごとの追加/削除。言うのはカンタンだが実装はとても難しい
  • ハフマン符号
    • 出現率の高い文字を少ないビット数で表現する
    • 統計はすでに取ってあってテーブルは固定
  • 圧縮技術の使いよう
    • リファレンスセットを使うときはインデックスも必要
    • 6種類の使い方があるだろう。実験のために名前をつけてみた(WGで決めたものではないので以降のスライドを参照する場合は注意)
  • 実験
    • 相互接続テストで使ったデータを圧縮してみて、元のヘッダに対してどれくらい縮むか調べた
    • 実装にバグがないかも、すでに存在するものと比較して検証した
  • 実験結果
    • ハフマン符号は得
    • 【悲報】 リファレンスセットを使っても短くならない
    • ハフマンは縮むけどHEADERフレームあたりで31バイトにしかならないので、重要かどうか疑問
    • @jovi0608: stream fireはどうしている? 違うホストのデータを混ぜてるから圧縮が効かないんじゃない? 特定のホスト向けだけに限定すると縮むのでは?
  • 提案: リファレンスセットを削除する
    • @jovi0608: 仕様からは消さなくても使わなければいいだけでは? Googleはでかいクッキーがあるから得だと言っている → @kazu_yamamoto: インデックスで番号で指定するから1バイトしか得にならない

高速化

  • プロファイル取ってみて遅いところ: インデックスの探索、ハフマン復号化、ハフマン符号化
  • インデックスが遅い
    • ハッシュを使うとハッシュ値攻撃をくらいそうなのでツリーを使っています
  • ハフマン復号化が遅い
    • “Fast Prefix Code Processing”という論文を見つけた
    • nビット単位で状態遷移を事前に計算しておく
    • 遷移しながら出力する文字と、遷移後の状態を記録
  • ハフマン符号化のシフトが遅い
    • シフトは7種類しかないからあらかじめ計算しておく
    • 表引きとorで計算できる

Q&A

  • @Jxck_: あらかじめ計算した状態マシンとテーブルでどれくらいのサイズ? → 257文字の2分木を16分木にするのでノード数はそう増えない。256にすると40ノードでしたっけ
  • @jovi0608: MLに定量的なデータを出して提案してみたらどうかな
  • @lef: CRIMEのときに、少しでも情報を送信したくないという力が働いて差分という話になってきている

Jxckさんより

  • interimの合間にハッカソンをやっていた
  • そろそろ仕様も固まってきたので、いまからでも参加したい方はどうぞ
  • 実装者は日本がかなり多くなってきた
  • 2/16(日)、となりの部屋でハッカソンやりましょう
    • (前田注: 天候の問題で2/23(日)に延期になりました)
  • これを期に参加したい人のためにしきいを下げたいと思います
  • 3月にIETF
  • その後またみやげ話を聞く会をやります

以上です