HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏
昨年後半、IETFのhttpbisワーキンググループでHTTP 2.0標準化に向けた動きが開始されました。 そのhttpbisワーキンググループのチェアであるMark Nottingham氏(Akamai)に対するインタビューの機会を頂けました。 Mark Nottingham氏は、HTTP 2.0標準化の舵取りをしている方です。
非常に興味深い最新状況を伺えたので、可能な限り生に近い情報をお届けします(日本語に翻訳する前の英語版はこちら)。 お楽しみ頂ければ幸いです。
Q: HTTP 2.0標準化開始の経緯を教えて下さい
HTTP 1.1とHTTP 1.0には、よく知られた制限があります。 特に顕著なのが、ひとつのコネクションでリクエストを出してレスポンスを受け取ることしかできないという点です。 しかも、HTTP 1.0では、リクエストに対するレスポンスを受け取るまで、次のリクエストを出すことができません。
HTTP 1.1では、その問題を解決するためにパイプラインの仕組みが導入されました。 しかし、HTTP 1.1のパイプラインを使ったとしても、非常に大きなレスポンスやレスポンスを返すまでに時間がかかる場合などには、そのコネクション上でリクエストがブロックされ続けるという状況が発生します。 さらに、パイプラインそのものにも様々な課題があり、それらに関してhttpbisワーキググループで数年間議論し続けています。
こういった背景から、昔から、HTTPの世界に多重化があった方が良いと言われていました。 HTTPの多重化とは、複数のリクエストとレスポンスを単一のコネクション内で自由に行うものです。 そのコネクション内で、それらのやり取りがインターリーブします。
2000年代前半に、HTTPngと呼ばれる、そのような取り組みがありました。 しかし、ほとんど関心が示されず、失敗しました。 そのため、我々はHTTP 1.1を10年以上使い続けています。
ここ数年、多くの人々がWebパフォーマンスの重要性を認識し、少しでも良いパフォーマンスを実現するために力を注いでいます。 そういった努力の前に、HTTPそのものが持つ制約が立ちはだかります。
HTTPコミュニティでは、「HTTPngで一度やろうとして駄目だったことだし、また同じことをやろうというのは無理だな」といつも思っていました。 しかし、ブラウザが進化やイノベーションに対してアグレッシブになってきたという状況の変化もあり、新しいHTTP標準化が可能となりました。
GoogleのMike Belshe氏とRoberto Peon氏がSPDYのプロポーザルを持ってきました。 Googleは、WebサイトとWebブラウザの両方を持っているという非常にユニークな立場だったこともあり、彼らはSPDYの実験を行うことができました。 このことに関して、「Googleが」と言う人も多いのですが、実際は「Googleが」というよりもMikeとRobertoが20%時間で独自にやったことなんです。 少しずつ、そして確実に、この取り組みが重要でありそして良いことであると、人々に納得してもらえるようになっていきました。 彼らが活動を開始した2009年に、Mikeと夕飯を食べながらミーティングをしていましたが、彼は「これは標準にしたい。Googleプロプライエタリにはしたくない」と言ってました。 その後、Firefoxが、この技術の利点を理解し、非常に興味を示すようになりました。 さらに、Akamaiが興味を示し、Microsoftが議論の場に加わるなど、他の組織も関わるようになりました。
そしていまは、変化を起こせるだけの業界内のムーブメントが明らかに存在しています。 我々は、Web全体を良くするためにプロトコルの新しいバージョンを作る機会を得ています。 それは非常にエキサイティングですが、失敗すれば誰にとっても良くないのでリスキーでもあります。
しかし、我々は実装者と連携しながら作業を進めているため、実装者からフィードバックを得ることができます。 今週、我々はブラウザ、ミドルウェア、サーバ、Webサイトの実装者が集まるミーティングを行います(取材者注：東京で行われたinterimミーティング前にインタビューしています)。 これらの人々が同じ部屋に入って議論できるのは、非常にエキサイティングです。
私にとって、非常に興味深く、また難しいのは、これによってより良いパフォーマンスなどを実現しなければならない点です。 しかし、かといって、この作業によって、これまでのWebとのインターオペラビリティを全て犠牲にし、Webを壊してしまうわけにはいきません。 この話は、あまり議論しているわけではないのですが、私は、Webが機能しているバランスというものがあると考えています。 Webには、様々な関係者が関わっています。 エンドユーザはブラウザを利用し、Webサイトがコンテンツを発信し、仲介するものや、ネットワークプロバイダもいます。 好むと好まざるとに関わらず、Webが運用に関して、これらの関係者の間でのバランスが必要になります。 既存のバランスをひっくり返すことはない、とは言いたくないのですが、非常に気をつけないと悲惨な副作用があるかも知れません。 我々が行っていることには、重い責任があるのです。
Q: HTTP 2.0の現状を教えて下さい
技術的な視点では、我々はいくつかのことをしています。 まず、完全な多重化を行っています。 効果的に送信しつつ、それぞれの繋がりを保ち、HTTPリクエストやレスポンスとして再構築できるようにするだけです。 これがトリッキーなのは、完全な多重化をしたとしても、互いにブロックする可能性がある要素は残っている点です。 たとえば、「私はサーバです。クライアントであるあなたに対してレスポンスを送ります。GIF画像を先に送りましょうか？それともJavaScriptもしくはCSSを最初に送りましょうか？」という感じです。 そこら辺の話を議論する必要があります。
そのため、現在議論されているプロトコルには、ヒントを交換することができる優先度(prioritization)という機構があります。 ただし、ブラウザにとって、その瞬間に何が重要であるかという話もあります。 たとえば、「私は今、コンテンツのこの部分を描画中なので、これら画像を下さい。とか、このJavaScriptを下さい」という感じです。 そうなると、何らかのフローコントロールも必要になります。 「あなたは色々と私に送りつけているけど、それによって私のバッファがいっぱいになってしまっているので、もうちょっとゆっくり送ってね」と言える必要があります。 フローコントロールをTCP全体で行うのか、それともフロー単位で行うのか(最近はフロー単位で議論が進んでますが)、下位層にあるTCPのフローコントロールとの関係など、これもまた非常にトリッキーです。 我々は、TCPのフローコントロールと似たものをゼロから再発明したくありません。 そのため、我々の作っている仕組みが正しく動くことを確認するために、下位層であるトランスポート層の専門家の助けも必要です。
(続く：次へ)
最近のエントリ
- 「ピアリング戦記」の英訳版EPUBを無料配布します！
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
- ShowNetのローカル5G企画（2022年、2023年）
過去記事
