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

現在、JavaScriptのロードを複数に分けて出来るようにするという議論がHTML5で行われています。 もしかしたら、パーサが漸進的にロードが行えるようにするための新しいメディアタイプが作られるかも知れません。 そういった手法は、次世代のFEOと言えそうです。

いまのところは、あまり話として登場しませんが、HTTP 2に関連してアプリケーション層における様々な問題を修正していくというものもあります。 そうすると、トランスポート層における問題が、より一層明らかになるでしょう。

今は、非常に多くの注目がトランスポート層に向けられています。 TCPに関する非常に多くのプロポーザルが提案されていますが、TCPを置き換えるという議論まで登場しています。

HTTP 2とTCPは、全く異なる話ですが、そのレイヤーをどのように改善できるのかも見ています。 棒でつついてみて、何を修正できるのかを探しているような感じです。 いくつかの議論は、「これを無くして、他の何かに置き換える必要がある」というものだったりもします。

そういった話はエキサイティングではありますが、同時に危険でもあります。 IETFに居るような人々と話すときは特にね。

Q: TCPパフォーマンスの議論は、もう何十年も続いていると思います

はい。同じ議論が何度もくり返されています。

そろそろ新しい血が必要だと思います。 何人かと話をしていますが、何か新しいことが起きようとしているのを感じます。

それらは、書かれる必要があり、それに関してワクワクしている人々がいます。 しかし、一方で、ワクワクしていない人々もいます。 まあ、そういうことですよ。

Q: 既存のドラフトのintroductionでは、SPDYによるTCPコネクション数に関して「今よりも少ないTCPコネクション数」とあります。しかし、4.1項では、「クライアントは、同一の相手に対して同時に複数のHTTP/2.0セッションを張るべきではない」と不整合があります。SPDYでのTCPコネクション数は、いくつぐらいになるのでしょうか？

現在、既存のHTTPは4から8のTCPコネクションを利用しているようです。 HTTP 2では、ひとつか2つのTCPコネクションになると思います。 それは、fairnessという視点では改善されたと言えます。

2つのTCPコネクションによって、多少の並列処理は残っています。 しかし、TCPスタックの制約を改善することができれば、ひとつで十分になるかも知れません。

トリッキーなのはここです。 スループットと同時にfairness問題がついてくるわけです。

HTTP 1.0およびHTTP 1.1が現在かかえる問題は、HTTPフローが短いことが多いことです。 TCPが性能を出せるまえにセッションが終わります。 SPDYフローがより長い時間継続し、HTTPフローが長くなれば、TCPも十分な性能を発揮できるようになります。 そうあるべきですが、これは全く新しいことです。

Googleは運用経験を持っているので、この件に関して非常に自信を持っていますが、ほとんどの人々はまだこれからです。 テストベッドを用意し、β版を公開し、長期的視点でそれらがどのような挙動を見せるのかを観察する必要があります。

みんなが利用することによるネットワーク効果もあります。 GoogleとGoogle Chromeだけが利用しているときには良くても、世界全体が使い始めたらそれは全く話が違ってきます。 ということで、やらなければならないことは非常に多くあります。

Q: HTTP 2.0はパフォーマンスを向上させるであろうことは理解できます。しかし、サリーフロイド氏らによるRFC5348にあるTCPスループット評価式を見てもわかるように、TCPには制約があります。そのため、Webブラウザは複数のHTTP 2.0セッションを張った方が性能を出せると推測されます。いまどきのブラウザにはDNSプリフェッチ機能など、パフォーマンスのためにアグレッシグな取り組みがおこなわれがちです。そう考えると、Webブラウザ実装者は、複数のHTTP 2.0セッションを張る実装をしていくんじゃないかと予想できませんか？

最新のWebブラウザがどうなっているのかは見ていませんが、以前のバージョンでは、SPDYコネクションは2本だけでした。 開発者達は高潔な人々であり、fairnessに対する影響を正しく理解しています。 彼らは、世界をより良い場所にしたいと考えています。

ただし、ご指摘のように、実用主義というものもあります。 たとえば、ひとつのものをダウンロードするためにTCPコネクションを50本も張るようなダウンロードマネージャを書くような人もいるわけです。 それに対しては、何もしようがありません。

しかし、Webブラウザは、エコシステム内において自分達の立場を理解していると思います。

私にとって、少ないTCPコネクション数による面白い環境としてあげられるのが、モバイル環境においてHTTP 2プロキシが1つか2つのTCPコネクションを維持しつつ、TCPコネクションを暖めておき、ヘッダ圧縮も行うような場合です。 一般的なWebブラウザで考えられるシナリオというのは色々考えられますが、我々はそれらに関しても検討する必要があると考えています。

Q: HTTPとTLSのネゴシエーションに関して質問です。単一のTCPポートを利用してTLSありとTLSなしの通信を同時に出来たりしますか？

恐らく出来ないと思います。 理論的には可能ですが、多分無いだろうと思います。

(続く：次へ)

最近のエントリ

• 日本のIPv6採用状況が50％を超えている件について
• 「ピアリング戦記」の英訳版EPUBを無料配布します！
• IPv4アドレス移転の売買価格推移および移転組織ランキング100
• 例示用IPv6アドレス 3fff::/20 が新たに追加
• ShowNet 2024のL2L3
• ShowNet 2024 ローカル5G

過去記事

過去記事一覧