IETF標準化報告 [第2弾] ～2022年の、HTTP・QUIC関連の標準化トピック～
tech_team IETF インターネットの技術先日公開した「IETF標準化報告 [第1弾] ～IETF 112より～」に続いて、第2弾としてHTTP・QUIC関連の標準化トピックをご紹介します。今回のレポートは、後藤ひろゆき氏（グリー株式会社）にご執筆いただきました。
はじめに
今回は、2021年を振り返りながら、2022年に標準化が行われるトピックについて紹介していきます。
2021年はWebを中心に、HTTP/3やQUICの実利用が進みました。IETFの取り組みとしては、QUICは2021年5月にRFC 9000として公開されました。HTTP/3も、標準化が最終段階となっています。このように、QUICやHTTP/3のコア部分の取り組みはほぼ終わっており、それらの拡張仕様や、発展的な仕組みづくりが行われました。
それでは、関連するIETFワーキンググループごとに紹介していきます。
QUIC WG
先述の通り、QUIC Version 1 (QUIC v1)が、RFC 9000として標準化が完了しています。現在、QUIC WGでは、いくつかの拡張仕様に取り組んでいます。それらは、QUICのパフォーマンスを向上させるものや、QUICの次のバージョンを見据えた取り組みになっています。
大きなトピックの一つとして、「Multipath Extension for QUIC」が挙げられます。これは、Multipath TCPのように複数経路を利用してコネクションを確立するという仕様です。もともとは、QUIC WGのチャーターにもトピックの一つとして上がっていましたが、仕様が複雑だという難点がありました。QUIC v1の標準化が進み、2021年は再びMultipathのユースケースや要件の整理が行われました。2022年には、正式にWGアイテムになることが予想されます。
もう一つの大きなトピックとして、「Compatible Version Negotiation for QUIC」、「QUIC Version 2 (QUIC v2)」があります。これらは、将来のQUICバージョンを見据えた準備になります。具体的には、バージョンネゴシエーションの仕組みを設けること、新しいQUICバージョンがインターネット上でディプロイできることを確認する、という取り組みです。QUIC v2は、機能的にはQUIC v1とまったく同じですが、このQUIC v2を利用して、バージョンネゴシエーションやディプロイ性の確認を行う目的で、標準化が進められています。
2022年は、QUICの拡張仕様の議論が進むことでしょう。
HTTP WG
2021年、HTTP WGは比較的穏やかに進行しました。IETFの本会合でもセッションを行わず、WGの中間会議を重ねてきました。主な取り組みとしては、HTTPCoreと呼ばれているドキュメント群の標準化です。これは、HTTP/1.1 (RFC 7231)の仕様からHTTPセマンティクスを分離し、HTTP/2やHTTP/3の仕様から独立して参照できるようにするという作業です。
このHTTP Coreの仕様群も「HTTP Semantics」、「HTTP Caching」、「HTTP/1.1」として、標準化の最終段階になっています。RFC Editor Queueに先に入っていたHTTP/3も、HTTP Semanticsの仕様に依存しているため、これらの仕様は2022年にRFCとして公開されるのではないかと思います。
その他にも、Cookieの仕様や、HTTPメッセージの優先度制御の仕組みなどの取り組みが進められています。
2022年はHTTP/3の標準化とともに、引き続きHTTPのメンテナンス作業が行われるでしょう。
WebTransport WG
WebTransportは、比較的新しいWGです。まず簡単に、WebTransportとは何なのか説明します。
もともとWebでは、HTTP上で双方向のアプリケーションデータのやり取りを行うために、WebSocketという仕組みが利用されていました。そういった中で現在、HTTP/3というプロトコルが出てきました。HTTP/3はQUIC (UDP)上で動作し、仮に経路上でパケットロスやパケットの順番が入れ替わったとしても、それ以外の受け取ったパケットについては、処理を進めることができます。このHTTP/3の特性を、Webでの双方向アプリケーションデータのやり取りに活かしたいというのが、WebTransportという新しい仕組みのモチベーションになります。
特に、パケットロスがあったとしても、再送をしないアプリケーションデータの送信というのは、今までのHTTPではできないことです。
2021年、このWebTransportは下位層にQUICを使うか、HTTP/3を使うかという議論が行われていました。議論のすえ、HTTP/3を利用したものの標準化を進めるコンセンサスが得られました、また、合わせてHTTP/2を利用するものも、標準化をすることに決まりました。
WebTransportは、すでに一部のブラウザで実装が進められており、2022年はWebTransportの実利用および仕様のブラッシュアップが行われるでしょう。
Masque WG
Masque WGも、比較的新しいWGです。Masqueは、Multiplexed Application Substrate over QUIC Encryptionの略であり、確立したHTTPコネクション(主にHTTP/3を想定)上で、別の通信をトンネリングする仕組みの標準化を行っています。例えば、Masque ProxyサーバにHTTP/3コネクションを確立した後に、そのコネクションを利用し、UDPパケットをProxyしてもらうといったユースケースを検討しています。
また、AppleのPrivate RelayがこのMasqueの仕組みを使って、第三者のWebサービスに対してユーザーのIPアドレスを隠すサービスを展開していることもあり、比較的ホットなトピックになっています。
2021年は、UDPパケットを転送する仕組み、IPパケットを転送する仕組みなどの議論を行い、それぞれWGアイテムとなっています。2022年は、引き続きこれらの仕様のブラッシュアップ作業が進められるでしょう。
Media over QUIC
Media over QUICは、まだワーキンググループにすらなっていませんが、IETF本会合中にサイドミーティングが行われるなど、比較的ホットなトピックです。
その名の通り、QUIC上でメディアデータをどのように転送するか議論を行っています。ライブメディアでは、いかに速く配信者から動画を受け付け、視聴者に届けるかが重要なポイントになります。そこでQUICを利用できないかというのが、モチベーションになっています。
2021年は、ライブメディアを扱うステークホルダ間で、要件やユースケースの取りまとめが行われました。一方で、FacebookやTwitchでは、すでにそれぞれ独自の方法で、Media over QUICを行っている旨共有されています。関心を持つ企業は多いですが、いくつかのユースケースがあり、まだ方向性は固まっていません。
2022年は、関心を持ついくつかの企業から、具体的な実装や提案仕様などが出てくるのではないでしょうか。それらを出発点に、標準化の方向性も見えてくることでしょう。
おわりに
2021年は、やはりQUICの標準化が大きなトピックでした。QUIC v1の標準化が完了するとともに、ここまで紹介したように、QUICやQUICを利用するHTTP/3の応用の議論が多く行われました。
2022年は、2021年に上がった議論をもとに、それぞれのトピックが標準化に向かう年になりそうです。まだまだ、熱いトピックですので、興味のある皆様は、関連するWGの議論を覗いてみてはいかがでしょうか。