HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として

今回は「HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として」についてご紹介します。

関連ワード （仕組、以上、参考等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

現在標準化が進められている新たなHTTPである「HTTP/3」のトランスポート層プロトコルとなる予定の新しい通信プロトコル「QUIC」が、インターネットで用いられる通信プロトコルなどの標準化を行う団体のIETF（Internete Engineering Task Force）により「RFC 9000」として策定を完了、新たなインターネット標準になったことが明らかになりました。

QUICはもともとHTTPをより高速化するためのトランスポート層プトロコルとしてGoogleが開発し、その後IETFで標準化が進められてきました。

QUICはまずは次世代のHTTPであるHTTP/3のトランスポート層プロトコルとして使われますが、今後それ以外にもさまざまなプロトコルのトランスポート層プロトコルとして使われていく見通しです。

参考：マイクロソフトが「SMB over QUIC」ファイル共有プロトコル実装中。VPNなしでもインターネット上で安全にファイルサーバへのアクセスを実現へ

インターネットで使われているインターネットプロトコル（IP）には、トランスポート層プロトコルとして「UDP」と「TCP」の2つが存在しています。

おおまかに言えば、UDPはパケットがちゃんと届いたかどうかをあまり気にせずどんどん投げつけるプロトコルで、TCPはパケットが失われず順番通りに届くことが保証されたプロトコルです。

それぞれの特徴を生かして、UDPは動画送信のように通信内容が多少失われることを許容しつつ高速な通信を優先したいアプリケーションなどに使われ、TCPは文書のように内容が壊れると困るデータの転送などに使われてきました。

WebサーバとWebブラウザのあいだで通信を行うためのHTTPプロトコルは、当初からTCPを用いて通信を行っています。

しかしこのHTTPをより高速にやりとりしようと最適化とバージョンアップを重ねてくると、やがてHTTP自体の改善にとどまらず、TCPそのものの遅さを改善することが視野に入ってきました。

TCPはパケットが失われず、順番通りにきちんと届く信頼性の高い通信を実現してくれますが、それを実現するためのさまざまな仕組みが備わっているためにUDPと比べてオーバーヘッドの大きい、遅いプロトコルになっているのです。

そこで、UDPを基に、TCPのような信頼性を保ちつつもより高速な通信を実現しようとして開発されたのがQUICです。

もともとQUICの開発を始めたのはGoogleで、それを基にIETFが標準化を進めたのが、今回RFCとして標準となったQUICです。

QUICがどのようなプロトコルなのかは、別の記事「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説」で詳しく紹介しているので、ぜひそちらをご覧いただくとして、ここではその記事からいくつかポイントの図を引用します。

QUICは、おおまかには下記のような構造になっています。

左が従来のHTTP/2、右がQUICを用いたHTTP/3です。UDPを基にQUICが実装され、そのうえにHTTP/3が乗っていることが示されています。

そして次のような特徴を備えています。

QUICを用いたHTTP/3は、WebブラウザとWebサーバが対応すれば自動的に使われるため、ユーザーはHTTPのどのバージョンを利用しているかを気にすることはありません。

すでにGoogle Chromeのユーザーのうち、25％以上でHTTP/3が自動的に使われるようになっているそうです。今回、QUICの標準化が完了し、まもなくHTTP/3も標準化が完了する見通しで、今後さらにQUICとHTTP/3によるWebの進化は広がっていくことになるでしょう。