HTTP2とは
HTTP Client APIでの簡単な使い方のみであれば、HTTP2とHTTP1.1の違いについてほとんど意識せずにコードを記述できます。
これはHTTP2での特徴でもありますが、HTTP Client APIを使った場合、HTTP2が接続できない場合には、自動的にHTTP/1.1になるなどAPIの利用者はコードレベルでは気にすることがほとんどありません。
しかし、APIの細かな違いや、複数のリクエストを非同期で扱うケースが生じた場合には、アプリケーションの開発者であってもHTTP2の特徴を知ることは非常に大切です。
そこで、詳しいプロトコルの説明はここでは行いませんが、HTTPのクライアント側のコードを実装する場合に知っておいた方がよいHTTP2とHTTP/1.1などの違いについて簡単に説明します。
HTTP/1.0やHTTP/1.1（KeepAliveを使わない場合）で通信する場合には、図1のようにリクエストする度にTCP/IPの接続をし、レスポンスを返すと接続を切って1つの処理が完了します。
プログラムからHTTPのリクエストを行う場合には通常この流れが多いと思います。
一方で一般的なブラウザがあるHTMLをリクエストする場合には、図2に示すように1つの接続で複数のリクエストとレスポンス処理を行っていきます。
これは、KeepAliveと呼ばれていて、この機能があることで通常のHTMLでは関連する画像、CSS、JavaScriptなど必要なリソースを取得する度に再接続をする必要がなくなります。
ただし、実際にはすべてのリクエストで接続が再利用されるわけではなく、サーバ側から切断されるケースもあり、その場合にはクライアント側からは再接続しなければなりません。
こういったことを考えたコードを記述するのは多少困難になり、JavaなどプログラムからHTTPリクエストを行う場合には、KeepAliveの機能は使わずリクエストの度に接続を作る処理を行う方が多いと思います。
また、一般的にはクライアント側からは必要なリソースは同時に取得を始めた方が効率がよいので同時接続をしたいのですが、サーバ側にとっては1つのクライアントが何個もの接続を使ってしまうことは好ましくありません。そうした意味で、KeepAliveという機能はどちらかと言えばサーバ側の都合であると言ってもよい機能です。
しかし、1つの結果を取得するまで次のリクエストが送れない状態では、1つのページを表示するにも非常に時間がかかってしまい、結局、現実ではブラウザ側は同時に接続を行ってしまいます。
そこで、この欠点を克服したのがHTTP2です。HTTP2では、図3（左図）のように１つの接続の中に仮想の接続（ストリーム）をリクエストごとに作成し、そのストリームの中でリクエストに対してレスポンスを返してあげます。
こうすることで、従来クライアント側で同時に接続してしまっていた部分が接続内部のストリームの同時利用に置き換わるので、実際の接続は1つのままでよくなります。
そして、これまでのHTTP1.1で行っていた処理の流れと変わらないため、これまでのコードとも互換性が保ちやすくなります。
その結果、右図に示すように途中に重い処理があっても、それによって次のレスポンスが待たされることなくクライアント側に返すことができるのです。
