SPDY、そしてHTTP/2の誕生
2009年、米グーグルによるWeb高速化の取り組みの一環から﹁SPDY﹂プロトコルが生み出されました。SPDYは、既存のHTTPと互換性を保ちながらセッション層を効率化する画期的なプロトコルで、TwitterやFacebookなどの有名サイトも次々とこの仕組みを取り入れるようになりました。 ﹁HTTP/2﹂は簡単に言えば、このSPDYを改良したものです。したがって、HTTP/2は従来のHTTP/1.1に新しくメソッドやヘッダによって機能を追加するものではなく、HTTPの表面上の機能はそのままに内部動作を置き換えるものです。次の図は、SPDYとHTTP/2のプロトコルのイメージです︵右の図は少々違和感があるかもしれませんが︶。![HTTP/2とSPDYの位置付け](http://cz-cdn.shoeisha.jp/static/images/article/8663/http2-position.png)
HTTP/2は、標準化団体IETF(Internet Engineering Task Force)のHTTPBisワーキンググループによって仕様の策定が進められ、今年5月にRFC化を果たしました。議論の様子はGitHub上の「http2/http2-spec」で見ることができます。
![HTTP/2とSPDYの関係。HTTP/2の仕様策定はSPDY/3をコピーして開始された](http://cz-cdn.shoeisha.jp/static/images/article/8663/spdy-http2_2.png)
実は、HTTP/2には日本のコミュニティが多くの貢献をしています。活動内容はHTTP/2のサーバ・クライアント実装(ローカルコミュニティとしてはかなり多いです)からIssueに対する議論、テストケースの作成など様々で、RFCに謝辞が載るまでになりました(p94 Acknowledgementsの一番下)。Webの未来に興味のある方は、こうしたコミュニティに参加してみるのも面白いと思います。
なぜHTTP/2の登場が必要だったのか
そもそも、SPDYやHTTP/2が解決しようとした問題とは何だったのでしょうか? 一番の問題は、プロトコルの仕様に起因するパフォーマンスの悪さです。以降では、従来のHTTPではパフォーマンスが悪くなる根拠を、HTTP/2登場の背景として説明します。HTTP/1.1とその限界
HTTPでは、1つのリクエストが完了するまで、次のリクエストを送ることができません。現在のWebでは1ページに多くのリソースを必要とするため、この方法は明らかに非効率です。この制約を回避するために、多くのブラウザは1ドメインへの接続を同時に複数行うことで、通信の多重化を図っています。 次の図は、Chromeブラウザで同時に多くの画像を読み込む例です。Chromeが同時に送信するリクエストは6つまでである︵7つ目以降はブロックする︶ことが分かります。
また、同時接続はネットワークに負荷をかけるため、本来HTTP/1.1の仕様としては2つまでにすべきとされています。
HTTPパイプライン
実は、HTTP/1.1から、前回リクエストの完了を待たずに次のリクエストを送信してもよいことになっています。これを実現しているのは「HTTPパイプライン」という仕組みです。相手側のリソースに余裕がある限りどんどんリクエストを送ってよく、新たに余裕ができ次第、さらに次のリクエストを送ることが可能です。
![HTTPパイプライン](http://cz-cdn.shoeisha.jp/static/images/article/8663/pipeline.png)
リソース読み込みを速くする様々な工夫
このような条件下で可能な限りパフォーマンスを出すため、Web開発者によって多くのプラクティスが生まれました。Webアプリケーション開発に携わっている方であればお馴染みかもしれません。リソースの結合
複数のファイルを1つに結合すれば、リクエストの数を減らし、余計な待ち時間を減らすことができます。画像の場合、複数の画像を1枚の画像に集約した上で、CSSから目標の座標を指定するというテクニック︵CSSスプライト︶を用います。画像のインライン埋め込み
ページの表示に必要な画像はブラウザがHTMLを受け取った後に改めてリクエストする必要があります。そこで、次のように記述することで、HTML内にbase64でエンコードした画像を直接埋め込む方法があります。<img src="data:image/gif;base64,HRv3ABkAOYAAGYIAL65qSb+gbLeJGRi~(省略)">