こんにちは。
とうとうやってきました。HTTP3！
今回はHTTP2とHTTP3の違いについてお伝えできればと思います。
この記事を書いている段階ではHTTP3未対応サーバーが結構見受けられますが、今後どんどん対応サーバーも増えてくるかと思いますので是非その実態を少しでもお伝え出来れば嬉しいです。

HTTPってなに？

Hypertext Transfer Protocol (HTTP) とはWEBサーバーとクライアント間でHTML 文書などのリソースを取り出すことを可能にするプロトコルです。
すごく簡単に言うと通信の決まり事みたいなものです。

例えば、Webページを閲覧する際を見ていきましょう。
クライアント側（サイトを閲覧するユーザー）がサーバーにリクエストします。
サーバーはそのリクエストを受け取ると、処理をしてレスポンスを返します。

【図1】

一つのWebページであっても、ページにもよりますがほとんどのWebページはサーバーからレスポンスされるデータは複数存在します。
例えばWebページが表示する為のHTML。
そのHTMLを元に画像ファイルやcssファイル、jsファイルなどがサーバーからレスポンスされるので、単純なページに見えていてもクライアント側で表示する際には、見えないところでこんなやり取りがなされているのです。

ざっくりとHTTPについて説明させて頂きましたが、HTTP/3のすばらしさについて、順にお伝えしていければと思います。

HTTP/1.1、HTTP/2、HTTP/3其々の違いについて

HTTP/1.1

TCP（Transmission Control Protocol）を利用しており、通信の際トラフィックを制御します。
これは、パケットの転送レート削減など、中間ノードや、ネットワークの許容量（処理能力やリンク数）を超過することによる輻輳を防ぐことで通信を確実に行う事が出来るプロトコルです。しかし、確実に通信が行われるまで待つ必要があります。

ただHTTP/1.1は、リクエストが1つづつしかできず、下記のように単一で処理されます。

【図2】に沿って、見ていきたいと思います。
ここでは、1つのリクエストに対して1つのレスポンスが送信されています。

【図2】

データ①をレスポンス→②リクエストに対してデータ②をレスポンス→③リクエストに対してデータ③をレスポンス。
しかし、リクエスト②の時、パケットの通信がうまくいっていませんね。
そういった場合、パケットは再送信されリクエスト②の通信を再度踏まなければいけません。
その際、TCPの特徴である“確実に通信が行われるまで待つ“という状態になる為、本来リクエストされレスポンスされるデータ③までスムーズに辿り付けなくなってしまいます。

HTTP/2

こちらもHTTP/1同様、TCP（Transmission Control Protocol）を利用しており、通信の際トラフィックを制御します。
HTTP/2では、クライアントからまとめてリクエストをする事が出来ます。
ですので、単一でリクエストとレスポンスをしなければならないHTTP/2に比べ、通信時間を大幅に削減する事が可能になりました。
現在では、多くのサーバーがこのHTTP/2に対応してます。

【図3】

HTTP/2すごい！まとめて処理とかすごい賢い！！！
しかし、現実はそう甘い話ばかりではありません。
そうです。HTTP/1.1同様、TCPを利用して通信の際トラフィックを制御しています。

【図4】

【図4】にあるように、複数のリクエストを受ける事が出来るのですが確実に通信が行われるまで待つ必要があります。

 

 

HTTP/3

UDP（User Datagram Protocol）ベースにした「QUIC」を利用。
まず、通信の処理の流れについて、【図5】を例に見ていきたいと思います。

HTTP/1.1、HTTP2では、単一でリクエストとレスポンスがされていましたが、HTTP3からは並行して複数の処理がされています。
パケット（データ③）が再送信される間に他のパケット（データ①、データ②）は先にクライアント側に送る、再送信されるパケット（データ③）も送る事が出来ます。
データ①データ②は”送るデータ”、データ③”送れなかったデータを再送信”といった二つの処理が同時にされている事が分かるかと思います。
つまり、並行して処理する事が出来るのです。

【図5】

ここまで、TCPとUDPでクライアントとサーバ間でのデータ通信の違いを見て頂いきました。
次は、UDPのベースになっている「QUIC」についてふれて行きたいと思います。

 

QUICと3WAYハンドシェイク

暗号化通信のための高速なハンドシェイクを行うTLS 1.3を含んでいます。(TLSハンドシェイク)
これは、ハンドシェークの直後から暗号通信をしている為です。
その為にはまず、従来利用されている3WAYハンドシェイクから触れていきたいと思います。

3WAYハンドシェイク

TCP（Transmission Control Protocol）で利用されています。
クライアント側とサーバー側で3回のコネクションを確立し、不正な通信を排除し、より整合性の高い通信を可能にしています。
簡単に言うと、データ取得を開始するまでに3回のやり取りが必要になってきます。
前述した過程を経て、TLSハンドシェイク（鍵交換のやり取り）を経て、通信が開始さます。

【図6】

QUIC

UDP（User Datagram Protocol）で利用されています。
元々Google社で開発された技術で、3WAYハンドシェイクのように
こちらは暗号化通信を前提としているため、TLSハンドシェイク（鍵交換のやり取り）が発生します。
こうする事で通信までのオーバーヘッドを大幅にカットする事で全体の通信速度を高速化する事ができる画期的な技術になります。

【図7】

最後に

いかがでしたでしょうか？
簡単にHTTP/3について触れさせていただきました。
SSLで整合性を保った通信を担保しながら、並行して複数の処理をする技術HTTP/3。
ものすごくシンプルに言えばクオリティを維持しながらも高速なんだ。という話なのですが、そうする為にも、私たちの見えない苦労の果ての技術が凝縮されています。
何気なく利用しているこの通信も、HTTP/1の頃では計り知れないくらいのデータ通信量になっていて、当たり前のように使われる裏には多くの技術や苦労が積み重なっているんですね。

「ボタンをしたらご馳走出てくる。そんな世界はつまらない。」と、昔某企業CMでやっていましたが、詰まるところの結果至高の賜物があるのだと。
その実態を知ろうともしない、考える事を忘れた果てに「つまらない」と嘆いてしまうのかもしれない。
本当にまだまだ知らない事ばかりだ、詰まらない空っぽな知識しかないな。と痛感しました。
そんな事を考えながら、この記事を執筆させて頂きました。
凄い余談になりましたが、少しでもお伝えできていれば幸いです。最後までお読み頂きありがとうございました。