HTTPはHTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0といった具合にバージョンが重ねられるごとに機能改善をしてきました。そして現在もっとも普及しているのがHTTP/1.1です。

HTTP/1.1

HTTPキープライン

HTTPリクエストやHTTPレスポンスといったデータのやりとりをする際、TCPを用いて行われます。このTCPを利用する時コネクションという通信経路を確立します。HTTP/1.0以前ではHTTPリクエストが送る時コネクションを確立、HTTPレスポンスとしてデータが返ってくると切断されていました。これだと毎回の通信毎にコネクションを確立する必要があり(コネクションを確立する際3回通信が行われる)、余分な通信が起きてしまいます。webページにたくさんの画像が使われるようになるとこの方法では効率が悪く、余分な通信が発生してしまします。HTTP/1.1にバージョンが上がってからはコネクションを維持し続ける方法が確立されました。これをHTTPキープアライブといいます。

HTTPパイプライン

HTTP/1.1では通常リクエストを一回送るとレスポンスが返ってくるまで、原則次のリクエストが送れないといった欠点がありました。これだとwebサイトに画像が複数あると一個の画像の読み込みが終わるまで次の画像の読み込みが始まらないといった非効率な通信となってしまいます。そこでHTTP/1.1ではリクエストの完了を待たずに次のリクエストを送ることができる仕組みとしてHTTPパイプラインが実装されました。
ただしHTTPパイプラインには二つの問題がありました。一つがHTTPパイプラインはサーバー側できちんとした対応がされていないとブラウザのリクエストを処理できない問題がありました。二つ目が「サーバーはリクエストが送られてきた順番でレスポンスを返さなければいけない」という制限があります。そのためほとんどのブラウザではHTTPパイプラインはoffになっており、ブラウザ側で複数同時接続を行うことである程度通信の多角化を図っています。

HTTP/2.0

HTTP/1.1では一回リクエストを送ったらレスポンスが返ってくるまで原則次のリクエストが送れないという欠点を補うためにHTTPパイプラインという仕組みがありました。しかしHTTPパイプラインは複数のリクエストを送ることはできても、リクエストを送った順番でレスポンスを返さないといけないという制限がありました。結果webサイトを読み込む際、レスポンスが遅いものがあればそれ以降の読み込みが止まってしまい、webサイトの表示速度が遅くなる問題がありました。HTTP/2.0ではその問題を解決するためにストリームが実装されました。

ストリームによる多重化

ストリームはTCPのコネクション内に仮想的な独立した通信経路のことをいいます。複数生成することで、それぞれのストリーム内でリクエストとレスポンスをやりとりできるため、「リクエストを送った順番でレスポンスを返す」といった制限がなくなり、より効率良く通信をすることができるようになりました。

バイナリ形式の利用

HTTP/1.1以前ではリクエストとレスポンスのデータをテキスト形式(人が読みやすい)でやりとりしていました。バイナリ形式(コンピュータが読みやすい)のデータであっても一度テキスト形式に直してからやりとりしていました。HTTP/2.0ではよりデータのやりとりをバイナリ形式でもできるようになり、変換にかかる時間がなくなり、webブラウザとサーバーの負担も軽減されました。

ヘッダの圧縮

HTTP/2.0ではヘッダを圧縮することデータ量を軽量化することができます。HTTPリクエストだと利用しているブラウザの種類など、HTTPレスポンスだとwebサーバーのバージョンの種類がヘッダ情報に含まれています。HTTPリクエストとHTTPレスポンスの繰り返しやりとりする上でこのような情報は重複することがあります。HTTP/2.0ではヘッダ情報から差分のみを取り出して送るHPACKという圧縮方式が用いられています。

サーバープッシュ

サーバープッシュはHTTPリクエストの内容からサーバーが必要なファイルを判断し、事前にwebブラウザに送る仕組みです。通常はHTTPリクエストが送られてきてから必要なファイルをHTTPレスポンスとして返します。あるindexファイルには画像ファイルが必要だったら、そのHTTPリクエストが送られてくるまでサーバーは画像ファイルを送ることはありません。HTTP/2.0では最初のHTTPリクエストが送られてきた段階で、もしindexファイルには画像ファイルが必要と判断したら、HTTPリクエストが送られずともwebサーバーから転送します。