2021年 HTTPやQUICの最新動向振り返り

HTTP QUIC TLS 雑

2021年について、プロトコル周りの動向を振り返っていきたいと思います。

今年は、個人的には次の2点がホットトピックと挙げられると思います。

  • QUICやHTTP/3を活用した応用系プロトコルの作業が進む
  • プライバシー系の取り組みが活発化

それでは、個別に補足していきます。（IETFの動向がメインです。なお、個人的にキャッチアップできてないトピックもあります...）

f:id:ASnoKaze:20211231030248p:plain

HTTP関連

まずは、HTTPです。HTTP/3の標準化が注目を浴びていますが、HTTP/1.1やHTTP/2なども改定作業が行われております。あわせて、HTTPセマンティクスは各バージョンから独立し、各バージョンから参照される形となりました。それぞれRFC出版の最終段階となっています。

f:id:ASnoKaze:20211230235428p:plain

書いた記事はここらへん

また、それ以外にもメソッド・ヘッダ・Cookieなど様々な仕様が提案されております

また、書いたのは一昨年ですが、次のトピックも標準化が進められています

その他書けていないトピックとしてRFC6265 HTTPのCookieも仕様の改定作業が進められています

QUIC

QUICは、RFC 9000として標準化が完了しました。いくつかの拡張仕様の議論や、実際のQUICの運用に関するトピックの議論が行われています。

個人的に注目しているところとして、Ossification(硬直化)対策として進められているQUIC v2や、Wi-FI+LTEといった複数通信を扱うMultipath QUICといったトピックがあります。
書いた記事はここらへん

その他記事には書けておりませんが、QUIC WGでは他にも次のような仕様の標準化が進んでいます

DATAGRAM拡張

QUICにはDatagram拡張という仕様の標準化が進められています。トランスポートプロトコルであるQUICはアプリケーションプロトコルのデータは再送されますが、再送を必要としない通信方法を規定しています。WebTransportやMASQUEなど多くのプロトコルで利用されます。

もともとはHTTP/3で利用のみとして標準化されていますが、TCPにより再送されてしまいますがHTTP/2, HTTP/1.1でも利用できる形での標準化が目指されています。また、DATAGRAM拡張自体を拡張出来るように現在専任デザインチームで議論されています。そのため、またその部分は変更されるものと思われます。

WebSocket, WebTransport

Webでのアプリケーションデータの双方向通信として、WebTransportというものが出てきました。これはHTTP/3を活用し再送が不要なアプリケーションデータの送信を可能にするものです。

今年は方針が固まった年であり、WebTransportは over HTTP/3でまず標準化することと、フォールバック先としてover HTTP/2の標準化を行うことが決まりました。

また、WebSocketではHTTP/3対応した仕様の標準化作業が進められています。

書いた記事はここらへん

WebTransport over HTTP/2は最初の仕様とは異なり、最新版ではlayered designという形で再設計されております。

また、ブラウザへのマルチキャスト配信についてW3CのMulticastCGで議論されておりますが、そこでもWebTransportを使用できないかという議論が進んでいます。

OHTTP, Masque

OHTTPもMasqueもそれぞれ全く違う技術ですが、合わせて紹介します

OHTTP(Oblivious HTTP)は、ユーザのIPを秘匿する通信方法の標準化を行っています。AppleのPrivate Relayなどの取り組みを行っている方々も興味をもっているようです。書いた記事はここらへん

Masqueは、HTTP/3上UDPパケットやIPパケットをトンネリングする仕組みを標準化しています。それぞれWGアイテムとして標準化が勧めラ得ています。書いた記事はここらへん

なお、CONNECTメソッドを使用していましたが、最新仕様ではWebSocket over HTTP/2と同様に拡張CONNECTメソッドを使う形で標準化されています。CONNECT-IPは複数の提案仕様があったのですが、合わせるような形で新しい仕様が出されています。

Media over QUIC

IETFでは、QUIC上でどのようにメディアデータを送信するかというトピックがホットになっています。すでに、FacebookやTwitchではそれぞれ独自の手法で実利用が始まっているようです。とはいえ、注目は浴びているものの、標準化のためにユースケース別に要件を整理している段階になります。

主なユースケースは次のとおりです。

  • 配信者からのアップロード
  • 視聴者のダウンロード
  • P2Pによる通信

FacebookはRUSHというプロトコルを、TwitchはWarpという仕組みを利用しているようです。Warpは提案仕様を提出する準備ができているようですが、まだ出てきておりません。その他SRT over QUICや、RTP over QUICの議論も行われています。

RUSHについては記事を書いております

XX over QUIC

QUICがRFCとなり、既存のアプリケーションプロトコルでも、QUICを利用することが考えられています。それぞれのワーキンググループにより標準化が進められています。

  • BGP over QUIC
  • DNS over QUIC
  • SSH over QUIC
  • SMB over QUIC
  • RTP over QUIC
  • (NTP over QUIC)

TLS

TLS関連も引き続き標準化が進められています。ココでは、個人的に注目しているトピックを触れます。

TLS1.3の仕様も改訂作業が進められています。機能上は大きな差はありません。

あと大きなところで言うと、Encrypt SNI(ESNI)とも呼ばれていましたが、ClientHelloを暗号するECHという仕様も標準化が進められています。以前記事に書いております。


その他にDTLS 1.3や、余分なデータ量を削ったコンパクトなcTLSの標準化も進めれています。また、TLSを安全に使うためのガイドラインRFC7525の改訂作業も進められています。

その他

そのた

追えてないトピック

  • OAuth, Gnapまわり
  • Privacy Pass まわり
  • Privacy Interest Group まわり
  • 暗号系トピック