Media over QUIC（MoQ）

なぜ「もう一つの配信方式」が要るのか

ライブメディア配信には長らく二つの極がありました。片方はWebRTCで、数十〜数百ミリ秒の超低遅延を実現しますが、/network/webrtc-ice-stun-turn/で見たようにICE/STUN/TURNによる接続確立やSFUの運用が重く、CDNのような単純なファンアウトで大規模化しにくい弱点があります。もう片方はLL-HLSやLL-DASHといったHTTP適応配信で、/network/cdn/のキャッシュ階層に乗せて数百万視聴者まで容易にスケールしますが、セグメント／チャンク単位の構造ゆえ遅延は良くても数秒に留まります。

横にスクロール

Media over QUIC（MoQ）は、この二極の間を埋めるためにIETFのmoq Working Groupが標準化を進めるライブメディア配信の枠組みです。狙いは、WebRTC並みとまではいかないが1秒を切る低遅延を、CDN的なrelay階層でHTTP配信並みにスケールさせながら、取り込み（ingest）と配信（distribution）を単一のスタックで扱うことにあります。

土台：QUIC と WebTransport

MoQの中核仕様はMedia over QUIC Transport（MOQT）で、これは生のQUIC接続、またはWebTransport（HTTP/3の上でQUICのストリーム／データグラムをアプリに開放する層）のどちらの上でも動きます。ブラウザからはWebTransport経由、サーバー間やネイティブアプリからは生QUIC、という使い分けが想定されています。

QUICを土台に選ぶ必然性は配信の性質から来ます。QUICはストリームごとに独立した順序保証を持ち、あるパケット損失が他ストリームを止めない（HoLブロッキング回避）。この内部構造は/network/quic-internals/で詳述したとおりで、独立に到着してよい映像フレーム群を別々のストリームに載せる設計と噛み合います。順序保証や再送が不要な部分はQUICデータグラムに載せることもでき、TCP上のHTTP配信では選べなかった粒度の制御が可能になります。

Track・Group・Object の三層モデル

MoQの表現力の核心はデータモデルにあります。配信内容を三つの入れ子で表します。

• Object: 最小の配信・キャッシュ単位。1つの映像フレームや音声フレーム、あるいはその断片に相当する不透明なバイト列で、Group内での連番（Object ID）を持つ。
• Group: Objectの集合で、単独で復号を開始できる境界として使う。映像ならGoP（IDRフレームで始まる一区切り）に対応させるのが典型で、Group単位で連番（Group ID）を持つ。
• Track: Groupの時系列。1本の映像や1本の音声といった「購読の単位」で、Track NamespaceとTrack Nameの組で識別する。

この階層が効くのは輻輳時です。relayやエンドは「どのObjectを、どの順で、どこまで送るか」をGroup境界とObject単位で判断できます。たとえば新しいGroupが来たら古いGroupの未送Objectを捨てて追いつく、といった遅延を守るための選択的破棄が、アプリ側のコーデック知識をrelayに持ち込まずに実現できます。

publish/subscribe とデータの流れ

MoQはpub/subモデルです。配信者（publisher）は自分が持つTrack NamespaceをrelayにANNOUNCE（告知）し、視聴者（subscriber）は欲しいTrackをSUBSCRIBE（購読）します。relayは購読要求を上流へ伝播させ、届いたObjectを購読者へファンアウトします。制御メッセージ（SUBSCRIBE、ANNOUNCE等）とObjectの実データが、同じQUIC接続上を流れます。

Objectをどう運ぶかは実装・仕様の版で選択肢がありますが、基本の考え方は「独立に消費してよい単位を別ストリームに分ける」ことです。Group単位でストリームを分ければ、あるGroupの損失回復が次のGroupの配信を止めません。各Objectやサブグループには送信優先度を付与でき、relayは輻輳時にQUICのストリーム優先度制御を使って重要な映像（例えば基準レイヤやキーフレーム）を先に通し、余裕がなければ低優先のObjectを落とせます。

relay によるファンアウトとスケール

大規模化の鍵はrelayツリーです。relayはObjectをキャッシュしつつ、同じTrackを購読する多数の下流へコピーを配ります。1つの上流Objectを受け取ってN個の下流へ複製する、という関係は/network/cdn/のエッジキャッシュと同型で、視聴者が増えても上流の負荷は購読の重複ぶんだけ増える構造にはなりません。

WebRTCのSFUと違い、relayはメディアをデコード・再エンコードしないため、CPUコストが軽く水平展開しやすいのが利点です。取り込み側も同じrelayに対してpublishするだけなので、配信と取り込みが同一の中継基盤・同一プロトコルに統一されます。これは、取り込みはRTMP、配信はHLS/CMAF、というように別プロトコルを繋ぎ合わせてきた従来のライブ配信パイプラインを一本化しうる点でインパクトがあります。

立ち位置：三方式の比較

まとめ

MoQは、QUIC／WebTransportというウェブ標準の土台に、Track・Group・Objectという配信専用のデータモデルとpub/subの制御を載せた枠組みです。映像をObject単位で扱い優先度を付けることで、relayはコーデックを知らないまま輻輳時に古いGroupや低優先Objectを選択的に落とし、遅延を守れます。relayツリーはCDNと同型にファンアウトしてスケールし、取り込みと配信を単一スタックへ統一します。狙う遅延はWebRTCとHTTP適応配信の中間で、両極の弱点を避けようとする設計思想が、この方式の存在理由そのものです。