2021-11-29

HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか？現代のプロトコル設計とインターネットの課題

IETFで標準化が進められているWebの新しい通信プロトコルQUICとHTTP/3について、現在のインターネットが抱える課題やプロトコル設計での議論を中心に、ASnoKaze blogの後藤ゆき（@flano_yuki）さんに執筆いただきました。

2021年、Webに新しい通信プロトコルが登場しました。RFC 9000として標準化されたQUICと、その上で動作するHTTP/3です。HTTP/3はまだドラフト版ですが出版準備段階となっており、すでに実際のWeb通信でも広く使われています

この2つのプロトコルは、現在のWebやインターネットが抱える課題について熟考された上で、設計・開発されています。どのような特徴のプロトコルなのか、どのような議論がされてきたのかを踏まえ、Webの現状とプロトコルの進化について私見を交えながら概観していきたいと思います。

なお、この記事ではプロトコルの意義や可能性にフォーカスしており、プロトコルそのものの技術的な解説については記事末に掲載した参考資料などを参照してください。

Webの発展によりHTTPの改良が必要になる
QUICとHTTP/3の登場と標準化
- 新しいトランスポートプロトコルQUICの特徴とメリット
- アプリケーションプロトコルHTTP/3の特徴
HTTP/3を通して見るインターネットの現在と未来
今後のWebの議論にも注目しよう
- 参考資料

Webの発展によりHTTPの改良が必要になる

今回の主題であるHTTP/3やQUICは、なぜ必要になったのでしょう？その背景にあるWebの発展について、まず軽く振り返ってみましょう。

Webは、私たちの生活に欠かせないものになっています。晩ごはんのレシピや明日の天気といった日常的な話題から、動画配信などの娯楽、行政サービスまでありとあらゆるところでWebが使われ、多くの人がWebを利用しています。

さらに携帯電話やスマートフォンの普及と性能向上、利用できるネットワーク帯域の拡大にともなって、Webのコンテンツはよりリッチになっています。Webコンテンツがリッチになると、1つのWebページを表示するために必要なリソース（HTML文書、画像、CSS、スクリプトなど）も増えます。必要なリソースが増えるにつれて、WebブラウザがWebページを表示するまでにかかる時間も増大します。

Webページが早く表示されることは、もちろん利用者にとってよいことですが、それだけでなくWebでビジネスを行いたい事業者にとっても重要な指標となっています。Webサイトが表示されるまで長く待たされると利用者の離脱が増え、Webページのビュー数や商品の販売にも悪影響を及ぼします。

このようにWeb利用者の増大と、Webコンテンツのリッチ化により、Webページの表示速度の重要性が高まる中、Webを高速化しようと考えるのは自然な流れです。Webブラウザやクライアントサイド、サーバーサイドのアプリケーションそれぞれで努力が行われていますが、Webコンテンツを配信しているプロトコル、つまりHTTP（HyperText Transfer Protocol)）を改良することで、この課題を改善したいと考えることも自然な流れです。

現在のインターネットでは、1997年に発表されたHTTP/1.1がまだ利用されています。これを改良しようと、2010年代にHTTP/2が標準化されました。そして上記のような背景からさらに多くの労力が投入され、より改良されたHTTP/3が登場することになりました。

QUICとHTTP/3の登場と標準化

HTTP/3の議論が始まったのは、2015年ごろです。ちょうどHTTP/2がRFC 7540として標準化され、利用も徐々に広がっていました。HTTP/2は、1つのコネクションで複数のリソースを取得できるように工夫されており、まさにWebのリッチ化が進む中で、Webページの表示速度の高速化を実現するプロトコルでした。

一方で、HTTP/2にも限界があり、さらなるWebの高速化をどう行うべきか模索する時期でもありました。とくに大きなトラフィックを扱うクラウドやCDNを提供する企業では、自社のサービスを利用してもらうことでWebページをより早く表示できるようになるなら、ベンダーとしても力を入れるところです。

Googleでは2012年から、自社で開発しているWebブラウザ（Google Chrome）とWebサービスで、新しく開発したQUICというプロトコルを試していました（現在標準化されているQUICとは異なります）。

このQUICの成果が公表されると大きな注目を集め、議論の場をインターネットプロトコルの標準化を行っているIETF（Internet Engineering Task Force）へと移します。ここでQUICはTCPに代わるトランスポートプロトコルとして、そのQUICを利用するアプリケーションがHTTP/3として標準化が進められました（HTTP/3という名称は2018年に合意されたもので、それまでは「HTTP over QUIC」と呼ばれていました）。

新しいトランスポートプロトコルQUICの特徴とメリット

HTTP/3を語る上で切り離せないQUICについて、簡単に紹介していきます。

QUICは、トランスポートプロトコルです。トランスポートプロトコルの役割は、アプリケーションプロトコル（HTTPなど）のメッセージを通信相手に伝達することです。HTTP/3と一緒に設計が進められたQUICですが、汎用的にHTTP以外のアプリケーションでも使用できます。

QUICはUDPの上で動作しつつ、TCPと同じようにメッセージの信頼性をアプリケーションに提供します。インターネット上の通信では、何らかの理由でパケットが失われたり、順番が入れ替わることがあります。その場合でも、QUICが再送や並べ替えを行って、アプリケーションがメッセージを正しく処理できるようにします。

さらにQUICでは、TCPよりもいくつかの工夫がされています。

各コネクションはQUICが定義するコネクションIDで管理される
- IPアドレスやポート番号が変わってもコネクションは切断されない（コネクションマイグレーション）
コネクションの中に、仮想的な通信単位であるストリームという概念がある
- 1つのコネクション上で、アプリケーションメッセージを並列的に扱いつつ、パケットロスに対しても効率よく処理できる
TLS 1.3（暗号化プロトコル）を内部でハンドシェイクに利用している
- TCPの上でTLSを利用する場合に比べて、より早くコネクションを確立できる
アプリケーションのメッセージはもちろん、QUICのパケットもほとんどの領域が暗号化される

とくにHTTPのように同じ相手と並列的に多くのメッセージをやりとりする場合、ストリームが利用できることは有益です。QUICのストリームでは、パケットロスが起こった場合でも、受信できたパケットから処理を進めることができます。

このようにQUICには多くの長所があり、アプリケーションがトランスポートプロトコルをTCPからQUICに切り替えるだけで（単純にできるわけではありませんが）、こういったメリットを享受できます。

アプリケーションプロトコルHTTP/3の特徴

HTTP/3は、HTTPメッセージを効率よくやりとりするための考案されたプロトコルです。大きなポイントは、トランスポートプロトコルとしてQUICを利用することです。上記のようなQUICの特徴を生かし、そのメリットを享受できるように設計されています。

ですので、HTTPメッセージ（HTTPリクエストやHTTPレスポンス）の意味は既存の通信と変わりません。クライアントからHTTPリクエストが送信され、サーバからHTTPレスポンスが返されます。そこで用いられる、リクエストのGETやPOSTといったメソッド、レスポンスのステータスコード、ヘッダは今まで通りです。

こういった通信上がバイナリ形式で送られる点は異なるものの、WebブラウザおよびロードバランサやミドルウェアなどがHTTP/3に対応するだけで、多くのクライアントサイドとサーバサイドのアプリケーションは変更なく動作します。

なお、QUICはUDP上で動作するトランスポートプロトコルなので、HTTP/3もルータなどでUDPのトラフィックとして扱われます。既存のHTTP/1.1やHTTP/2は、従来通りTCPのトラフィックです。この点も大きな違いと言えます。

HTTP/3を通して見るインターネットの現在と未来

ここまで、QUICやHTTP/3がどのようなプロトコルなのかを見てきました。ここで視点を変えて、プロトコル標準化の議論を踏まえつつ、インターネットの現在と未来について考えてみましょう。

まず、QUICはどのような点に気を付けて標準化されたのか？それを通して現代のプロトコル設計とインターネットの課題について見ていきます。

現代のプロトコル設計において議論される暗号化の観点

QUICでは、ほとんどの領域が暗号化されています。アプリケーションデータだけでなく、通信の制御用メッセージも暗号化されています。これは、盗聴やさまざまな攻撃から通信を保護するためです。

米国政府が関与する大規模なインターネット盗聴が2013年に報告された事実を踏まえ、IETFでは翌2014年に「Pervasive Monitoring Is an Attack（広範囲にわたる監視は攻撃）」と題したRFC 7258を発行し、通信の暗号化に力を入れてきました。

暗号化には別の観点として、インターネットの硬直化（ossification）に関連したトピックもあります。硬直化とは、古いネットワーク機器（ファイアウォールやルータなどのミドルボックス）が新しいプロトコルを正しく解釈できず、通信に不具合を起こす問題です。

TCP Fast OpenやTLS 1.3といったより新しいプロトコルをインターネットで利用しようとしたときに、ミドルボックスがその通信を古い決め打ちのロジックで処理したがゆえに、奇妙な振る舞いをする硬直化の問題が認知されるようになりました。これに対してQUICでは、バージョン固有の鍵で暗号化することで、プロトコルを古い実装でパースしたり処理したりできなくしています。

また、プライバシーも重要な点です。QUICではユーザをトラッキングできないよう工夫されています。識別子として使えるようなユーザ固有の値があると、通信経路上の観測者は、その値をもってユーザが物理的に移動していることなどを観測できてしまいます。QUICでは、コネクションIDと呼ばれる識別子がありますが、暗号路上で更新する仕組みを持つことで対策をしています。

ここまで述べたように、盗聴・硬直化・プライバシーに関する観点は、現状のインターネットで通信をする上で大事なポイントになるでしょう。新しいプロトコルを作る上でも、注意深く設計される点となるでしょう。

将来にわたって議論が必要なインターネットの課題

QUICやHTTP/3の登場により、インターネットの課題は解決されたのでしょうか？ここでは、いくつか今後の課題について、私見を交えながら見ていきましょう。ここでは2つ紹介します。

通信帯域
検閲やブロッキング

インターネットの通信量は日に日に増加するばかりです。高速大容量で超低遅延な通信をうたう5G（将来的にはBeyond 5G）の利用も、今後は広がっていくでしょう。それに伴って通信されるコンテンツの容量も増え、なおかつレイテンシについても引き続き改善が求められるでしょう。すでに帯域の利用の上昇に懸念を述べているベンダーもあります。それに対して、QUICを用いたマルチキャスト通信によって帯域を効率よく使う方法が模索されはじめています。

先に述べた通り、IETFでは通信の暗号化に注力しています。その一方で、検閲やブロッキングといったことが、さまざまな目的をもって行われている国や地域があるのも事実です。一概に良い悪いと言えるものではなく、議論が引き続き必要です。IETFとしては、例えばTLS Encrypted Client Hello（ESNIとも呼ばれていた）といった、既存の通信において平文で行われていた情報を暗号化する取り組みも進めていますが、非技術的な要素も含めて多くの課題があります。

QUICはこれからどう変化していくか

最後に、QUICやHTTP/3自体について議論されていることを紹介します。

まず、QUICには機能を追加する仕組みがあります。現在、以下のような拡張機能が議論されています。

QUIC Datagram
QUICではアプリケーションプロトコルはパケットがロスすると必ず再送されるが、再送不要なアプリケーションメッセージの送信を可能にする拡張案
Multipath QUIC
複数の通信経路を使ってコネクションを張れるようにする提案
例えば、Wi-Fiとキャリア回線といった複数の通信経路を利用できるようになる

また、QUIC自体のバージョンネゴシエーションの仕組みにも議論が進められています。具体的にはまだ何も決まっていませんが、将来的にはQUIC version 2が登場するかもしれません。

前述したようにQUICはHTTP以外も使用できる汎用的なトランスポートプロトコルなので、既存のアプリケーションをTCPやUDPに代えてQUIC上で動作させる取り組みも進められています。IETFに提出されている提案仕様をいくつか紹介します。

DNS over QUIC（DNS over Dedicated QUIC Connections）
SSH over QUIC（QUIC-based UDP Transport for SSH）
BGP over QUIC（BGP Over QUIC）

その他にIETFでは、HTTP/3やQUICに関連した次のような取り組みがあります。

WebTransport
WebSocketに変えてHTTP上においてクライアント／サーバ間で双方向通信を行うプロトコル
HTTP/3やQUIC Datagramを活用し、柔軟な通信を可能とする
Masque
HTTP/3上でコネクションを確立し、そのコネクション上でパケットをトンネリングさせることでVPNのように扱う仕組み
Media over QUIC
QUICで動画の送信を効率化する取り組みで、さまざまな提案が出ている
例えばFacebookが開発したRUSHでは、配信者が動画をアップロードする際にQUICを利用している

なお、これらは全て議論中であり、今後の成り行きで変更される可能性もあります。