HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏 (2)
ヘッダ圧縮
もうひとつの大きな要素はヘッダ圧縮です。
HTTPヘッダは、何度も同じ内容をくり返していることは良く知られています。 たとえば、全てのリクエストは、毎回同じ user agent で送信されます。 refererも、似たような内容だったり、時として全く同じ内容が送信されます。 コンテンツネゴシエーション、フォーマット、言語環境等に関するヘッダも同様です。
しかし、そうやってWebが作られているので、我々は、それらを全て維持しなければならないのです。 Webを壊すわけにはいきません。 好むと好まざると、Webサイトはこれらの情報を利用しているので、「こういった情報を取り除き、全て変更します」という判断はできません。
回線上での効率を上昇させるために、我々はそういった部分をエンコードして圧縮する必要があります。
FirefoxでSPDYとHTTP/2.0の開発を行っているPatrick McManus氏が、83個の画像などを含むページを取得する実験を行いました。 その実験では、WebブラウザがHTMLを取得するためのGETを送信し、HTMLを受け取ります。 その後、Webブラウザは、HTMLに記述された83個の画像やCSS等を取得します。 ネットワーク環境が完璧であり、HTTPにおける多重化が行われていたとしても、HTTPヘッダを運ぶパケット達は3回ないし4回のラウンドトリップで送信されていました。
ヘッダを圧縮することで、複数のリクエストをひとつのパケットに押し込むことが出来れば、それは非常に大きな効率化となります。 その機能は、SPDY 3に含まれており、Zlibで実現されていました。
ただし、Zlibを利用したSPDY 3のアプローチは、今は使われていません。 それは、CRIMEという攻撃がそのアプローチに対して可能であることがわかったためです。
TLS上でSPDY 3のアプローチを使った場合、ペイロードの中にクッキーやリンクなどを突っ込むことが可能です。 Webブラウザに何らかの動作をさせることも比較的容易に可能です。 TLSで暗号化された通信路から、セッションキーやパスワードなどのテキストを取り出すことも可能です。 それらは、容認できません。
現時点でのヘッダ圧縮まわりの議論は、ヘッダを効率的に運びつつも、こういった攻撃を防ぐ方法を探すこととなっています。 今週のinterimミーティングでも、それらは議論されます。
現在、それに対して4つの異なるプロポーザルが提出されていますが、あと2つか3つぐらい出ると思います。 我々は、それらのためのテストベッドも持っているので、各提案がどのように動くのかを試す予定です。
ただ、私にとってヘッダ圧縮はエキサイティングです。 それは、モバイル環境においてパフォーマンスを劇的に改善できる可能性があるからです。 そして、圧縮の仕組みを上手く作れれば、新しいヘッダを追加するコストが高価ではなくなります。 たとえば、GoogleのIlya Gregoric氏は、クライアントに対してもっとリッチな機能を持たせるというプロポーザルを出しています。 現時点では、彼らはJavaScriptを使って「私のエージェントのスクリーンサイズはこれです。JavaScriptエンジンの持っている機能はこれです」を伝えています。 HTTPヘッダにこういった情報を入れることができれば、ネットワークの途中経路上にある機器によって、様々な興味深いことができるようになります。 ヘッダ圧縮が上手く働けば、それを追加するコストを気にせずに、もっとリッチなメタデータを扱えるようになります。
ということで、多重化と優先度付け、そしてフローコントロール。 ヘッダ圧縮と、それに関する懸念という二つを紹介しました。 議論に時間がかかっている主な議題はその二つです。
TLSを必須とするかどうか
TLSを必須とするかどうかに関して、非常に長い間議論が続いています。 それには、いくつかの理由があります。
ひとつは、新しいプロトコルをWebでデプロイするのが難しいということがあげられます。 新しいプロトコルへのHTTP upgradeのメカニズムを理解せず、下手な書かれかたをした中間機器が非常に多く存在しています。 それらがどれぐらいの数存在しているのかに関しては、現在調査中です。
もうひとつの理由は、多くの人々がWebセキュリティをアップグレードする良い機会であると考えていることがあげられます。 いまや、暗号化を行うためのマシンパワーも十分安価になりましたし、証明書も十分安価になりました。 セキュリティが不十分なWebサイトを立ち上げるべきではありません。 WiFiポイントの近くで座りながらほとんどのWebサイトのセッションキーを盗んでログイン可能な攻撃があるような状況では、特にそうです。 Firesheepは、素晴らしいデモだと思います。
政治的に言うと、TLSを必須にするのは、恐らく無理です。 それは、様々な組織が関わっているためです。 たとえば、APIのバックエンドでHTTPを使っていたり、追加のオーバーヘッドを避けたい中間機器ベンダーだったりします。 とはいえ、実際は何かひとつにアップグレードするという話ではなく、現在は複数のものへのアップグレードが可能となるようにプロトコルを設計しています。
今は、ブラウザとサーバがネゴシエーションを行えます。 「私はHTTP 1.1をサポートしています。私はTCP上のHTTP 2をサポートしています。私はTLS上のHTTP 2をサポートしています」といった感じです。 それらのうち、どれを選ぶのかはブラウザ次第です。 そして、ブラウザが暗号化なしのTCP上でのHTTP 2を実装しないという選択をしても驚きません。
(続く：次へ)
最近のエントリ
- 「ピアリング戦記」の英訳版EPUBを無料配布します！
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
- ShowNetのローカル5G企画（2022年、2023年）
過去記事
