HTTPの仕様が標準化された1996年といえば、まだ米Googleさえ存在していなかった頃です。日本でNTTドコモの「iモード」がスタートしたのは1999年ですから、インターネットに接続するためのクライアント端末はもっぱらクライアントPCのみでした。

　HTTPの仕様が変わらない一方で、インターネットに接続するユーザー側の環境は大きく変わりました。人々が使用する端末の台数は圧倒的に増え、スマートフォンやタブレットなど端末の選択肢も大幅に広がりました。今やそれらを1人で複数台利用することも普通のことです。当然ながら、それらの端末のアクセス先となるサーバの数も増え続けています。

　多くのアプリケーションがWebを通じて提供されるようになったのも大きな変化です。当然のことながら、やりとりされるアプリケーションのデータ量、つまりペイロード（IPパケットのデータ部分）とHTTPリクエストも爆発的に増えています。

　ブロードバンドが普及して以降、コンテンツ自体もますますリッチになっています。例えば、ユーザーがショッピングサイトにアクセスしたとして、昨今は検索窓に文字を入力すれば目当ての商品を先読みしてくれるし、マウスオーバーした画像が拡大するのも当たり前です。

　Webアプリケーションにおいて、ボタンを押したら購入ページに遷移するといった動作は全て、HTTPによって処理されます。コンテンツのリッチ化に伴い、このHTTPの処理内容はますます複雑になっています。そして、これまでの仕様ではアプリケーションサーバのHTTP処理による負荷ばかりが増え、表示が遅くなるなどの可能性が出てきたのです。

　トラフィックの増大に対しては、ADSLを光ファイバーに変えるといったように、ただ回線を高速化すればいいと考えられがちです。しかし、アプリケーションのレイヤーにおいては、回線の高速化は必ずしも解決策になりません。帯域を2倍3倍と増やしても、データのダウンロードがそれに比例して速くなったり、遅延が解消するわけではないのです。

　むしろ、重要なのはWebブラウザがWebページの読み込みにかける処理時間を短縮することであり、そこにいろいろな工夫をしなくてはいけないのが従来のWebエンジニアの悩みでした。例えば、Webサイトにアクセスしてきたユーザーに対して、サイト内の画像ファイルを送るとき、元データを最適化して容量が10Mバイトであるものを1Mバイトのデータサイズに圧縮するなどの手法があります。また、Webブラウザによっては、独自の機能でHTTPのセッションを複数張るという機能が備わり、少しだけデータの配信を早くするという手法を取るものもあります。しかし、これらはあくまでも現場のエンジニアの努力による独自の取り組みであり、期待できる効果には限界がありました。

アプリケーションのトラフィックはデータ自体のサイズも大きくなり続け、またクライアント機器から発信されるリクエストの数も増え続けている（出典：IETF）

SPDYからHTTP/2へ

　アイコンをクリックしたらページが遷移するといった、紙芝居のような静的なWebサイトを見せるためのプロトコルだったHTTP/1.0。1997年にHTTP/1.1にマイナーバージョンアップした際には、データ転送のたびに掛かる負荷（オーバーヘッド）をできるだけ小さくするため、一度張ったコネクションを有効利用できるようにしました。

　こうした工夫で、都度接続する必要をなくしたとはいえ、HTTP/1.1でもやはり、クライアントからサーバへ意図的にデータを取得しにいくという振る舞いは必要でした。2000年代の半ばには、クライアント側に送付したJavaScriptが、ユーザーの動作を待たず自動的に次の画面を取りにいく仕組みを備えた「Ajax」という開発手法も登場しました。Ajaxによりオンライン地図「Googleマップ」のような動的なコンテンツも作れるようになったわけです。

　ただし、これらは先述したように全て、エンジニアの努力と工夫で実現したものです。Webの高速化と運用性の向上には、やはりプロトコルの刷新が必要でした。

　HTTP1.1の課題を解決する新しい仕様策定のきっかけになったのが、Googleの提唱するHTTP拡張プロトコル「SPDY」です。

　現在はページ遷移を伴わないユーザーインタフェース（UI）が求められる一方で、サーバから情報をプッシュする仕組みに対するニーズも高まってきました。例えば、通話・メッセージアプリの「LINE」でメッセージを送ると、瞬時に相手の端末にメッセージが通知されるような使い方です。サーバとクライアントの間で張られたコネクションを維持したまま双方からプッシュを可能にするプロトコルとしては「WebSocket」があります。ただ、WebSocketは工場のオートメーションを制御するアプリケーションなど、特殊な用途にしか使われておらず、HTTPが標準語であるとすれば“方言”にすぎません。

　そこで、WebSocketよりも一般的に使えるSPDYを基準に、新しいプロトコルを策定しようという機運が2012年ごろから高まってきました。私企業であるGoogleが開発したSPDYを標準的なプロトコルとして採用するには課題もありましたが、その名の通り高速で、とある検証によると環境次第ではWebページ表示時間をHTTP1.1ベースの通信と比べて50％程度高速化できたという結果もあります。高速化において3年の実績を持つSPDYを排除する手はありません。

　Googleは、SPDYをより使い勝手のいいプロトコルにするため日々改良を続けてきました。SPDYはまず同社のWebブラウザである「Google Chrome」で利用できるようになり、米Microsoftの「Internet Explorer」をはじめ、「Safari」「Firefox」「Opera」など主要なWebブラウザでも次々と利用可能になりました。

　こうして、ユーザー側はSPDYにほぼ「Ready」な状態になりました。そして、Webブラウザがデータを取得しに行く先のサーバの方も、米Facebook、米Twitterなど大手中心にSPDY利用の準備が進んでいます。

HTTP/2で何が変わるのか

　今回、HTTP/2がRFC（IETFがインターネットに関わる技術の仕様について定めた文書）として発表され、正式な仕様となったことを受けて、GoogleはSPDY終了の計画を公式ブログで発表しました。実際、HTTP/2にはSPDYのさまざまな主要機能（複数ストリームのマルチプレックス機能やヘッダ圧縮機能、リクエストの優先度指定機能など）が継承されています。標準化されたプロトコルへの貢献をもってGoogleがSPDYを終了し、以降はHTTP/2の展開にシフトするべきと考えるのは必然であるといえます。

　サーバをHTTP/2に対応させることで大きく変わるのが、パフォーマンスとセキュリティです。オーバーヘッドが減ってデータ転送処理を最適化すれば、同じシステムでより多くの処理ができるようになります。また、HTTP処理に煩わされていたリソースをアプリケーションのパフォーマンス向上に集中させることもできるようになります。

　また、HTTP/2では1つのコネクションに複数のユーザーを入れ込むことができるようになる（複数ストリームのマルチプレックス機能）ため、回線事業者やデータセンター事業者にとっては、張られるコネクションの数が減るというメリットがあります。

　SSL通信が必須とされる見込みである点も大きな変化だといえるでしょう。これにより、まず期待されるのはセキュリティの向上です。加えて、あまり知られていませんが、Googleの検索結果表示アルゴリズムではSSL通信を優遇するという動きがあるため、SSL通信化は結果的に検索エンジン最適化（SEO）対策になる可能性もあります。

　そもそも、日々インターネットのサービスを利用していて、個人情報など重要情報をやりとりするサービスは増え続けるばかりです。SNSしかり、ショッピングサイトしかり、オンラインゲームしかり。そして、この流れは加速する可能性はあっても、なくなることはまずないでしょう。そうした意味でも、インターネット接続は今後、SSL通信が標準的になっていくと考えられます。

　HTTP/2対応は当面、セッションの効率化でメリットが見込める大手Webアプリケーションサービスプロバイダーなどを中心に導入が進むことになるでしょう。ただし、公開サイトのSSL通信化が必須となる流れの中で、いずれはあらゆる企業でHTTP/2対応を検討せざるを得なくなるものと考えられます。

HTTP/2ゲートウェイを置く

　もちろん、HTTP/2対応のため、全てのWebアプリケーションサーバを更新するというのは多くの企業にとってハードルが高いと言わざるを得ません。Webサービスを提供する企業の全てがFacebookやTwitterと同じことができるわけではありません。

　HTTP/2対応はしたいけれど今すぐ全てのサーバを更新することは難しい、あるいはインパクトを最小限に抑えながら運用したいと考えるならば、「HTTP/2ゲートウェイ」を置くというのも1つの選択肢です。HTTP/2ゲートウェイとは、簡単に言うとサーバに直接HTTP/2の通信をさせる代わりに手前の機器で通信の終端を代行させることです。

HTTP/2ゲートウェイを置くメリット《クリックで拡大》

　HTTP/2ゲートウェイのコンセプトを実現する製品登場に向けた動きもあります。F5ネットワークスが2012年6月に発表した、SPDYの処理が可能なアプリケーションデリバリコントローラー（以下、ADC）はその1つです。SPDYによるリクエストをHTTPに変換する機能をADCが提供することで、ユーザー企業はADCをSPDYのゲートウェイとして利用し、既存のWebサーバを維持しつつSPDYへ対応できるようにしたのです。今後は同様の仕組みで、HTTP/2の処理を可能にしたADCが増えると考えられます。

　そもそもADCとは、公開アプリケーションサーバの手前で複数のサーバへのトラフィック振り分けを行う負荷分散装置（ロードバランサ）が進化した製品です。

　サーバを増強する際にアクセス先が負荷分散装置で抽象化されれば、サービスを停止せずに物理サーバを追加することが可能になり、稼働中の機器のメンテナンスも容易になります。

　アプリケーションとネットワークが高度化するにつれ、負荷分散装置には上記の機能以外にも、セキュリティやレスポンス低下防止、高可用性など、さまざまなテクノロジーが求められるようになってきました。その結果、多くの負荷分散製品はニーズに応えるべく多様な機能を付加し、今日のADCへと進化したわけです。

　ADCの根本的な考え方は「サーバはアプリケーションを動かすことに専念し、CPUもメモリも全てそのために使ってもらう。それ以外のアプリケーションに必要な要件は全て、サーバの手前にあるADC機器に集約する」というものです。

　当然、HTTP/2のような新しいWebプロトコルへの刷新時にも、ADCのアプローチは有効です。ユーザー側は新しいプロトコルを意識することなくHTTP/2対応のWebブラウザ経由でアクセスしてきます。その際、ADCが全てのHTTP/2セッションの受け口となり、結果として、ユーザーとADC間のみHTTP/2通信となります。

　一方、ADCとその背後にあるHTTP/2未対応のアプリケーションサーバ間は、従来通りのHTTP/1.1通信で当面しのぐという、いわば移行期間のような暫定的な措置も可能になります。慌てずゆとりを持って計画的にインフラの刷新を実現し、かつ対ユーザーの通信においてはいち早く新しいプロトコル対応を完了することができるのです。

　もしこのようなゲートウェイがなければ、HTTP/2への切り替えを急がなければならず、サーバの更新・刷新が悩みの種となってしまう可能性があります。

　企業であれコンシューマーであれ、行動の起点は「とりあえずネットで調べてから」が当たり前の時代です。自社のWebサイトやアプリケーションへ快適にアクセスしてもらえる環境を整えることは、ECやコンテンツ提供を担う業態はもちろん、そうでない企業にとっても重要な課題であることを意識しておきたいものです。