連日暑い日々が続いていますが、みなさんいかがお過ごしでしょうか。
WYRDの豊田です。
最近は日傘とハンディ扇風機を常に携帯するようになりました。
マスクをしながら、この酷暑を乗り切るのは今年で最後にしたいところですね。
さて今回のブログでは、HTTP/3を実現する上で合わせて策定され、5月にIETFにより承認された”QUIC”（クイック）というプロトコルについて書いていこうと思います。
HTTPの歴史
QUICを説明するには、まずHTTPの変遷について理解しておく必要があります。
HTTP/1.1
HTTP/1.1は、1997年に最初のRFCが発行されて以来、これまで何度も拡張を繰り返し、現在も利用され続けています。
近年のインターネットの目覚ましい発展により、HTTPには通信データ量の増加、通信速度の高速化が求められるようになりました。
ここでHead of Line Blockingという問題が表面化します。
HTTP/1.1には「リクエストとレスポンスは送受信の順番を一致させる」というルールがあり、処理に時間のかかるリクエストをすると、その処理が終わるまで次のリクエストは処理を待たされます。
これを(HTTPレベルの)Head of Line Blockingと言います。
クライアント サーバー | | |--------- req_1 -------->|---- | | ^ | | | | | この間req_2を送っても処理されない | | | | | v |<-------- res_1 ---------|---- | |
いくつかの回避策（HTTPパイプラインやコネクション多重化）は考えられましたが、どれも根本的な解決にはなりませんでした。
通信の効率が落ちてしまうこの問題は、発展を続けるインターネットの世界で悩ましい問題だったと言えるでしょう。
HTTP/2
2015年5月、HTTP/1.1の抱える問題の解決を図るため、新たなRFCが採用されます。これがHTTP/2です。
HTTP/2では、ひとつのTCPコネクション内にストリームという通信の単位が与えられ、リクエスト-レスポンスをセットで管理するようになりました。
個々のストリームを独立した通信として管理することで、あるストリームで発生した遅延が他ストリームに影響を及ぼすことはなくなりました。
これで(HTTPレベルの)Head of Line Blockingは解決されました。
※HTTP/2ではヘッダの圧縮など、他にもさまざまな点で効率化が図られましたが、今回は割愛しています
HTTP/2にも問題があった
HTTP/2の登場により、全て解決…とはなりませんでした。
次に問題になったのは(TCPレベルの)Head of Line Blockingでした。
TCPとは、HTTPのプロトコルスタックにおいて、下層で利用しているトランスポート層のプロトコルです。
TCPは通信の信頼性（データの欠落や誤りが無い）を保証します。
その性質上、通信（パケット）に問題が発生した場合、その問題が解決されるまでTCPレベルで通信が止まります。
HTTPはTCPの上で動作するプロトコルなので、TCPレベルで通信が止まると、当然HTTPも通信が止まります。これが(TCPレベルの)Head of Line Blockingです。
多くの場合TCPの信用性の担保はOSレベルで行われるため、アプリケーション(HTTP)は問題が解決するまで待つしか無いのです。
QUIC登場
2013年、Googleが独自に開発を進めていた QUICというプロトコルが発表されます。
当時はトランスポート層とアプリケーション層のプロトコルが混在し、プロトコルスタック上では明確に分けられていなかったようです。
TCPレベルのHead of Line Blockingに対する解決が試みられていたこのプロトコルは、2016年にIETFワーキンググループが発足し標準化が進められることになります。
QUICの特徴
QUICはトンランスポート層のプロトコルですが、下位プロトコルに同じトランスポート層のUDPを利用しているという特徴があります。
UDPは通信の信頼性を保証しませんが、上位のQUICが通信の信頼性を保証するための拡張を行います。
TCPでは手の届かなかった痒いところをUDPの拡張により解決した感じですね。
2020年時点で、QUICにはGoogle QUICとIETF QUICという“似て非なるプロトコル”が混在している状況ですが、Googleは順次IETF QUICに対応していくことを明言しています。
ChromeではすでにHTTP/3が？
QUICと並行して策定が進められているHTTP/3は、現在草案34版がでていますが、正式なRFCにはなっていません。
ただし、最新のGoogle Chromeを使ってGoogleのトップページへアクセスすると、すでに（部分的に）HTTP/3が利用されていたりします。（Protocolが “h3” となっている）
最後に
QUICはTLS（暗号化）なども一手に引き受けることで、コネクション確立を効率化したり、トランスポート層の通信内容まで暗号化できるなど、他にもさまざまな改善が盛り込まれています。
ただ、世界にはすでにたくさんのTCPで動作する機器が存在していることもあり、すぐにQUICが主流となることはなさそうです。
環境と仕組みが相互に発展を続けていく、というサイクルの象徴的な出来事と言えるかもしれません。
