http2化される世界

http2が普及すると世の中はどうなるのでしょう。そもそも普及するのでしょうか。

8.1. http2は一般の人々にどのような影響を与えるのでしょうか。

http2はまだ広くデプロイされておらず、また使われていません。我々は今後どうなっていくのか自信を持ってここで語ることはできません。我々はSPDYがどのように使われているか見てきました。その経験やその他の過去および現在の実験をもとに推測や計算をすることができます。

http2はネットワークラウンドトリップの回数を削減します。ヘッドオブライン・ブロッキングのジレンマを多重化と不必要なストリームをすぐに捨て去ることにより完全に回避します。

今日もっともシャーディングが多用されているサイトよりも多くの並行ストリームを使用することができます。

優先度をストリームに適切に適用することで、クライアントは重要なデータをあまり重要ではないデータの前に受信することができる可能性が高まります。これらを総合的にみると、高速なページロード、そしてよりレスポンシブなwebサイトを実現できる可能性が高いと言えます。単刀直入にいって、よりよいwebのエクスペリエンスにつながるのです。

どの程度速くなるのか、またどの程度改善するのか、といったことはまだわかりません。まず第一に、この技術はまだ初期の段階であり、これらプロトコルが提供する能力を余すところなく使い切るクライアントとサーバー実装はまだありません。

8.2. http2はweb開発にどのような影響を与えますか？

この何年かでweb開発者とweb開発環境はトリックや道具をたくさんかき集めてきてHTTP 1.1の問題を回避してきました。私がこの文書の最初にhttp2の正当性の証としてそれらの中のいくつかを紹介したことを思い出してください。

ツールや開発者が今日何も考えないで使っているこれらの回避策の多くはおそらくhttp2の性能に悪影響を与える、または、少なくともhttp2のすばらしい能力を余すところなく使いこなすことができない、ということになるでしょう。スプライティングとインライニングは殆どの場合http2ではすべきではありません。シャーディングもhttp2にはおそらくよくない結果となるでしょう。というのはhttp2は少ない接続数から恩恵を得るからです。

ここでの問題はもちろんwebサイトとweb開発者は、少なくとも短期間はHTTP 1.1とhttp2のクライアント両方のために開発とデプロイをする必要があることです。全ユーザーに最高の性能を提供することは2つの異なるフロントエンドの提供なくしては容易ではありません。

この理由だけをとってみても、http2の潜在能力が完全に発揮されるまでは少し時間がかかると私は考えています。

8.3. http2の実装

特定の実装についてこの文書で触れることは、もちろん理にかなったことではありませんし、失敗することは目に見えています。ほんの少し時間が経てば古くなってしまいます。そういうことはせず、私は広い視点での状況を説明することにして、読者には実装のリストを参照していただくことにします。

早くから多くの実装が存在していて、http2の作業中にも増えてきました。この文書の執筆時において40を超える実装がリストに載っており、それらのほとんどは最終版を実装しています。

8.3.1. ブラウザ

Firefoxは最新ドラフトにもっとも速く追随してきたブラウザです。Twitterは最新版に追随しサービスをhttp2で提供しています。Googleは2014年4月頃からGoogleのサービスを提供するテストサーバーでhttp2をサポートしていて、2014年5月から開発版のChromeでhttp2サポートを提供しています。マイクロソフトは次期Internet Explorerとしてhttp2をサポートしたプレビュー版を公開しました。SafariとOperaはhttp2に対応予定であると言っています。

8.3.2. サーバ

既に多くのサーバがhttp2をサポートしています。

人気のあるNginxサーバは2015年9月22日の1.9.5からhttp2を提供しています。 （SPDYモジュールの置き換えが必要で、SPDYモジュールとhttp2の共存はできません。）

Apacheのhttpdサーバは2015年10月9日にリリースされた2.4.17からhttp2モジュール mod_http2 が提供されています。

H2O、Apache Traffic Server、nghttp2、Caddy、LiteSpeedは全てhttp2が使用できます。

8.3.3. その他

curlとlibcurlは平文とTLS両方のhttp2をサポートしています。複数のTLSライブラリで対応を行っています。

Wiresharkはhttp2をサポートしています。http2のネットワークトラフィックを分析するための完璧なツールです。

8.4. http2に対するよくある批判

このプロトコルの開発中、議論は前後しました。もちろんこのプロトコルは完全に間違いであると信じている人も確かにいました。私はよくある批判のいくつかに言及し、それに対する回答を述べたいと思います。

8.4.1. ”プロトコルはGoogleによって作られた”

世界はさらにGoogleに依存または支配されていくことを示唆するような亜種の批判もあります。このプロトコルはここ30年間に開発されたプロトコルと同様の手法でIETFによって開発されました。しかしながら我々はSPDYにおけるGoogleのすばらしい仕事を認めています。それは新しいプロトコルがデプロイできるということを証明しただけでなく、それによりどのような効果が得られるのかを示す数値も提供しました。

Googleが公式に発表したところによると、SPDYとNPNをChromeから2016年に削除し、サーバーもHTTP/2に移行していくことを急ぐということです。

8.4.2. ”ブラウザーだけが得をするプロトコルだ”

これはある意味本当です。http2の開発を裏で牽引した主要なものの一つはHTTPパイプライニングを修正することです。あなたのユースケースがパイプライニングを必要としないのなら、http2はあまり大きな効果をもたらさないかもしれません。これだけがプロトコルにおける改善点ではありませんが、しかし大きな改善点の一つです。

サービスが1接続上の多重化されたストリームがもたらす真の力と能力を理解し始めるとすぐに、我々はより多くのアプリケーションがhttp2を使うことを目にすることでしょう。

小さなREST APIや簡素なHTTP 1.xのプログラムにおけるユースケースはhttp2へ移行しても大きな利点を得られません。しかし、また、ほとんどのユーザーにとってhttp2がもたらす欠点はほとんどないはずです。

8.4.3. ”プロトコルは大規模サイトでしか有用ではない”

そんなことはありません。多重化の能力は、地理的に広範囲に分散していない小さなサイトでありがちな遅延の大きい接続におけるエクスペリエンスを大きく向上させることに寄与するでしょう。大規模サイトはほとんどの場合もうすでに速くてより分散していて短いラウンドトリップ時間をユーザーに提供しています。

8.4.4. ”TLSによって遅くなる”

これはある程度真実だといえます。TLSハンドシェイクは少し余計に時間がかかります。しかしTLSにおいて必要なラウンドトリップを削減する試みが今までもありましたし、現在も進行中です。通信路上で平文ではなくTLSを使うことによるオーバーヘッドは無視できないし、より多くのCPUと電力が同じトラッフィクパターンの平文に比較して使われることになります。それがどのくらいでどの程度の影響力を持つのかについては意見や測定結果次第です。有用な情報源の例としてistlsfastyet.comを参照してください。

電話会社や他のネットワーク事業者、例えばATISオープンWebアライアンス、は、サテライトや機内のようなところでの高速なwebエクスペリエンスを提供するためにキャッシング、圧縮、その他諸々の技術が必要であり、それには平文のトラッフィクが必要だと言っています。http2はTLSを必須としているわけではありませんのでこれ以上議論を複雑にすべきではありません。

多くのインターネットユーザーはTLSが広く使われることを望んでいますし、我々はユーザーのプライバシー保護を促進すべきです。

実験ではTLSを使うと新しいプロトコルを80番ポートで実装するよりも高い成功率があることを示しています。というのは数えきれない中継器が世界に存在していて、80番ポートを通るならHTTP 1.1だと思い込んで、ときどきHTTPにみえることもあるからですが、妨害するからです。

最後に、http2の1接続上に多重化されたストリームの恩恵により、通常のブラウザーのユースケースではTLSハンドシェークの回数が削減されることになりHTTP 1.1を使うHTTPSよりも速くなる可能性もあります。

8.4.5. ”ASCIIではなくなるということは深刻な問題だ”

はい、我々は平文でプロトコルを見ることができるということを好みます。なぜならデバッギングやトレースが容易になるからです。しかしテキストベースのプロトコルはエラーを誘発しやすく、より多くのパースにおける問題を引き起こします。

あなたが本当にバイナリプロトコルを使えないというのなら、HTTP 1.xのTLSや圧縮も扱えなかったはずですが、これらは長い間我々と共にあって使われてきたのです。

8.4.6. ”HTTP 1.1よりも速くない”

これについては、もちろん速いというのが何を意味してどうやって計測するのか議論しなければなりませんが、SPDYの頃から多くのテストが行われていて速いページロードを証明しています（例えば、ワシントン大学の人々による"How Speedy is SPDY?"、Hervé Servyによる"Evaluating the Performance of SPDY-enabled Web Servers"）。このような実験はhttp2でも同様に繰り返されてきました。私はより多くのこのようなテストや実験が公開されることを楽しみにしています。httpwatch.comによる最初の基本的なテストはHTTP/2がその約束を果たしていることを示唆しています。

8.4.7. ”これは階層侵害だ”

本気でそう思っていますか？層は世界的な宗教の触ることができない聖なる柱ではありません。我々がhttp2の開発に際し、グレーゾーンに足を踏み入れた時は、与えられた制約の中で効率のいいプロトコルを作るという意思をもってのことでした。

8.4.8. ”HTTP 1.1の弱点のいくつかは修正されない”

これは本当です。HTTP 1.1のパラダイムを維持するという目的に沿い、いくつかの古いHTTPの機能は残されました。よく使われる、もう見たくもないcookieやauthorizationヘッダーなどがそうです。しかしこれらのパラダイムを維持したお陰で、基本的な部分を完全に書き換えるというアップグレード時の頭のくらくらするような膨大な作業なしにデプロイできるプロトコルを得ました。http2は基本的に新しい層の一つです。

8.5. http2は広く普及するか？

回答するには時期尚早ですが、私なりに推測と予測をしてみたいと思います。

反対論者は普及が開始するのに数十年もかかる新しいプロトコルの例としてこういうでしょう。”IPv6が何をなしてきたかみてみろ”と。しかしながらhttp2はIPv6ではありません。それはTCP上で動作し、普通のHTTPアップグレードメカニズムやポート番号そしてTLS等を使います。ほとんどのルーターやファイヤーウォールを変更する必要はありません。

GoogleはSPDYにより、短期間で新しいこのようなプロトコルがデプロイできて、ブラウザーやサーバーの複数の実装間で使うことができるということを証明しました。インターネットで今日SPDYをサポートするサーバーの数は1%の域ですが、これらサーバーが扱うデータの量ははるかに大きいのです。今日におけるいくつかの極めて人気のあるwebサイトはSPDYをサポートしています。

http2はSPDYと基本的に同じパラダイムを有しますが、IETFのプロトコルであることから、より広くデプロイされるだろうと私は考えています。SPDYのデプロメントは”Googleのプロトコル”という汚名により若干縮小気味です。

有名なブラウザーもリリースを控えています。Firefox、Chrome、Safari、Internet Explorer、Operaの代表者たちはhttp2をサポートするブラウザーを出荷すると表明していますし、実際に動く実装を世界に示しています。

Google、Twitter、Facebookといった巨大なサーバー事業者もhttp2を近々サポートする予定です。我々はApache HTTPサーバーやNginxといった人気のあるサーバー実装にhttp2が実装されることを望んでいます。H2Oはとてつもなく高速なHTTPサーバーでhttp2をサポートしていてその潜在能力を示しています。

HAProxy、Squid、Varnishといった巨大プロキシーベンダーはhttp2サポートの意思を示しています。

2015年全体を通して、HTTP/2のトラフィック量は増加しています。9月の初めにおいて、Firefox 40での使用率はHTTP全体の中の13%、HTTPSに限定すると27%でした。Googleは18%のトラフィックがhttp2だったと言っています。Googleは他の新しいプロトコルの実験も同時に行っている（12.1のQUICを参照してください）ので、http2の使用率は低く出てしまうことに注意してください。