こんにちは、編集長の白石です。

この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、様々な技術的なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、ヤフー株式会社にお勤めの大津繁樹さんと新部長則さんです。

▲左から、ヤフー株式会社 大津繁樹さん、新部長則さん

お二人のセッションは「大規模運用で見えるWebプロトコルの理想と現実、そして今後」（ルームB 13:20-14:00）です。 （現在HTML5 Conferenceは定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、諦めずにキャンセル待ちすることをお勧めします！）

日本最大級のHTTPS & HTTP/2化案件の実際

白石: まず簡単な自己紹介からお願いできますでしょうか？

新部: 私は2005年の7月に入社し、Yahoo!メールや広告の画像配信を行うCDNの運用などを経て、現在は全社で利用しているリバースプロキシの運用を行っています。 現在、社内でプラットフォームと呼ばれる部分にはだいたい関わっている感じですね。

大津: まさに、新部さんのチームは、ヤフーのトラフィックをほとんど全て受け止めていると言って間違いありません。国内最大級のトラフィックを支えているんです、半端ないですよ。

白石: では大津さんも自己紹介をお願いできますか？

大津: 私は昨年の10月に入社したばかりです。大きく2つの仕事をしていまして、Node.jsのコミッターとして社内のサポートを行っているのと、IETFでネットワークプロトコルの標準化活動に関わっています。

白石: ありがとうございます。では、ヤフーのサービスをHTTPS + HTTP/2化した際のことを伺ってもいいですか？

新部: まずはヤフーのサービスをHTTPSに移行するところから始めたんです。HTTPS化に伴うコストや影響の試算を踏まえて、2015年10月に、全社横断でHTTPS化するプロジェクトが発足したんです。

HTTPS化するにあたっては大きな問題が2つありました。1つは、TLSの暗号化・復号化の処理が重たいということ。もう1つは、証明書の管理が煩雑にならないようにしなくてはならないということでした。なにせドメインでいうと1,000以上、サービスも100以上ありますので。

白石: 規模感が普通の会社とは桁違いだ…。

新部: なので、全社共通のリバースプロキシを作って対応することになったんです。そのリバースプロキシでTLSを一旦終端させて、そこから先は通常のHTTP/1.1に変換し、各サービスにリクエストを転送する。

白石: そのリバースプロキシって、だいたいサーバ何台分くらいになるんでしょう…？

新部: 500台以上ですね。

大津: 「以上」と言っても幅があると思いますが、そのかなり上の方ですよ、実際の数字は(笑)。

白石: す、すごい…！

新部: そして、2016年3月、最初にリバースプロキシに乗ったのはヤフオク！です。

白石: なんでヤフオク!を最初のサービスに選んだんですか？

新部: 検証の意味も強かったので、ある程度以上の規模感のあるサービスをデプロイしたかったんです。あと、下手すると人命を左右するような「何があっても絶対に止められない」サービスは避けたかった。

白石: なるほど。

新部: ヤフオク！も、いきなり全部をHTTPS化したわけじゃなくて、最初は一部だけ、その後範囲を広げていったという感じです。 幸いにもそれほど大きな事故も起こることなく進んでいき、2017年の3月末には、特定のクライアントに提供しているところを除いたすべてのサービスがHTTPSで動作するようになりました。

HTTP/2化は正直、「エイヤ」でやった

白石: なるほど、HTTPS化は、様々なご苦労はあったことと思いますが、比較的順調に推移したということですね。そして今では多くのサービスがHTTP/2を利用しているんですよね。HTTP/2化はどういう流れで進んでいったんですか？

新部: これはちょっと言いにくいし、言っていいのかもわからないんですが…正直、「エイヤ」でやってしまったところもありますね(笑)。

全社共通のリバースプロキシを構築できたし、ここをHTTP/2化してしまえば、全部HTTP/2にできるじゃん、と。弊社のエンジニアもHTTP/2サーバの実装に携わっていたりもしたので、自分たちで作った成果を自分たちで使いたいという要望もありまして…。

白石: で、「エイヤ」でやっちゃったと(笑)。

新部: まあ、全部をいきなり切り替えたわけじゃないですけどね。こちらも一部のサーバだけを切り替えて、問題がないことを確認しつつ、だんだんと。

白石: なるほどー。ちなみにその、最も重要なリバースプロキシですが、具体的にはどのソフトを利用しているんですか？nginxとか？

新部: いや、Apache Traffic Serverというプロダクトです。元々これは米国のYahoo! Inc.が開発していたものをApache Software Foundationに寄贈したものです。

白石: では、Apache HTTP Serverとは関連がないんですね。

新部: そうです。このサーバをHTTP/2対応させるパッチの開発に、弊社のエンジニアもコミットしているんです。

「HTTP/2化で速くなったかは…正直わかりません(笑)」

白石: では、HTTP/2への切り替えは、それほど大きな問題もなくうまく行ったと。そうした環境で運用を行ってみて、実際にわかったことや問題などはありますか？例えばHTTP/2化することで、パフォーマンスが向上するんじゃないかという期待はあったと思うのですが。

大津: そうですね…正直に言ってしまうと、HTTP/2でパフォーマンスが上がったかどうかはよくわからないんです。

白石: ああ、それ先日インタビューしたあほむさん も同じこと言ってました(笑)。

大津: 個別に見れば、速度が上がっている部分は確実にあるんです。ただ、トータルで向上したかどうかは結局よくわからないんですよね。

例えば、window.onload が速くなったかというと、そうでもないんです。ただ、onloadについてはあまりにも様々な要因が絡むんで、測定の指標としてあまり有効でないという問題もありますけどね。なにせ、ずっと昔から運営しているサービスなので、 document.write にブロックされているページも残っていたりしますし。

白石: 確かに、「トータルで向上したか」と言っても「トータル」ってそもそも何なんだという定義が難しそうです。

大津: そういうところも含めて、測定が十分に行えていないというのも課題ですね。サーバ側のログを見ると、リクエスト数ベースでHTTP/1.1とHTTP/2の割合は現在4:6くらいです。

白石: 1.1がまだいるっていうのは…ああそうか、(HTTP/2に対応していない)古いブラウザを使っているクライアントですね。クライアントの環境も様々だから、余計測定が難しいですね…。

大津: そうなんです。一気に切り替えてしまったことで、A/Bテストなども行えていないですしね。A/Bテストを行うために、一部を一旦HTTP/1.1に戻すというのもありかもしれません(笑)。

HTTP/2がサーバの処理負荷を下げる？

白石: HTTP/2に移行する前の、HTTPSへの切り替えではいかがでしたか？先程、「TLSの処理が重たい」という懸念が事前にあったとのことでしたが。

新部: 一度それで問題になったことはありますね。

弊社のサービスからプッシュ通知を送った時とかは、ユーザーが一斉に接続するので負荷が一時的に高まるんですが、それでCPUがパツパツになってしまったことがありまして。ただ、HTTPS化する前はCPUがボトルネックになるようなことはなかったので、やはりTLSの処理が影響していたんだろうなあと思います。

大津: ただ、その後そういう問題は起きていないのは、HTTP/2が一役買っているのかもしれません。

HTTP/2はTCPセッション数が減るので、TLSの暗号化・復号化に伴う処理負荷も減ります。単純に言えば、HTTP/1.1の時に6セッションだったものがHTTP/2で1セッションになったら、TLSのコストは1/6になるわけで。

白石: なるほど！HTTP/2がサーバの処理負荷を下げるという可能性は、今まで思い至りませんでした。

HTTP/2のさらに先へ。新しいプロトコルを知る – TLS 1.3とは？

白石: HTML5 Conferenceでは、さらに新しいプロトコルについてもご紹介があるとのことですね。

大津: はい、TLS 1.3やQUICについて紹介しようかと思います。

TLS 1.3というのは、1.2までの技術的負債を精算しつつ、ハンドシェイクを速くすることを目的とした仕様です。仕様はだいたい固まっていて、現在Googleをはじめとした企業が、実験的に使用して調査中です。

白石: 技術的負債を精算して、さらに速く…って、いいことづくめですね。

大津: ただ、TLS 1.3にはまだ大きな問題が残っています。後方互換性に関わる透過性の問題があって、通信できない場合があることが報告されているのです。

TLS 1.3に対応していない中間機器が、接続を無断で切断しちゃうことがあるんですよね。そういうファイアウォール、IDS（Intrusion Detection System:不正侵入検知システム）、IDP（Intrusion Prevention System:不正侵入予防システム）などが中間経路にあると、ネットワーク全体がダウンしてしまうこともあります。本来は、TLS 1.2にフォールバックしてほしいのですが…現在Googleなどが後方互換の問題を最小にするために透過性の調査を行っているところです。

白石: 通信を遮るものをどう扱うか、は難しい問題ですね。正直、簡単に解決する問題には全く聞こえませんね…

大津: そうなんですよ。少し前に、GoogleがTLS 1.3を試験的に有効化していたところ、ある学校で問題が発生し、数万台のChromebookが通信もアップデートも行えなくなってしまうということがありました。 こうなるとGoogleですらお手上げなんですよね。TLSに完全に依存しているので。

そう考えると、HTTP/2って「幸運」だったと思うんですよね。

白石: 「幸運」ですか。

大津: はい、TLS 1.2という「枯れた」プロトコル上の動作を前提にできたのがラッキーでした。TLS1.2って、2008年に登場したプロトコルで、今は完全に普及しきっていますから。

そういう前提のないプロトコルや機能拡張だと、大変なんです。

例えば、TCPのデータ送受信開始を速める「TCP Fast Open」という仕様もあるのですが、うまく通じない現象がAppleのエンジニアによって報告されていて、最近Linuxで緩和策が講じられたにもかかわらず、Microsoft Edgeではついにデフォルトで無効化されてしまいました。

TCP Fast Openは2014年に標準化されており、Linux、 macOS、 WindowsなどOSの対応も進んでいるのですが、それでもまだこういう状況です。それほど、低レイヤーのプロトコルを普及させていくのは難しい。

だから、私たちがHTTP/2の移行にあまり苦労しなかったことも含め、HTTP/2のアップグレードがこれほどスムーズなのは大変幸運なことなのです。

QUICという「プラットフォーム」の可能性

白石: QUICについても教えていただけますか？

大津: QUICは、ざっくり言うとUDPの上でTCP、TLS 1.3、そしてHTTP/2の一部をごちゃっとやる感じのプロトコルです。

白石: ごちゃっと(笑)。

大津: IETFでの標準化も進められていて、今度の10月で1年になりますね。非常に有望なプロトコルで、今後のネットワークのプラットフォームになっていくポテンシャルを秘めていると期待しています。

白石: なぜそこまで期待していらっしゃるのでしょう？

大津: 「UDPなので疎通性が良い」というのと「ユーザーランドで動作するプロトコルなのでデプロイが容易」ということが挙げられます。

先程TLS 1.3の普及には苦労しそうだ、という話をしましたが、QUICはUDPなので比較的通りやすいんです。また、通じなかった場合はTCPにフォールバックする機能もある。通信を行うコンピューター同士が、エンドツーエンドでQUICに対応していればいいのです。

ユーザーランドで動作する…というのは、TCP BBR (※) と比較するとわかりやすいと思います。

※参考: 「Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始 (Publickey)」

TCP BBRは、Googleが開発した新しい輻輳制御のアルゴリズムです。モバイル環境のように、パケットロスが非常に多い環境でも速度を最大化できるという利点があります。

しかし欠点としては、TCPのスタックってOSのカーネルに実装されているので、使おうとするとカーネルのアップデートが必要になるということです。できれば通信を行うコンピューターがどちらもTCP BBRに対応したカーネルにアップグレードしていることが望ましいのですが、OSのアップグレードサイクルを考えると、どれほど少なく見積もっても普及には数年かかるでしょう。

その点QUICはUDPの上で構築されている。プロトコルの処理はユーザーランドで行われるので、デプロイするのにOSのアップグレードなどを伴いません。プロトコルのバージョンアップも、機能追加も比較的簡単だと考えられます。将来的にHTTPだけでなくDNSやWebRTCなどでQUICが利用されることも検討されています。

白石: それが、「QUICはプラットフォームになりうる」という先程の言葉の意味ですね。

大津: はい。ただ、QUICも実際には良いことばかりではありません。「QUICを無効にしたらChromeが軽くなった」などのノウハウが最近巷に広まってきています（※）。さきほどUDPの透過性の良さについて話しましたがやはり完全に透過ではなく、これも中間経路での問題が出てきている現象だと見られています。

※参考: 「最近 Chrome が「重くなった・ひっかかる」と感じたら試してみてほしいこと (Tanweb.net)」

白石: やはり、ネットワークプロトコルのデプロイって難しいんですね…。ただ、QUICが持つ素晴らしい可能性についても、よくわかりました。

本日は、実際の大規模なHTTPS & HTTP/2への移行経験から新しいWebプロトコルのお話まで聞けて、大変勉強になりました！ どうもありがとうございました。

こんにちは、編集長の白石です。

この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、いろいろ伺ったものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、株式会社サイバーエージェントにお勤めの佐藤歩さんです（ネット上では「あほむ」「ahomu」のIDで有名）。 （プロフィールはこちら）

あほむさんのセッションは「最近のWebパフォーマンス改善について知っておきたいコト」（ホール 13:20-14:00）です。 （現在HTML5 Conference 2017は定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、あきらめずにキャンセル待ちすることをお勧めします！）

パフォーマンスはなぜ重要か？を違う切り口から伝える

白石: Webパフォーマンスについて、「ベーシックな話を少々と、最近の動向」をお話されるということですね。

あほむ: はい、そうですね。まあ、まだセッションの内容はほとんど固まっていないので、当日は全然違った話をすることになるかもしれないのですが。

普通パフォーマンスに関する「ベーシックな話」というと、「なぜパフォーマンス改善は重要か」ということを語られることが多いと思うんです。でも、「パフォーマンスが重要」というのは、もうエンジニアには広く認識されているんですよね。

足りないのは、パフォーマンス改善を「開発者の自己満足」で終わらせないことなんじゃないかと。パフォーマンス改善が、自社のビジネスにどう寄与するのか。そこを考えないと、意味のないパフォーマンス改善を行ってしまう恐れもあるし、社内の理解も得られない。

「パフォーマンスは重要である」というメッセージを、そういう観点からも伝えたい気がします。それも他社の事例とか一般論から語るんじゃなくて、私自身が遭遇した実体験などを踏まえて語りたいな…と思ってます。

白石: それは面白そうですね！具体的には、どんな実体験になりますか？

あほむ: 例えば、弊社のサービスってSNSでWebページが拡散されることが、非常に大きな比重を占めているんです。つまり、TwitterやFacebookのアプリ上で、WebViewでページを表示されることがすごく多いんです。そうなると、実はブラウザのキャッシュにすら期待できないことが多い。弊社のサービスはiOSのユーザーが多いのでなおさらです（※）。

とはいえ、SNSを通じてたまたま遭遇した、っていう千載一遇のチャンスは活かさなくてはならない。そういう限定された環境でも最高のUXを実現するため、最大のパフォーマンスを発揮するにはどうしたらよいかを常に試行錯誤しているんです。

白石: なるほど。確かにそれは、パフォーマンスが非常に重要なシチュエーションと言えそうです。

あほむ: こういう例を含めていろいろ紹介できるといいかもしれません。URLさえあればどこからでもアクセス可能というのはWebの利点ですが、要はどんな環境で見られるかわからないということです。だから、Webのパフォーマンス改善には終わりがないし、少しでもその助けになるよう、常に新しいアイデアや技術が考案されています。そういう技術のうち、比較的新しくて、活用しがいのあるテクニックや仕様について、いろいろご紹介できればと思っています。

※弊社のサービスはiOSのユーザーが多いのでなおさら…Androidであれば、Chrome Custom Tabという仕組みでメインブラウザ（Chrome）とキャッシュなどのリソースが共有されることも期待できる。iOSは、Chrome Custom Tabに近いSafari View Controllerという仕組みがあるが、あまり利用されていない。

ページロードパフォーマンスの改善テクニック

白石: では、パフォーマンスを改善していくテクニックや仕様をいくつかご紹介いただけますか？

あほむ: Webパフォーマンスを考える際には、やはりページロード (ページの読み込み速度)と ランタイム （ページ実行中のパフォーマンス）に分けて考えるのが王道です。ページロードの改善については、最近だとHTTP/2の話が中心になると思います。

白石: なるほど、御社のサービスでは、HTTP/2対応はもうかなり進められている感じなのですか？

あほむ: はい。できるところからHTTP/2にしていくというアプローチで、現在は多くのサービスがHTTP/2を利用して動いています。

白石: 実際にHTTP/2に対応してみていかがですか？苦労した点とかはありましたか？

あほむ: 具体的な切り替え作業については、インフラの専門チームが実施してくれるので、あくまで開発側からの意見になりますが…ほとんど苦労していることはないですね。

白石: おお、本当ですか。それは素晴らしい。

あほむ: はい、HTTP/2に切り替えても、開発への影響はほとんどなかったという点はとても重要ですね。アプリケーションとネットワークで、レイヤーが違うから当然といえば当然なのですが、やはり実際に経験してみると、そのありがたさが実感できます。トレードオフがほとんどないにも関わらず、パフォーマンスの向上が見込めるのですから。

白石: でも、HTTP/2に切り替えたことで、本当にパフォーマンスアップするのか、懐疑的な意見も目にしたことがあります。実際のところどうなんでしょうか？

あほむ: うーん…実際のところ、それはありますね。HTTP/2にしただけだと、体感的に良くなったっていう実感があまりないのは、正直なところです(笑)。

白石: それも正直な意見として、貴重だと思います(笑)。

あほむ: 例えばHTTP/2でヘッダ圧縮されてデータ転送量が多少減ったとしても、アプリケーションで扱うデータが最適化されてなかったら、誤差みたいなレベルになってしまいますからね。HTTP/2によるパフォーマンス向上は、確実に効いているとは思います。ですが、実際のサービスでは、常に別のところにパフォーマンスのボトルネックが潜んでいて、効果のほどが見えにくいんですよね。

白石: 他には、ページロードの最適化で知っておいたほうがいいテクニックとかありますか？

あほむ: ほかには、コンテンツの圧縮にZopfliやBrotliを利用していますね。他にはResource Hintsなども使っているので、お話したいですね。

※参考記事：FRESH! Web パフォーマンス改善 〜サーバサイド編〜

白石: Zopfli…？そんな圧縮形式があるんですか？

あほむ: はい、ZopfliもBrotliも、どちらもGoogleが開発した圧縮形式です。

Zopfliは、圧縮の速度は遅いですが、そのかわりに圧縮効率は非常に良い。そしてgzipとの互換性があるので、gzipに対応したブラウザであればだいたい扱えるという大きな利点があります。

Brotliは、gzipとの互換性はありませんが、非常に効率のよい圧縮アルゴリズムです。こちらは現在のところ、Chrome, Firefox, Edgeでのみ利用可能です。

白石: Resource Hintsというのはどういうものですか？

あほむ: 利用するリソースを先読みするヒントをブラウザに与えるための仕様です。これを利用すると、現在のWebページに含まれていないリソースであっても、ブラウザに先読みさせることができます。dns-prefetch (名前解決を実行しておく）, preconnect （サーバ接続を行っておく）, prefetch （リソースのフェッチを実行しておく）, prerender （ページのレンダリングをバックグラウンドで実行しておく）といったタイプの先読みが可能です。 （筆者注: Jxckさんのブログで詳しく解説されています）。

ランタイムパフォーマンスの改善テクニック

白石: ランタイム （アプリケーション実行時）のパフォーマンスを向上させるために使用している技術にはどんなものがありますか？

あほむ: Intersection ObserverやPassive Event Listenersは利用しがいがあると思います。

Intersection Observerというのは、要素同士の領域が交差したり、もしくはビューポート（ユーザーに見えている範囲）に要素が入ったかどうかなどを検出できるAPIです（筆者注: Intersectionとは「交差」の意味）。これを利用すると、ビューポート外で行われる処理を抑制したり、遅延させたりすることが可能になるので、パフォーマンス向上には非常に効果的です。わかりやすいのは、img要素がビューポート内に現れるまで画像の読み込みを遅延させる…などですね。

Passive Event Listenersというのは、UIイベントが preventDefault() （デフォルトの動作をキャンセルする）されないことを保証するための仕組みです。

スクロールイベントなどは、 preventDefault() を行うことでブラウザのスクロール処理そのものをキャンセルすることができます。逆に言うと、ブラウザはスクロールがキャンセルされる可能性を考えると、イベントハンドラを実行してから実際のスクロールを行わなくてはならない。だから、イベントハンドラの実行に時間がかかったりすると、スクロール処理が詰まってしまうんです。これがスクロールジャンクと呼ばれる現象です。

ただ、実際に preventDefault() でスクロール処理を止めたいというケースは多くはありません。なので、「このイベントハンドラはpreventDefault()を呼ばないよ」ということをブラウザに伝える手段として用意されたのがPassive Event Listenersです。

（筆者注: これらも、Jxckさんのブログに詳しい解説がある。Intersection Observer Passive Event Listeners）

白石: 今おっしゃったIntersection ObserverやPassive Event Listenersは、全てのブラウザで動くわけではありませんよね？

あほむ: はい。なので、動作しないブラウザ用にFeature Detectionで分岐を設けたり、Polyfillも活用しています。

白石: なるほど。ただ、最初にお聞きした例だと「SNSで拡散されたページの最適化に注力している」というお話でした。こういうランタイム系のパフォーマンス改善って、SPA (Single Page Application) ではない通常のランディングページやメディアのサイトなどでも重要なのでしょうか？

あほむ: そう思います。先程も申し上げたように、SNSを通じてサイトにアクセスしてくれるのって、ユーザーと接触できる千載一遇のチャンスなわけです。そこからモバイルアプリへの誘導を行うこともできる。なので、そういう千載一遇のチャンスで少しでも機会損失を起こさないように、入念にパフォーマンスをチューニングするのは非常に重要です。

個人的には、jQueryを使った普通のWebサイトこそ、ランタイムのパフォーマンスにもっと気を使うべきだし、できるとも思います。jQueryのプラグインが最新の仕様に追従すれば、プラグインをアップデートするだけで恩恵を得られるわけですから。

ただ逆に、プラグイン側が対応してくれなかったりすると、プラグインの中に手を入れるわけにもいかず、対応が進まないということの裏返しでもありますけどね…悩ましい問題です。

パフォーマンス改善を「開発者の自己満足」で終わらせないために

白石: これまでご紹介いただいた様々なテクニックですが、これらを活用してパフォーマンスを実際に改善していくのは、実際には骨の折れる作業だと思います。そうした、パフォーマンス改善作業に投下するコストと、それによって得られるリターンについては、どのようにお考えでしょうか？

あほむ: はい、おっしゃるとおり、これらのテクニックをただ使って、目に見えない部分でパフォーマンスを改善しても、単なる開発者の自己満足に終わってしまいます。それを避けるためには、まずは正しく計測することと、それがビジネス上のKPIとどう関連付けているかを検証していくことが必要です。

まず計測についてですが、クライアントサイドのパフォーマンスを計測する指標は、現在も様々なものが考案され、利用可能です。

例えばFirst Paint。Webページの描画が開始されたタイミングを表す指標で、ChromeやEdgeでは非標準のAPIから値を得ることができます。

ただ、First Paintだけでは、コンテンツの表示が完了するまでの速度などについてはわかりません。最も重要なのは、ユーザーに見える範囲、つまりビューポートの描画がいつ完了するかです。

そういう観点での指標としてはSpeed Indexがあります。Speed Indexを計測する基本的な方法としては、描画中の画面をキャプチャして、最終的な表示結果が得られるまでにどれくらいかかるかを測るというものです。弊社のサービスでは、ページビューや直帰率といったKPIとSpeed Indexの間に相関関係が認められたため、Speed Indexを中心にパフォーマンス改善を行いました。

さらにこうした指標は実際のユーザーの環境で得られた値を一定量集めることも大事なので、集計結果をGoogle Analyticsに送信しています。そうすることで、GAを使いなれたプロに分析をお任せすることもできますからね。

そうした経緯は弊社技術ブログの記事に詳しく書かれています。

白石: なるほど…パフォーマンス改善がビジネスに寄与するという道筋を立てることで、パフォーマンス改善が業務として意味にあるものになるわけですね。

あほむ: そうですね。パフォーマンス改善とビジネスが両輪としてうまく回るためにも、やはり様々なパフォーマンス指標や計測が大事になってきます。

指標は他にもFirst Contentful Paint （コンテンツが表示され始めた時）や First Meaningful Paint （ユーザーに意味のある表示になったとき）など様々なものが考案され、実装も行われています。よければそういう話をまとめた私のブログ記事も見てみてください。

白石: なるほど、今日は貴重なお話をお聞かせいただきありがとうございました！HTML5 Conferenceでのセッションも楽しみにしています。

セッションは大変良くまとまっていますので、YouTubeにあがっている動画を見れる人はそちらを見てもらえればいいのですが、時間がないという人のために、その内容をまとめました。基本的には文字起こしに近いものです。

重要だとわかっているけど、なかなか導入に踏み切れない人も多いHTTPS。これについて、最新の状況が理解できるコンテンツとしてお役に立てるならば嬉しいです。

※この記事は、Qiitaに投稿された記事を、Qiitaの許可を得て転載したものです。

TL;DR

• HTTPSはPWAppなどWebにとって必須。
• しかし、パフォーマンス悪化するかも！？ でもお高いんでしょ？ それに見合うだけのメリットあるの？などなどの疑問（＝都市伝説的なものも含む）があるので、それを1つ1つ検証。
• 結論: 確かに懸念すべきものもあるが、やはり必須。正しく、早急に導入しよう。

Mythbusting HTTPS: Squashing security’s urban legends

“Mythbusting HTTPS: Squashing security’s urban legends” はGoogle I/O 2016の初日の夕方に行われたセッションです。ChromeのセキュリティチームでSSL/TSLを担当するエンジニアであるエミリー（Emily Stark）自らが登壇しました。

Mythbustingとは

Mythとは英語で「神話」を意味します。Bustにはいくつか意味がありますが、ここではゴーストバスターズなどと同じように、「退治する」、「撃退する」の意味になります。実は、オーストラリアで制作され、米国でも放映されているMythbustersという人気テレビ番組があります。都市伝説のような伝説を検証する科学エンターテイメント番組なのですが、タイトルのMythbustingはもしかしたらそこからとったのかもしれません。

Mythbustersは日本でもケーブルテレビなどで放映されておりますが、そのタイトルは「怪しい伝説」となっています。この投稿のタイトルもそれに習いました。

セッション動画

セッション動画はここから。英語が苦手な方も、Google Developers Japan: 技術と英語を同時に、しかも無料で勉強できる画期的な方法 にあるように字幕付きならば、技術的な内容ですので、十分内容を掴めるはずです。

HTTPSのおさらい

セッションでは、スピーカーであるエミリーが2010年の世界から見ると、2016年の今日のWebは大きく進化したというところから話し始めます。ホーム画面への追加（Add to Home screen）やプッシュ通知、デバイスオリエンテーション、ジオロケーションなどプログレッシブWebアプリケーションをはじめとするWebをよりアプリに近づける技術が使われるようになっています。

一方で、そのようなアプリケーション的なWebが普及する中、未だに課金や商取引、個人情報をやりとりするようなデータを扱っていながら、第三者から盗み見されるようなネットワークで運用されているところもあったり、ISPやWiFiプロバイダーのような第三者がWebサイト運営者の意図しないようにコンテンツを書きかえることさえ起きています。

エミリーはだからこそHTTPSが重要だと強調します。

現在のブラウザはHTTPSでアクセスしているサイトには、それがHTTPSであることをインディケーターで示します。ですが、すべてのWebサイトがHTTPSをサポートし、この緑のインディケーターを必要としない世界こそ、望むべきものです。

HTTPSには3つの役割があります。

• 認証（Identity）: https://google.com/ にアクセスすると、ブラウザはgoogle.comから証明書を受信し、それにより今アクセスしているgoogle.comが真正のgoogle.comであることを確認します。
• 守秘性（Confidentiality）: 一度、真正のgoogle.comにアクセスしていることが確認されると、その後の通信はgoogle.comとブラウザ以外には盗聴されない形で行われます。
• 完全性（Integrity）: google.comとブラウザの間でのデータは第三者により改ざんされないことが保証されます。

このようなセキュリティ上の利点があるものの、HTTPSを導入しようとしたときに、コスト、パフォーマンス、そして保守の面で課題があるのではないかと心配されるかもしれません。しかし、それは過去のものです。そのようにエミリーは言います。

HTTPSにまつわる話

これらの誤解は結局のところ、5つほどの話に整理できます。それらのうちのいくつかは過去には正しかったものの、現在では都市伝説になっているものもあります。エミリーは5つの話を現在でも事実の話と怪しい伝説とに分類していきます。

その5つの話は次の通りです。

1. 私のサイトはHTTPSを必要とするほど重要ではない
2. HTTPSを導入すると遅くなる
3. HTTPSに関しての攻撃がたくさんあるみたい
4. HTTPSにはお金がたくさんかかる
5. 私のサイトはHTTPSに移行できるけど、使っている（依存している）サードパーティ（のサービス）はどうしたらいいの？

それでは、エミリーが1つ1つをどのように解説していったかをお伝えしましょう。

「私のサイトはHTTPSを必要とするほど重要ではない」

エミリーはアリスの話を始めます。

アリスというWebデベロッパーがいます。彼女の旅行ガイドのWebサイトはログインフォームもなければ、クレジットカード番号の入力フォームもない。そこでアリスは自分のサイトにはHTTPSは必要ないと考えます。ですが、ある日、彼女の友人からアリスの旅行ガイドサイトが遅いと言われて、調べてみると、友人が見ている彼女のサイトには彼女が入れたのではない様々な広告が挿入されていたことに気づくのです。それらにはマルウェアが埋め込まれていて、アリスのサイトを信じた友人はサイト内の広告もクリックし、マルウェアに感染してしまっていたのです。

アリスはまた新しい機能をジオロケーションAPIを用いて実装しようとします。ユーザーがどこにいるかを把握し、適切なトラベル情報を提供しようと試みたのです。しかし、彼女はChromeでは動作しないことに気づきます。

現在、Chromeを始めとする多くのモダンブラウザはジオロケーションAPIをはじめとするパワフルな新しいAPIの利用はセキュアはHTTPS上でしか動作しないようにし始めています。

このように、HTTPSはプライバシーやセキュリティ上の重要なデータのやりとりが発生するようなサイトだけでなく、ユーザー体験を向上させるすべてのサイトに必要なものとなっています。

つまり、この話は嘘です。

「HTTPSを導入すると遅くなる」

次はボブの話。ボブはEコマースサイトを持っています。彼はサイトを分析し、コンバージョン最適化のためにはレイテンシーを下げることが必要と判断しましたが、HTTPSとパフォーマンスについてあまりよくない話を聞きました。

HTTPSに移行したyell.comはパフォーマンスの差（HTTPとHTTPS）は相対的に大きかったと言っています。しかしながら、2010年にGmailをHTTPSに移行したGoogleは無視できるほどの差しかなかったとしています。

ボブはこれらの話を知り、さらに自分自身でも調査をしました。

エミリーはボブや一般のWebデベロッパーのためにHTTPSにするとネットワーク層で何が起きるのかを説明し、どのように遅延を避けるかを解説します。

一般のユーザーはブックマークするなどした以前のHTTPのURLでサイトにアクセスしてきますので、まずはHTTPからHTTPSへのリダイレクトが起きます。そしてその次にTLSハンドシェイクで証明書のやりとりと双方がTLSを使えることの確認が行われます。

HSTS

まず最初のHTTPからHTTPSへのリダイレクトに関しては、HTTP Strict Transport Security（HSTS）の導入を勧めます。HTTPヘッダーにHSTSの記述をすることで、次回からのアクセス時にブラウザはHTTPでのURLを自動的に内部でHTTPSに置き換えます。これにより2度目以降はこのリダイレクトは発生しなくなります。

注意事項としては、これは一度セットされると、HTTPヘッダーが失効するまで有効ですので、HTTPSのテスト時や完全にHTTPSでのアクセスをサポートできるまでは行ってはいけません。

TLS False Start

次のTLSハンドシェイクにおける最適化は2ウェイラウンドトリップをいかに高速化するかに関わるのですが、ここではTLS False Startの利用を勧めます。

TLS False Startは2ウェイラウンドトリップを待つことなく、クライアントであるブラウザがHTTPSでの通信をリクエストするものです。

TLS Session Resumption

もう１つの最適化はTLS Session Resumptionと呼ばれるもので、一度TLS通信を行った場合、以前に使ったセッションIDを用いることで、同じTLSハンドシェイクは必要ないと省略するものです。

HTTP/2

ここでエミリーはHTTP/2のいくつかの特徴を話します。

HTTP/2はリクエストとレスポンスを並列で行うパイプライン化により、１つのリクエストのレスポンスを待たずに次のリクエストを送れます。また、サーバープッシュにより、ブラウザがHTMLをパースし、追加のリソースであるスタイルシート（CSS）やJavaScript、イメージなどをリクエストするのを待たずに、サーバー側から必要となるリソースをプッシュすることが可能です。

HTTP/2には他にもさまざまな利点があります。

ここで大事なのは、このHTTP/2はHTTPSでのみ利用可能なことです。

エミリーはHTTP/2がHTTPSでのみ利用可能になっているのには、2つの理由があると言います。1つがHTTPSを普及させるためのインセンティブとして、つまりHTTP/2を使いたいならば、HTTPSを使わなければいけないとすることにより普及を目論んでいるということです。もう１つがプロキシサーバーなどの中継機器によりHTTP/2の通信が阻害されることを避けるためです。

ここで、さきのボブの話に戻ります。ボブが知ったyell.comのHTTPS移行の話ですが、実は彼らが遭遇したパフォーマンス上の課題は古いロードバランサーによるものであったそうです。彼らは将来的にはHTTP/2にアップグレードすることで、TLSネゴシエーションを改良し、RTTを減らすことで、HTTPSへの移行をネガティブなインパクトではなく、ポジティブなインパクトに変えたいと言っています。

実際に、別の事例としてweather.comがあります。彼らはHTTPSに移行した際にネガティブなインパクトがあったのですが、最終的にHTTP/2にアップグレードすることで、それらはほとんど解消できたそうです。

ボブはこれらの調査結果を踏まえて、解説されたような設定を行うとともに、HTTP/2にアップグレードすることで、パフォーマンスの心配なく、HTTPSに移行することができました。

結論として、この話、「HTTPSを導入すると遅くなる」は（ほとんど）嘘とエミリーは言います。「ほとんど」となっているのは、HTTP/2へのアップグレードなどを含めて総合的にはという意味でしょう。

参考情報

HTTPSに移行したyell.comの話はHTTPS is Hard – The Yell Blogに詳しく書かれています。これは大変読み応えのある記事なので、英語ですがお勧めです。

また、HSTSについては以前書いたHSTS (HTTP Strict Transport Security) の導入 – Qiitaに簡潔にまとめてあります。

HSTSを含むTLSの設定などは、IPA（情報処理推進機構）のSSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～がお勧めです。

「HTTPSに関しての攻撃がたくさんあるみたい」

今度はイブの話。技術的な知識もあるイブはちょっとお金に困っていました。そこでHTTPSの脆弱性の話に目をつけ、あるHTTPSの脆弱性を持ったまま放置されているサイトを探します。クレジットカードやログイン情報を持っているサイトなどで脆弱性が放置されているサイトにアクセスします。

これは実際に起こりうる話です。

HTTPSのセキュリティの研究は最近とても注目されており、単なる攻撃の可能性を理論で示すだけではなく、より実践的な形で攻撃を示したり、インターネット上で実際に脆弱なサイトを見つけるツールやスクリプトを公開したりすることも多くなっています。

実際に図に示したように、多くの脆弱性と攻撃が見つかっています。

エミリーはこう考えたらどうかと言います。

「HTTPSはライフジャケットのようなもの。いろいろと問題はあるけれど、HTTPはライフジャケット無しのようなもの」

HTTPSを使わないのではなく、ツールなどを用いて、サイトで用いる技術を常に最新の状態に保つのが良いでしょう。例えば、SSL Labsはスキャニングツールを提供していて、サイトのURLを入力することで、サイトのレイティングや必要となる設定などを示してくれます。

類似のツールとして、MozillaはSSL Configuration Generatorを提供しています。利用するサーバーやバージョンなどを入力することで、設定が生成されます。

さて、この話の結論は事実（ただし、心配しすぎることは無い）です。「心配しすぎることはない」のは、ライフジャケットなしのHTTPよりも、多少の問題があってもライフジャケットとなるHTTPSは使ったほうが良いし、問題もツールなどを用いて常に最新ソフトウェアを使い、構成を正しくすることで解決できるからです。

「HTTPSにはお金がたくさんかかる」

次の主人公はチャーリー。

チャーリーは２年前にスタートアップ向きの素晴らしいアイデアを思いつきました。彼はサイトを作り、そこで人々がチャットを行えるようにし、無事ベンチャーキャピタルからも資金を調達できました。それから2年経ち、資金調達で得た資金も枯渇しつつありこともあって、彼はコストには厳しくなってきています。HTTPSにはお金がかかるという話が気になっています。

お金はHTTPSのいろいろなところに関係しています。

パフォーマンスもお金に関係しますし、最後に紹介する広告もお金の話です。ここでは、特にHTTPSの財務上の課題について話します。HTTPSを支える暗号技術における認証は証明書が必要です。これは従来は認証局から有償で購入する必要がありました。身分証明や法人登記書類などを提示して、認証局より証明書を購入し、それをブラウザに対しての自らの認証として使います。

さて、この証明書はいくらかかるのでしょう？ 確かに以前はお金がかかりましたが、今ではいくつかの安価な解決策があります。例えば、プロジェクトSSLMate（https://sslmate.com/ ）というものが数年前から始まっていますが、ここでは1つのドメイン年額$15.95です。複数証明書や追加オプションなどを使うとしても、財務にさほど大きな負担を与えません。新しいプロジェクトのLet’s Encrypt（https://letsencrypt.org/ ）は無料で証明書を発行します。

このSSLMateとLet’s Encryptは無料もしくは安価での証明書の取得を実現するだけでなく、自動化のためのコマンドラインツールも提供しているので、期限切れを防ぐことなどの管理作業を行うことができます。

このように、証明書はあまりお金がかからないものとなりました。

もう1つのお金にまつわる心配は、検索ランクへの影響です。HTTPとHTTPSという2つのバージョンのサイトがあったならば、検索エンジンが混乱してしまい、検索ランクが下がってしまうのではないでしょうか？

Googleはサイトの移動に関していくつかのガイドラインを示しています。1つはサイトを移動した場合、301リダイレクトを返すようにと勧めています。また、検索エンジンのクローラーがアクセスしてきた時のために、canonicalリンク要素を提供する必要があります。

他のガイドラインとしては、次のようなものがあります。

https://support.google.com/webmasters/answer/6033049 https://support.google.com/webmasters/answer/6073543 https://plus.google.com/+JohnMueller/posts/PY1xCWbeDVC

これらのガイドラインに従うことで、検索ランクへの影響は最小限に抑えることができ、その影響もしばらくしたら回復します。逆に、GoogleはHTTPSのサイトにランキングブーストを行っています。現在は小さいブーストだが、将来的には変更もあり得ることをエミリーは示唆しています。

証明書のコストも無料か低価格で抑えられ、検索結果への影響も無視できるレベルなので、この話の結論は嘘となります。

「私のサイトはHTTPSに移行できるけど、使っている（依存している）サードパーティ（のサービス）はどうしたらいいの？」

最後の話の登場人物はフランシスコ。彼によるサードパーティコンテンツにまつわる話です。 皆さんのサイトも多くのサードパーティに依存していることでしょう。

フランシスコは大きなニュースサイトを運営しています。このニュースサイトには多くのレガシーなコンテンツも掲載されています。フランシスコはサイトをHTTPS化すると、すべてのサードパーティコンテンツも同様にHTTPS対応していなければならないと聞いていたので、サイトのHTTPS化はかなり大変ではないかと心配しています。

これは事実で、サードパーティコンテンツもHTTPSに対応していなければなりません。

まず一番最初に心配したのが、サイトの収入源でもある広告です。広告がHTTPSに対応していれば、サイトの移行もすぐに行なえます。GoogleのAdSenseは現在では常にHTTPS上で提供されるようになっています。そのため、フランシスコが自分のサイトをHTTPSに移行する前であっても、実はAdSenseはHTTPSですでに提供されています。つまり、AdSenseについては心配の必要はありません。ただし、HTTPS通信がブロックされているいくつかの国は例外です。

これはGoogleだけの動きではありません。業界全体のトレンドです。2015年、IAB（Interactive Advertising Bureau）はブログ記事の中で約80%の広告ネットワークがすでにHTTPSに対応していると明かしています。

Adopting Encryption: The Need for HTTPS

このように最近では広告がHTTPSに対応していないから、サイトのHTTPS化ができないというのはほとんどなくなっています。もし、広告ネットワークがHTTPSに対応していないようだったら、是非確認してみてください。近い将来に対応予定であることがほとんどでしょうし、もしそうでなかったならば何故対応しないか、是非対応してほしいと言ってみましょう。

次に心配なサードパーティコンテンツはHTTPリファラーヘッダーに依存しているものです。アクセス解析のためなどのいくつかの理由によりパートナーサイトであるサードパーティはHTTPリファラーヘッダーを見て、トラフィックがフランシスコのサイトから来たものであることを確認します。問題は、HTTPSでホストされているサイト上のHTTPでホストされているサイトへのリンクをユーザーがクリックした場合、ブラウザはプライバシーの理由からリファラーヘッダーを取り去ってしまうのです。フランシスコにとって、これは困ります。

ここで解決のために必要となるのが、Referrer Policyです。a要素などに付けられるこのReffer Policyとして、”origin-when-cross-origin”を指定することで、リファラーヘッダーがHTTPサイトに対して送られることになります。他にも複数のポリシーがあるので、適切なものを選び、必要な状態でリファラーを送ることができます。

<a href="http://external-partner.com/..." referrerpolicy="origin-when-cross-origin">Click here!</a>

最後のフランシスコの心配は少し一般的なものです。Mixed Contentsと言われる、HTTPSサイトでホストされているページの中にHTTPサイトでホストされるセキュアではないコンテンツが含まれるケースです。このようなコンテンツがロードされることで、HTTPSにより高められるセキュリティが妥協したものになってしまうため、厳しい措置がとられています。スクリプトやiFrameのようなものはブラウザによりブロックされます。

また、フランシスコのサイトでは多くの古い記事にロードされている写真などがあったのですが、これらはHTTPでホストされています。このようなイメージに対してはブラウザはブロックはしませんので、イメージも見ることはできますが、ブラウザのアドレスバーのHTTPSアクセスを示す緑色は消えてしまいます。

CSP（Content Security Policy）を用いてこの問題は対処することができます。HTTPレスポンスヘッダーに次のように指定します。

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/reportEndpoint

default-src https:という指定から、ブラウザはすべてのコンテンツはHTTPSでロードしようとします。ただし、'unsafe-inline' 'unsafe-eval'という指定から、動的に生成されたものやインラインスクリプトは例外とします。ブラウザがコンテンツをロード中に、もしこのポリシーに従わなかったものを見つけたら、https://example.com/reportEndpointにレポートするように指示されています。

このポリシーの例は、”Report-Only”なので、ユーザーから見た時の挙動は変わりません。セキュアでないコンテンツのロードがブロックされることもありません。ただ、もしそのようなコンテンツがロードされたことがあったならば、フランシスコはレポートを通じて知ることができます。

このレポーティングのためのインフラを用意するのも面倒であった場合、report-uri.ioというサービスを使うことも可能です。エンドポイントを用意してくれるだけでなく、解析やビジュアリゼーションまでも行ってくれます。

ここで説明したことは、Chrome DevToolsのセキュリティパネルで見ることができるようになっています。

この話の結論は真実です。ですが、ここ数年で状況は改善されつつあり、業界全体として対応に取り組んでいるものです。

まとめ

確かに、10年や15年前はHTTPSは遅く、導入にはコストがかかり、セットアップは手間のかかるものでしたが、現在では多くの障壁は取り払われています。

このセッションでエミリーが解説したように、HTTPS関連のツールやサービスなどが充実し、導入は昔の比ではないほど敷居が下がっています。インターネットのセキュリティの強化は誰かひとりや一社の取り組みで一日にして成るものではありません。HTTPSの導入を進めることで、安全に快適なインターネット空間が広がるよう、皆で努力していきましょう。

補足

各お話に出てくる人物の名前にはそれぞれ由来があります。

• アリスとボブは暗号技術を勉強したことがある人ならばご存知だと思いますが、暗号通信を二者で行うときの例として出てくるのが常にボブとアリス。それが由来。
• イブはEvil（邪悪な）から。
• チャーリーはどこから来たのか不明。
• フランシスコはサンフランシスコからか。

HTTP/2.0相互接続試験で重要な技術要素の概要

SPDYを技術ベースにして検討されているHTTP/2.0仕様は、現在60ページ弱の分量です。従来のHTTP/1.1と異なりバイナリー通信を基本とするため、その多くはフレームフォーマットの説明に割かれています。HTTP/2.0で新しく導入されたヘッダ圧縮の仕様(HPACK)は、現在HTTP/2.0の仕様と分離されていますが、将来的には統合することも検討されています。
HTTP/2.0は、既存のHTTP/1.1のセマンティクスを保持したままフレームやストリームといった単位でバイナリー通信を行うので、この点過去のSPDYの開発経験や運用実績を活かすことができます。他方、既存のSPDYでは使われていないようなHTTP/2.0で新しく議論された技術仕様については、まだ未知数な部分が多く残っています。ここでは後者に該当する項目、先に述べた相互接続試験のポイントとなった2つの技術要素について、簡単に解説します。

初期接続：HTTP/2.0の接続方法は3種類で2段階

相互接続試験における一番最初の技術的なハードルは、初期接続の確立です。将来HTTP/2.0の仕様化が完了すると、ある日突然今利用している全てのウェブサーバやブラウザーを一斉にHTTP/2.0対応に変えなければならなくなる、というわけではありません。HTTP/1.1とHTTP/2.0はインターネット上で共存できるよう設計されており、皆さんはHTTP/1.1をこれからもずっと使い続けることができるでしょう。その共存を可能にする技術が、HTTP/2.0の初期接続仕様です。ブラウザやサーバは、この初期接続を通じて相手がHTTP/2.0を使うことができるのかどうかを知り、従来のHTTP/1.1を使うのか、それとも新しいHTTP/2.0で接続するのかを正確に判断することができるのです。

初期接続の第1段階

HTTP/2.0の初期接続は、2段階のステップに分かれています。 第１段階は、次の3種類の接続方法を規定しています(図1)。

1. TLS+ALPN

ALPN(Alternate Protocol Negotiation)は、TLSのハンドシェイク時に拡張フィールドにクライアントから利用可能なプロトコルリスト送信し、そのリストを受け取ったサーバが利用プロトコルを決定する方法です。 SPDYでは、クライアント側が利用プロトコルを決定するNPN(Next Protocol Negotiation)仕様を利用していました。IETFのtlsワーキンググループの議論の過程で、TLSハンドシェイク後のプロトコル選択方法としてNPNではなく、ALPNを採用することが決定されました。ALPN仕様の採用には様々な理由がありますが、セキュリティ通信の多くは基本的にサーバ側が決定権を持つというのが理由の一つです。 クライアント・サーバ間でTLSのネゴシエーションが終り、ALPNでその後続けてHTTP/2.0通信を行うことが決まると、次に2段階目の初期接続に移ります。
今回8月の接続試験時は、opensslのALPN対応パッチの導入がまだ公表されていなかったため、iij-http2 を含めたいくつかの実装は、ALPNの代替としてNPNを利用して試験しました。

2. HTTP Upgrade

従来のHTTP/1.1リクエストを行うと同時にクライアントから Upgrade ヘッダを送信して HTTP/2.0 接続に切り替える方法です。これは、WebSocketで行われている方法と同じ切り替え方式になります。サーバが、HTTP/2.0に対応していれば、ステータスコード 101 (Switching Protocols)をクライアントに返し、第2段階目の初期接続に移ります。Upgrade時にクライアントからHTTP/1.1で送信されたHTTPリクエストは、サーバ内部で最初のHTTP/2.0のリクエストとして扱われます。サーバ側では、Upgradeの有無によってHTTP/1.1とHTTP/2.0の両方を処理可能にする必要があるため、 iij-http2ではクライアントのみこの接続方式を実装しました。

3. Direct接続

あらかじめクライアントの接続先がHTTP/2.0に対応していることを知っていれば、(1)や(2)の初期接続を行わずいきなり第2段階目の初期接続から開始することも可能です。どのようにして事前にHTTP/2.0対応であることを知ることができるのかは、HTTP/2.0仕様とは別に決めることになっています。現在のところ、DNSレコードを見て判断する方法やAlternate-Protocolヘッダを見てリダイレクションを行う方法などが候補とされていますが、具体的な仕様の検討はまだ始まっていません。

初期接続の第2段階

第2段階目の初期接続は、HTTP/2.0通信を開始する最終確認です。このステップでは、24バイトのコネクションヘッダというバイト列(505249202a20485454502f322e300d0a0d0a534d0d0a0d0a) をクライアントからサーバに送信します(図2) 。

これは、 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n という文字列を表したものです(注1)。もし第１段階を経由して間違ってHTTP/1.1のサーバにアクセスしてしまっても、HTTP/1.1のサーバは PRIというメソッドとHTTP/2.0というサポートされていないバージョンを持ったHTTPリクエストを受け取ったと解釈し、400 (Bad Request) のエラーを返して直ちにコネクションを切断するでしょう。一方、 HTTP/2.0のサーバは、このバイト列を受け取れば確かにHTTP/2.0のクライアントからの接続であることの確証が取れますので、安心してHTTP/2.0の処理を継続することができます。

このバイト列を受け取ったことを確認したら、クライアント・サーバ双方で設定情報を通知するSETTINGSフレームを送信し、HTTP/2.0の初期情報を交換します。これをSETTINGSフレームによって、通常データのフロー制御を行う初期ウィンドウサイズや同時オープンできるストリーム数の最大数などの設定情報が定まります。

以上、第2段階までのHTTP/2.0初期接続のステップを完了して初めて通常のHTTPリクエスト・レスポンスといった処理を開始することができます。今回の相互接続試験では、試験対象の実装がサポートしている初期接続に対してちゃんと仕様が想定している通りに動作し、お互いに第二段階まで問題なく完了できるのかといったところが一つの技術的なマイルストーンでした。

実装者からのフィードバック議論において、既に大規模にSPDY向けにTLS+NPNを実サービスに展開しているGoogleなどから、HTTP/2.0でTLS+ALPNが採用されたため、今後どう両者を共存させながら大規模試験をしていくのか、そして最終的にどのようにしてSPDYからHTTP/2.0に移行していくか、という運用上の問題が懸念として示されました。これに伴いHTTP/2.0に関する dev ops の議論を行う場を新たに作る提案がなされています。

ヘッダ圧縮(HPACK)：脆弱性を克服、これまでのWebにはない新しい試み

現状HTTP/1.1で利用されているヘッダ情報は、毎回同じデータを送るように冗長になっている場合が多く、その容量も次第に増加しています。特にネットワーク帯域が制限されているモバイル環境では、冗長なHTTPヘッダ情報のやり取りは帯域を圧迫し、その影響は無視できないものになっています。この状況を解決するためSPDYでは、deflateという汎用的な圧縮アルゴリズムを利用してヘッダ情報の通信容量を圧縮しました。

しかし2012年9月に、deflateを用いた場合にヘッダ情報が暗号化された通信上でも漏えいできることをセキュリティ研究者により明らかにされました。彼らはCRIMEというツールを利用することにより、特定の環境下で短時間にクッキーなどの重要なヘッダ情報を取得することを示しました。現在SPDYを利用しているブラウザーでは、この脆弱性に対応するために暫定的にヘッダ圧縮をしない対策がとられています。しかしモバイル環境などでヘッダ情報の送受信を削減することは急務の課題です。
皮肉なことにこの脆弱性は、データ圧縮アルゴリズムによって送信データが最適化されてしまったことを手掛かりにヘッダ情報を取得する手法を使っています。このため一般的な情報圧縮手法では脆弱性を回避できない可能性もあり、HTTP/2.0ではHTTPのリクエスト・レスポンスに特化した目的でヘッダ情報のデータ量を削減する新たな仕様を導入する必要に迫られました。

当初新たなヘッダ圧縮手法として、 Delta2 と Header-Diff という2つの仕様が候補として検討が進められていました。調整の結果、第2回の中間会議の直前にこの2つを合わせた Header-Compression 仕様(現HPACK仕様)が両仕様の共著として提出されました。最終的にこれを実装仕様として採用することが決定し、相互接続試験では一部を改良した仕様(Header-Compression-01)を使ってテストが行われました。
HTTPリクエストとレスポンスは、HTTPヘッダのやり取りをせずに実現できるものではありません。相互試験の参加者は、Header-Compressionのリリース後初めてこのヘッダ圧縮仕様を実装します。今回の相互接続試験のもう一つの技術トピックは、この新しいヘッダ圧縮の仕様を使って本当にHTTPリクエスト・レスポンスのやり取りが実現可能か実証する所にありました。

HPACKの仕様は、これまでHTTPで用いられてきた通信手順と全く異なり、新しいコンセプトに基づくものです。その手順は細かく規定されていますが、全てを説明するとわかりにくくなるため、若干正確性を犠牲にしますが一部簡略化してその仕組みの概要を解説します。

この仕様の基本は、サーバ・クライアントがヘッダ情報を記載したヘッダテーブルとreference set という２つのデータ集合を状態として保持することにあります。このヘッダテーブルとreference setは、HTTPリクエスト・レスポンスそれぞれに用意されるものです。ヘッダテーブルは、初期状態としてあらかじめ数十種類のヘッダ情報が番号付きで登録されています。 reference set は、1つ前のHTTPリクエスト・レスポンスの送受信によって有効になったヘッダ情報を保持しています(図3）。reference set の初期状態は空です。 クライアントとサーバは、HTTPリクエスト・レスポンスが行われる度に reference set やヘッダテーブルに対してどういうヘッダ情報を追加・削除・変更するのかといった差分操作をやり取りします。この差分操作を表すやり方は、その種類や操作によって4種類のエンコーディング方式が定義されています(注2)。受信側は、エンコードされた差分操作のデータを解析し、記載された操作に従ってヘッダテーブルやreference set を更新します。その結果、サーバとクライアントは同じヘッダテーブルと reference set を持ち、ブラウザやWebアプリケーションはこの新しい reference set を有効になヘッダ情報として利用することになります。

具体的な例を見たほうがよりわかりやすいでしょう。一例としてまずクライアントが一番最初に :scheme http :host serverA :path / xmyhoge hoge のヘッダ(空白を除いて39バイト）情報をサーバにHTTPリクエストとして送信する場合を考えます。この場合、次の5つのステップでヘッダ情報の差分操作として表します。

1. 0番のヘッダテーブルをそのまま使う
2. 2番のヘッダテーブルを serverAに書き換える
3. 3番のヘッダテーブルをそのまま使う
4. 4番のヘッダテーブルをそのまま使う
5. xmyhogeは新しくヘッダテーブルに採番して値にhogeを入れ込む

この差分操作を規定されたエンコード書式で表すと、 0x80 0x03 0x02 0x07 serverA 0x83 0x84 0x40 0x07 xmyhoge 0x04 hoge のような形式になります。これは全27バイトのデータ容量で、HTTP/2.0のフレームに付与してクライアントからサーバへ送信されます。従来のヘッダ情報の送信(39バイト）よりもデータ容量が減っていることがわかります。このヘッダ操作データを受け取ったサーバは、エンコード情報を解析し、初期状態が空のreference setとヘッダテーブルに対して1から5の差分操作を行います。結果、クライアントと同じ有効なヘッダ情報を持つreference setを作成し、Webアプリケーションに渡します（図4）。

次にクライアントが2回目のリクエストする際には、この新しいreference setに対して、ヘッダの追加、削除、変更という差分操作情報をサーバに送信します。もしクライアントが、 :scheme http :host serverA :path /foo.html xmyhoge hoge のヘッダ情報（47バイト）を2回目に送信する場合は、今保持するreference setに対して:pathのヘッダ情報だけ更新を指示する操作情報のみサーバに送ることになります（3番のヘッダテーブルを/foo.htmlに書き換える操作）。 このエンコード方式は、 0x04 0x03 0x09 /foo.html と表すことができます。これは、わずか12バイトです。このデータをクライアントからサーバに送信し、サーバは、reference set とヘッダテーブル:pathの値を更新します。HPACKを使わなければ47バイトのヘッダ情報を送付しなければならないことが、HPACKの利用で12バイトを送付するだけに縮小できるのです(図5)。

もし3回目のリクエストが2回目と同じヘッダ情報を持つリクエストなら、更新操作は必要なくなり、送付する差分操作情報は0バイトになります。クライアントは、ペイロードを空にしてフレームヘッダだけを送信すればよいのです（図6）。 このように冗長で繰り返し同じヘッダ情報を送付する場合に、HPACKはその効果が最大限に発揮される仕様であると言えます。

この方式は、SPDYで利用されていたdeflateの圧縮アルゴリズムと全く異なるものであるため先ほどのCRIME攻撃の脆弱性は存在しないものと考えられています。当初この仕様を見て実装を始めた時には、その変わり様に非常に驚きました。しかし、実際に相互接続試験では初めての実装試験であるにもかかわらず、各実装に対して問題なくHTTPリクエスト・レスポンスのやり取りができることを確認できました。
しかし様々な課題がまだ残っています。例えばメモリの対策のためヘッダテーブルは容量を制限しなければなりません。その容量を超えた場合の更新処理はどうなるのか。また実利用のヘッダ情報を使っても長時間継続してヘッダ情報の更新を行った場合でも、クライアント・サーバ間でヘッダ情報の整合性を保てるのか、といったような課題が議論され今後更なる仕様の見直しと試験を続けていく必要がある、ということが合意されました。

このように従来とは全く異なった手法でヘッダ情報がやり取りされるということは、HTTP/2.0の大きな特徴です。今後HTTP/2.0の導入や運用を行う際には、これまでの古い知識にとらわれず新しく頭を切り替えてHTTP/2.0に取り組んでいく必要がありそうです。

まだまだある、技術的なチャレンジ

上記2つの技術トピックスは、初回の相互接続試験で特に問題になりそうなものだけを解説しました。これ以外にも、

• クライアント・サーバ間でフレームの送受信の競合状態が発生しても問題は発生しないか
• リクエストの予約という形の新しいサーバプッシュ機能はクライアントへキャッシュを正常に送り込めるのか
• フロー制御や優先度設定はいろんな環境でも有効に機能するのか

などなど、他にも解決しなければならない技術的課題がまだ数多く残っています。

とはいえ、近い将来インターネットで主流となる新しいプロトコルを世界中の優秀な技術者と一緒に作り上げていく過程は、エンジニアとして非常に貴重な機会であり、とてもワクワクする瞬間です。このレポートを読んでいただいている方に、このワクワク感が少しでも伝わればうれしいことだと思っています。

(注： 本記事は、2013年8月時点でのHTTP/2.0仕様ドラフトに基づくものです。今後仕様が変更され記述内容と異なる可能性がありますので、ご注意ください。)

(注1) これ(PRI SM)は、あのスノーデン事件が起きた時にエディターがシャレで付けた文字列です。現時点でこの文字列を正式に決めるようとすると議論がまとまらない可能性があるので仮の値になってます。このようにどうでもいいことで議論が発散することをbikeshed（自転車置き場）と呼んでワーキンググループ内で議論する時に注意しています。

(注2) この4種類のエンコーディング方式は、

Indexed Header Representation

ヘッダテーブルの数字指定だけで有効・無効をトグルさせる操作方式

Literal Header without Indexing

ヘッダを文字列指定してヘッダテーブルの更新しない操作方式

Literal Header with Incremental Indexing

ヘッダを文字列指定してヘッダテーブルの最後に追加する操作方式

Literal Header with Substitution Indexing

ヘッダを文字列指定して既存のヘッダテーブルの値を更新する操作方式

はじめに

先日公開された小松健作さんの記事「変わるWebプロトコルの常識（SPDY, HTTP2.0編）」で解説されている通り、Webを支えるプロトコルHTTPをバージョン1.1から2.0に大幅に改訂する作業が、現在急ピッチで進められています。10数年ぶりに改訂されるHTTPの仕様は、現状のインターネット環境に適応できるよう、これまで以上にWeb表示の高速化・効率化が実現できることを目的としています。

HTTP/2.0標準化作業の進め方

HTTP/2.0のプロトコル仕様の策定は、インターネット技術の標準化を推進する団体IETFのhttpbisワーキンググループで行われています。httpbisでは、SPDYを開発したGoogleをはじめ、Microsoft、Mozilla, Twitter, Akamaiなどのエンジニアが中心となり、メーリングリスト上で活発に議論を進めています。特にHTTP/2.0の仕様策定は他のワーキングループと違い、通常年3回ほど開催されるIETF総会とは別にinterimと呼ばれる中間会議を頻繁に開催して集中討議を行っているのが特徴です。 HTTP/2.0の仕様自体は、GitHub上で管理されています。ここのhttp2-specレポジトリでは、議論の合意を受けてエディタがドラフトを更新する様子をリアルタイムで見ることができます。

仕様更新の手順は通常のオープンソースプログラムと同様に、issueやPull Requestを使って行われています。仕様策定に関する議論はメーリングリスト上で行うことと決められているのですが、たまにメーリングリストに構わずGitHubのコメント上でやり取りが続いたりします。チャット感覚で議論が進むので白熱することも多いのですが、そんな時はチェアから注意を受けたりします。一方、設計を変更しない程度の修正であればPull Requestを送って、直接取り込んでもらうことも可能です。まだまだいろいろ試行錯誤の段階ですが、こういった今風なソーシャルコーディングのインフラを活用しながら標準化作業を進めていく手法は、IETFでも新しい試みではないかと思われます。

HTTP/2.0の仕様は、今どこまで進んでいるのか？

これまでのHTTP/2.0仕様策定作業の歩みを表1にまとめます。 今年になり、8月までに3回httpbisの中間会議が開催されました。HTTP/2.0の仕様ドラフトも6回改訂されています。当初HTTPの仕様改訂を開始するにあたり、SPDYを含む複数の候補案で検討が始まりました。途中大きな議論を経て、最終的にSPDYをHTTP/2.0の仕様ベースとして採用することが決定しました。ベースといっても、SPDYで実現できている機能や利点といった特徴を、HTTP/2.0の仕様に大部分引き継いでいますが、その仕組みに関しては大きく見直しが入っています。 HTTP/2.0の変更点の概要としては、

• フレームやストリームという多重化構造のSPDYプロトコルアーキテクチャをそのまま利用する。
• 無駄なヘッダフィールドやフレームタイプを統廃合し、簡略化を図る。
• SPDYの実運用で明らかとなったフロー制御・優先度制御といった課題に対応する。
• TLS利用を前提とするSPDYに対し、HTTP/2.0はTLS以外の接続も利用可能にする。
• 情報漏えいを起こす脆弱性対策として新たにHTTPヘッダ圧縮の送受信仕様を策定する。

といったことが挙げられます。 標準化作業の大きなマイルストーンとして、第2回目のhttpbis中間会議の結果を受けて最初のHTTP/2.0の実装仕様がdraft-04として7月上旬にリリースされました。それまで2つの案を候補にして検討されてきたヘッダ圧縮仕様も、両者をジョイントした新しい仕様Header-Compression-01がリリースされました。この2つのドラフト仕様がそろったところで、初めてHTTP/2.0を実装できる環境が整いました。実際に動くものを作って議論を進める段階に来たのです。

世界初、HTTP/2.0相互接続試験の実施

8月上旬、初めてのHTTP/2.0相互接続試験を実施すべく第3回中間会議が、ドイツ・ハンブルグで開催されました。

ハンブルグの風景

第3回の中間会議は二日半の日程で、下記のアジェンダで進められました。

1日目

終日 実装者からのフィードバック、issueの議論・整理

2日目

終日 相互接続試験

3日目

午前 issueの議論・整理、今後のロードマップ策定

ハンブルグでの初のHTTP/2.0相互接続試験向けに提出された実装のリストは、 http2-spec レポジトリのWikiページにまとめられています。現在ここに10の実装が登録されていますが、このうち実際に会議中に相互接続試験を行うことができたのは8つでした。実装の種類は、クライアント・サーバ・プロキシの3つの用途に大きく分類されます。今回の相互接続試験は初回ということもあり、基礎的な部分の動作確認が中心となりました。技術的には以下の2点が大きな検証ポイントです。

1. HTTP/2.0の初期接続が問題なく完了し、HTTP/2.0の処理が開始できること。
2. 新しいヘッダ圧縮仕様を使って問題なくHTTPのリクエスト・レスポンスの処理が行えること。

上記2つの技術ポイントについての詳細は、本レポートの後半(技術解説編）で解説します。

相互接続試験の結果と今後のロードマップ

私が持ち込んだ iij-http2 モジュールと他の実装との相互接続試験は、中間会議の2日目に集中的に行いました。ただ実際には、担当者同士でメールのやり取りをして、前日から既に試験を開始しています。

HTTP/2.0相互接続試験の様子

実は今回作成したiij-http2は、会議前にソースが公開されていた実装 (nghttpd や node-http等）に対してドイツ出発の2日前になってやっと初めて簡単な接続テストができたレベルなので、実際の接続試験ではどうなるかドキドキでした。当日は会議参加者間だけでなく、オフラインで参加した実装者も含めて各自がテストを進めています。相互接続試験といってもきっちりしたテストシナリオやチェック項目が用意されているわけではありません。開発者が気になる部分を中心に、用意されたサーバ・クライアントを自由にテストするといったやり方でした。

iij-http2は、テストのためにインターネット上に単純にHello Worldを返すサーバの2種類準備しました。ブラウザの替りに手元のクライアント実装を使って他のサーバやプロキシ実装に対してアクセスを行い、手元で表示されるデバッグ情報などと照らし合わせてHTTP/2.0プロトコルのやり取りを確認しました。最終的なiij-http2の接続試験結果を表2に示します。

試験を通じていくつの問題が発見されましたが、最終的にiij-http2は接続テストを行った全ての実装と接続確認が取れました。初回ということであまり複雑なアクセスパターンやエラー時の挙動などの試験を行っていませんが、先に解説した技術ポイントに対する相互接続は成功したことになります。一例としてHTTP/2.0対応Chromeとiij-http2との接続成功時のスクリーンショットを載せます。

会議の最終日は、今後のロードマップをどうするかという議論に移りました。クローズしたissueの方針や接続試験で議論された内容を最新のドラフトに反映し、第2回目の接続試験を行うための新しい実装仕様draft-06を2週間後にリリースすることが決まりました。またヘッダ圧縮仕様については一部仕様の見直しが必要なことが判明し、さらに詳細な試験が必要との声から、9月中旬に開発者が中心になってヘッダ圧縮に特化した試験を集中的に行うことも決めました。ちなみにヘッダ圧縮仕様の「圧縮」という名称は、機能的に正確な表現でないため、その名称をHPACKに変更するということが了承されました。

次の相互接続試験を行う中間会議は10月初旬シアトルで行われることを合意し、その先の2014年1月に開催する第5回中間会議までの予定を決めて会議は終了しました。HTTP/2.0の標準化作業は、2014年春の仕様化完了に向けてまだまだ続きます。後半では技術的な内容に興味を持つ人のために、HTTP/2.0相互接続試験の検証ポイントとなった技術トピックスについて解説します。

(注： 本記事は、2013年8月時点でのHTTP/2.0仕様ドラフトに基づくものです。今後仕様が変更され記述内容と異なる可能性がありますので、ご注意ください。)

HTML5の登場により、Webで使われるプロトコルは、 HTTP1.1 から大きく変わろうとしています。具体的には、SPDY, HTTP2.0, WebSocket, WebRTC といったプロトコルがそれにあたります。これらは、現状のHTTPが抱える各種問題点を解決するものです。

しかしながら、これらのプロトコルについて、

• いったい何であるのか
• 今のWebの何を解決してくれるのか

は、あまり知られていません。そこで数回に分けて、これらのプロトコルがいったい何であるのか、今のWebの何を解決してくれるのかを解説したいと思います。_[1]

今回は、SPDY, HTTP2.0について取り上げます。

そもそも HTTP とは？

まず、従来のWebプロトコル HTTP についておさえておきましょう。HTTPは Hypertext Transfer Protocol の頭文字をとったもの。その名の通り HTML (Hypertext Markup Language) 文書をサーバーからブラウザにダウンロードするために開発されました。ちなみに現在もっとも使われているバージョンは1.1です。

このHTTPの特徴は、動作が非常に単純であることにつきます。その動作パターンは以下のようになります。

1. ブラウザから、サーバーに HTML 文書を要求(request)する
2. サーバーは、ブラウザに要求された HTML文書を返す（response）

このため、HTTPは request & response型のプロトコルと呼ばれます。

Webの進化に伴い、スピードの問題が!!

Webが登場してしばらくの間は、このHTTPで全く問題がありませんでした。Webの初期は文書を表示することしかできなかったため、一つのHTML文書をダウンロードすれば良かったからです。

しかしWebの進化に伴い、特にスピード面で問題が出るようになりました。多くのリソースをダウンロードすることによる、パフォーマンス上のボトルネックが生じるようになったのです。

今皆さんが利用しているWebページは、多くのリソース（JavaScriptやスタイルシート, 画像など）から構成されています。例えば、HTML5 Experts.jpのトップページでは 80個のリソース から構成されています。これらのリソースを、HTTPを用いて 素直に 取得しようとすると、以下の様なパターンとなります。

1. ブラウザから、サーバーに HTML 文書を要求する
2. HTML 文書を取得したら、次のリソース（スタイルシート）を要求する …
3. 最後の画像リソースをダウンロードしたら、それを表示してWebページが完成する

つまり、request & responseの繰り返しが 80 回起きるわけです。もし、仮にサーバーからリソースをダウンロードするのに 1 回あたり、0.2秒かかったとすると 16 秒かかる計算になります。こんなに時間がかかっては、正直サービスになりません。

このため、現在Webで使われている HTTP1.1 では、同時に送信するリクエストの数を増やすことで、ダウンロード時間の短縮を図っています_[2]。運送業者にたとえるなら、80個の荷物を1台のトラックで1個づつピストン輸送するよりも、同時に複数台のトラックでピストン輸送したほうが早く終わる…という感じです。

この解決策により、スピードの問題は著しく改善しました。現在のWebでは様々なテクニックを駆使し、10本以上の同時リクエストを送信することで、スピードの高速化を図っています。

同時リクエストの乱用による新たな問題

しかし、このようなHTTPの同時リクエストの乱用は、新たな問題を生むことになりました。サーバーやネットワーク機器の負荷を上昇することとなってしまったのです。

先の運送業者の例で、伝え忘れていたことがありました。このトラックは、一本の車線を占有しないと走れないという困った特徴があります。これは、同時に10台でピストン輸送しようとすると、10本の車線が必要となることを意味しています。

これは、あまりにも大変で、無駄が多いことは直感的にわかると思います。トラックに積荷を載せる倉庫は、多くの車線をカバーする大きなものが必要になりますし、途中の道路についても同様です。

ここで、倉庫をサーバーとし、道路をネットワーク、車線をTCPコネクションとしたのが今のWebです。HTTPはTCPコネクションという車線の上を走るトラックに相当しますので、同時に送信するリクエスト数が増えれば増えるほど、TCPコネクション数が上昇し、サーバーやネットワークに過剰な負荷を引き起こします_[3]。

SPDY, HTTP2.0の登場

このようなTCPコネクション数の乱用による問題を解決するために登場したのが SPDY, HTTP2.0です。これらの最新Webプロトコルを用いることで、スピードを高めつつ、サーバーやネットワークの負荷を下げることが可能となりました。

そのアイディアは非常に単純・明快です。トラックでたとえれば、一台あたり一本の車線を専有してしまうのが諸悪の根源です。もし筆者が運送業者の社長であれば、運転手を説得し、全てのトラックを一本の車線で走らせることでしょう。冒頭の図面のように。SPDYやHTTP2.0についても、全く同様のアイディアです。複数のHTTPを一本のTCPコネクションで運べるようにしたのです_[4]。

最初に登場したのは、SPDYです。Googleが提唱した独自プロトコルで、ドラフト仕様が最初に公開されたのは 2009 年のことです。HTTPの多重化以外にも、HTTPヘッダーの圧縮やサーバープッシュ、フロー制御など高速化のためのさまざまな機能が盛り込まれています。

既に、Googleの各種サービスや Twitter, Facebookなどの大規模サイトで実際に利用されており、運用実績があるのも大きな魅力です。ブラウザとしてはすでにChromeやFirefoxが対応しており、Internet Explorerの次期バージョン IE11 でもサポートされることから、今後更に普及することが予想されます。

HTTP2.0の検討は、SPDYをきっかけとして 2012年に始まりました。SPDYのエッセンスを新しい HTTP のバージョンに盛り込み、HTTP1.1の様々な問題を解決した標準仕様を策定しようとする取り組みです。最初のドラフトは SPDY そのものでしたが、徐々にその形を変えてきています。今年度内には、テスト実装も予定されており、これをベースとして検討がより具体化されると予想されます。

SPDY と HTTP2.0の関係・これから

SPDYとHTTP2.0の関係ですが、SPDY/4では、HTTP2.0仕様の一部を取り込み始めています。短絡的に考えるのは早計ですが、SPDYとHTTP2.0は互いに影響を与えながら、あるべき次世代 HTTP の結論を導くことでしょう。

ただし、SPDYがカバーしようとする領域は HTTP だけではありません。Webに関わるその他のプロトコル〜DNSやWebSocketなど〜もSPDYの中に取り込んでいこうとするアイディアもあります。こういった様々な興味深いトピックも、HTML5 Experts.jpでは今後紹介していければと思っています。

[1] このシリーズは、最新Webプロトコルの入門編的な記事です。その後、より詳しいシリーズを執筆する予定です。

[2] 正確にはHTTP1.1というより、現在のブラウザのHTTP実装がそうなっているというほうが正しいのですが、話が複雑になるので割愛します。

[3] 例えばIPv4枯渇に伴い、特にモバイルキャリアのネットワークに CGN（Carrier Grade NAT）の導入が進んでいますが、このような振る舞いがCGNに大きなインパクトを与えています。

[4] 多重化のアイディアは、HTTP1.1でもpipeline仕様として存在しているのですが、相互接続性の問題から実際には殆ど使われていません。