HTTP over マルチキャストQUIC とは

2022/05/16 動きがあったため、記事を新しく書きました
asnokaze.hatenablog.com


Hypertext Transfer Protocol (HTTP) over multicast QUIC」で、マルチキャストのQUIC上でHTTP通信を行う仕様が提案されている。マルチキャストQUICは単方向通信であり、その上でサーバプッシュを行う感じである。



現状QUICの仕様ではIPマルチキャストの利用は想定されていない(もちろん双方向通信)ため、この仕様ではQUICのトランスポートレイヤ、HTTPレイヤを利用しつつも、IPマルチキャストを利用できるように一部の変更(制限)を加えている。


BBC Researchの方が書かれているので、主に動画像配信での利用を考えているんだと思う。


ざっと仕様を読んだのでかいつまんで特徴を紹介する。


また、QUICの仕様はまだ変わる可能性があり、本仕様はそれに併せて変わる旨注意書きがつけられている。

HTTP over マルチキャストQUIC

セッション

マルチキャストQUICでは、単方向通信になる。そのため、コネクションではなくセッションという用語を使用する(コネクションIDではなく、セッションID)。このセッションに参加者が参加する形になる。


セッションのステートは、個々のエンドポイント間で同期されるわけではないが、参加者(送信者も含む)の有無に関して「Idle」、「Half-established」、「Fully-established」、「Finished」の4つの状態が存在する。


Idle状態から開始され、参加者がいなくなるか、明示的に通信を終了することも出来ます。


エンドポイントは他のセッションにマイグレーションすることも出来ます。

セッションの広告

Alt-Svcを用いて、セッションの広告を行います。マルチキャストQUICは単方向通信であるためCryptoハンドシェイクは使用せず、このAlt-SvcにセッションIDやセッションで使用する暗号スイート、暗号化キーが含まれます。受信者は、自身が暗号スイートに対応してるか判断して、セッションに参加するか決めます。また、この時にトランスポートの鍵が提供されます。


プロトコルの識別子は、hqmを使用します。

   Alt-Svc:
       hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1;
       session-id=10; session-idle-timeout=60;
       max-concurrent-resources=10; peak-flow-rate=10000;
       cipher-suite=1301; key=4adf1eab9c2a37fd

source-addressは、Source-specific multicast (SSM) に使用される。


また、Alt-Svcはユニキャストの代替サービスも広報出来ます(後述)。

フローコントロール

QUICトランスポートでは、クレジットベースのフロー制御を行っています。しかし、単方向通信では実現不可能であるため、peak-flow-rateというパラメータを使用します。これは、1秒あたりのビット数で表され、Alt-Svcパラメータで通知されます。

送信者はこのレートを超えないようにしなければなりません。しかし、受信者はそれを超えても切断しなくてもよいです。

パケットロスの回復

マルチキャストQUICは単方向通信であるため、ACKフレームは送信者・受信者双方で使用が禁止されます。同様にSTOP_WAITINGフレームも送信できません。


仕様の中では、損失したデータの回復する方法を2つ示しています。

  • Forward Error Correctionを使用する方法。現在IETFの仕様ではFECはオプショナル仕様で、将来仕様策定される予定になっています。
  • ユニキャストで復元する方法。失われたパケットがFECで回復出来ない場合、もしくは閾値を超えて損失した場合は、ユニキャストを用いてデータを取りに行きます。
HTTP2まわり

マルチキャストQUICはHTTP/2のサーバプッシュに依存します。そのため、受信者はサーバプッシュを受け付けられる必要があります。また、マルチキャストQUICは単方向のため、受信者からHEADERSフレームを送ることはありません、そのためサーバからのPUSH_PROMISEフレームの送信は予約されたストリームを参照します


同様に、単方向通信のためにHPACKの動的テーブルを同期するのは不可能です。そのため、動的テーブルは使用できません。


また、単方向通信であるためもちろん受信者からPriorityを指示することも出来ません。

アプリケーションレイヤセキュリティ

HTTPレイヤでコンテンツの完全性と、相手が本当に正しいこと(主に送信者が正しいこと)を確認する事が推奨されます。


RFC3230 Instance Digests in HTTP」を使用し完全性を、「Signing HTTP Messages
」を用いて真正性を担保することを推奨しています。また、再送攻撃については、Dateヘッダを署名対象に含めるように推奨しているが、それ以上については仕様の範囲外としている。


そのほか機密性が必要があれば別途アプリケーションレイヤでの暗号化をするように推奨しているが、鍵の配送については規定していない。

そのほか

Security and Privacy Considerationsとして、セキュリティ(なりすまし、再送攻撃)・プライバシー(広域盗聴など)、DoS攻撃について手厚く書かれています。

たとえば、送信者のなりすましは可能であるため、上記で述べているようなアプリケーションレイヤの対策が推奨されている。