HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏 (4)

2013/2/8-1

どういう意味かというと、HTTPに接続しつつも、実際はその下はTLSであるという可能性もあるということです。もしかしたら、証明書を確認せずに日和見暗号化(opportunistic encryption)しか行わないかも知れません。そういった暗号化はアクティブな攻撃は防げず、パッシブな攻撃しか防げません。しかし、カフェでのスニフィングによる攻撃を防ぐことはできます。

この話は、議論されました。ただ、現時点ではどうなるのかわかりません。柔軟性があることは良いことです。

Q: 既存のドラフトでは、HTTPメソッドを「HTTP 1.1」としつつ、HTTPヘッダ部分にUpgradeヘッダを含むことでHTTP 2.0のリクエストであることを示しています。これは、今後の新しいHTTPバージョンも、HTTPリクエストラインにおいて「HTTP/1.1」というバージョン番号を使い続けることを意味しますか？

まだ、はっきりしてません。いま行われているのが、upgradeヘッダを利用するというものです。

もうひとつは、TLSを利用してネゴシエーションを行うというものです。そこでは、HTTP 2が利用されます。

あと、DNSにヒントを入れることも議論されています。恐らく、新しいレコードタイプになると思います。それによって、名前解決を行っている時に、HTTP 2.0対応であるかどうかを知ることができます。 Webブラウザ開発者は、その手法に興味を示しています。

さらに、以前のSPDYが考えていた概念もあります。その方式は別のプロトコルですが、SPDYを使える場所が記述されたヘッダを返します。

現在、HTTP 2.0サービスへと到達する手法として、3つか4つのプロポーザルがあります。それらは、いかにしてラウンドトリップタイムを避けるかを考えています。

一般的なケースでは、HTTP 2.0をリクエストして、その結果を得るだけなので良いのですが、問題はPOSTするときや、何かを多重化するときです。そこでラウンドトリップ分の時間を無駄にしてしまいます。

Q: 現在のドラフトに書かれているフローコントロールには "hop-by-hop" という表現があります。"hop-by-hop"って何ですか？

フローコントロールに関しては、まだあまり議論できていません。それに関しては、今週議論する予定です(取材者注：インタビューは東京で行われたinterimミーティング前に行なわれました)。

ご覧になったドラフトは、予備の議論を元に色々なものを詰め込んだSPDYドラフトです。現時点で公開されたものを読むことはお勧めしませんし、「このドラフトに書かれているものを実装しないで欲しい」と言っています。

数週間後に新しいドラフトを公開し、「このドラフトが実装を開始しても良い最初のドラフトです。フィードバックをお願いします。」と言えると思います。

Q: 現在公開されているドラフトに書かれているPINGはどうですか？

PINGに関しては、まだ全く議論していません。 PINGは、コネクションを維持するためと、以前のコネクションをテストするために使われます。

シナリオのひとつは、「既存のコネクションがあり、それがしばらく利用されておらず、それを利用してPOSTを送りたいとき」です。現在、非常に多くの実装が古いコネクションでPOSTを利用しないようになっています。 POST送信中にコネクションが死ぬと、どのデータが実際にサーバまで送信されたか全くわからないという悪い状況に陥ってしまいます。それを避けるために、新しいコネクションを確立するという手法が行われています。

PINGは、POSTを送信する前にコネクションのテストが可能になるので、便利です。

Q: AkamaiのSPDY実装について教えて下さい

AkamaiのSPDY実装は現在β版です。多くのお客様にβ版をご利用頂いていますが、それによって多くの計測データを得たいと考えています。私達は非常にユニークな立場にいることもあり、私は、そこで得られるデータから数値情報を作りたいと考えています。

GoogleにはGoogleのサイトがありますが、それはGoogle単体での分析に過ぎません。我々には、幅広く多角的に見ることができます。サイト毎に異なる視点を持つことも可能であることも、我々に取って大きな価値があります。

もちろん、これはゆっくりとしたプロセスではあります。これは全く新しいことで、それによってお客様に悪影響があってはならないためです。

Q: HTTP 2.0がRFCになるのはいつ頃だと思いますか？

ノーコメントで(笑。

Q: IETFのhttpbisワーキンググループのチャーターページにあるマイルストーンには、2014年にworking group last callを目指すとありますが？

チャーターには、向上心が溢れる記述がされるものです。

RFCの執筆作業というのは、ときおり非常に苦痛となることがあります。みんなそれぞれ各自の意見がありますし、異論が多かったり、価値があったりすると、コンセンサスを得ることが困難になります。でも、そういうものなんです。

HTTP 2.0に関して、最も関連する組織はIETFとW3Cです。そのため、我々は、その両方で活動をしています。

私は、いつも、「どっちでやるほうがいいだろうか？」と問うています。

Q: IETFとW3Cは、どのように協調しているのでしょうか？

ときどきカンファレンスを行います。非常に良好な関係を築けています。我々は、注意した方がよさそうな部分を指摘し、調整します。たとえば、W3Cで行った方が良いと判断したため、IETFで行われていた議論をW3Cへと移行したものもあります。

しかし、組織というものは資源に制約があり、そのうえ政治的な制約が存在する場合もあります。

Q: HTTP 2.0によってHTML5の仕様に影響があることも考えられますか？

無いと思います。

HTML5の人々とも良好な関係を築けています。彼らは、非常に興味を持っており、伝統的な標準化の世界とは全く異なるアプローチを取ってくれているので上手くいってます。

HTML5に対応するために、HTTP 1.1に対していくつかの変更を行いました。私が担当しているワーキンググループでは、HTTP 1.1の見直しと明確化も行っています。

次に我々が行わなければならないのは、WebSocket APIをHTTP 2に入れることによって、既存のHTTP 2コネクションを再利用出来るようにすることです。たぶん、そのことに皆は賛成してくれると思います。

WebSocket APIは非常に興味深いものですが、レイヤが低いAPIです。サーバとクライアントがそれぞれひとつずつのときは良いのですが、それを大規模にやろうとすると、専用のインフラを構築する必要が出てしまいます。

標準化という視点では、HTTP 1.1は急いで書かれたこともあり、非常に駄目な文書です。ただ、HTTP 1.1のアーキテクチャを一度理解すれば、WebSocketのようなことが出来ない理由はありません。単に、実装が特定のユースケースのみを想定して行われてしまったというだけなんです。

HTTP 2が目指しているチャレンジのひとつが、HTTP 1.Xとの下位互換性を維持しつつも、まだ誰も考えたことが無いような新しいユースケースに対する上位互換性も実現することです。それには、APIの抽象化が必要ですが、そのAPIによって、たとえばWebSocketなども実現できる必要があります。

Q: HTTP 2.0によってトラブルシューティングの難易度が上昇したりするでしょうか？

TLSによってデバッギング難易度が上昇する可能性があります。

それよりも、ヘッダ圧縮によってデバッギングが困難になるかも知れません。この問題は、何度も議論されています。

そうなると、ストリーム開始後にtcpflowやwiresharkなどのデバッガを起動しても、ステートを解読することができません。

これまで、多くの人々がこの件で抗議をしていますが、いまのところのコンセンサスは、ヘッダ圧縮によって得られる利点には価値があるというものです。得られるメリットと、想定されるデメリットを考慮しつつ、バランスの取れた判断をする必要があります。

我々は、可能な限り痛みが発生しないような調整をしようとしています。

Q: ありがとうございました

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！