Webページの表示は、この数年で確かに速くなりました。プロトコルの世代交代が静かに進み、主要なブラウザとCDNの間ではHTTP/3が当たり前に使われています。ところがライブ配信に目を移すと、現地の歓声より数十秒遅れて映像が届く光景は、あまり変わっていません。Webを速くした技術は、映像には効かないのでしょうか。
その世代交代の中心にいるのがQUICです。HTTP/3という名前の陰に隠れがちですが、変わったのはHTTPそのものではなく、その下で通信を運ぶ土台のほうでした。ここでは、QUICが何を作り直したのか、そして放送・配信の現場にどう関わってくるのかを整理します。
QUICプロトコルとは、TCPの待ち時間を作り直した設計
HTTP/2までのWeb通信は、TCPの上に成り立っていました。TCPは通信を始める前に3ウェイハンドシェイクで往復1回、暗号化のためのTLSハンドシェイクでさらに往復を重ねます。TLS 1.2なら合計3往復、TLS 1.3で短縮しても2往復です。東京とアメリカ西海岸の間の往復遅延はおよそ100ミリ秒ですから、最初の1バイトが届く前に数百ミリ秒が消える計算になります。データを何も運んでいないのに、です。
もう一つの問題がヘッドオブラインブロッキングです。HTTP/2は一本のTCP接続に複数のリクエストを多重化しましたが、TCPは届いた順序を厳密に守るプロトコルです。パケットが1つ失われると、再送が届くまで後続のデータ全体が止まります。本来は無関係なはずの別のリクエストまで、道連れにされてしまう。多重化の効果が、足元のTCPで打ち消されていたわけです。
QUICはこの二つを、TCPの改良ではなく作り直しで解決しました。土台に選んだのは、順序も到達も保証しないUDPです。その上にQUIC自身が再送や順序の管理を実装し、TLS 1.3による暗号化をハンドシェイクごと統合しました。接続確立と鍵交換が1往復で同時に終わり、一度接続した相手なら0-RTT、つまり往復を待たずにデータを送り始められます。ストリームの多重化もQUIC自身が受け持つため、あるストリームのパケット損失が他のストリームを止めることはありません。
接続の識別方法も変わりました。TCPがIPアドレスとポートの組で接続を識別するのに対し、QUICはコネクションIDという独自の札を使います。スマートフォンがWi-Fiからモバイル回線に切り替わってIPアドレスが変わっても、接続は切れずに続く。Googleが自社サービスの高速化のために始めたこの設計は、IETFでの標準化を経て2021年にRFC 9000となり、その上で動くHTTPがHTTP/3と名付けられました。
放送・配信の現場でQUICはどこに効くのか
では映像です。インターネットの動画配信の大半は、映像を数秒単位のファイルに刻んでHTTPで配る方式で動いています。 HLSやDASHによるセグメント配信 です。配信がHTTPの上に載っているのなら、HTTPが速くなれば配信も速くなるはずです。実際、HTTP/3の恩恵はまずここに現れます。電波状況の揺れる移動中の視聴でパケットが失われても、他のセグメントやプレイリストの取得が道連れで止まらない。接続の往復が減るぶん、再生開始も速くなります。
ただし、それで配信遅延が一桁縮むわけではありません。セグメント配信の遅延の主因は、セグメントをいくつか貯めてから再生を始めるという方式そのものにあるからです。土台を速くしても、上に載る方式が変わらなければ効果は限定的です。そこでIETFが動き始めました。
Media over QUIC、略してMoQです。IETFのワーキンググループで策定が進むこの仕組みは、映像をファイルに刻んでHTTPで取りに行くのではなく、QUICのストリームに載せてリレーサーバー経由で押し出すように配る設計です。セグメント方式より大幅に短い遅延と大規模配信の両立を狙い、素材の打ち上げから視聴者への配信までを一つのプロトコルで扱うことを目標に掲げています。標準化はまだ途上ですが、低遅延化をアプリケーションの工夫ではなくプロトコルの設計で解く方向として注目されています。
SRTとの関係も整理しておきましょう。取材先から局へ、局からクラウドへ映像を打ち上げるコントリビューションの領域では、 SRTプロトコルによる低遅延伝送 がすでに実務の道具になっています。QUICが主戦場とするのはその先、不特定多数の視聴者へ配る区間です。少数の拠点間はSRT、視聴者への大規模配信はHTTP/3やMoQ。競合ではなく、パイプラインの別の区間を受け持つ関係です。
導入のハードルはプロトコルの外にある
ここまで読むと今すぐ使いたくなりますが、QUICには設計の外側に敵がいます。UDPを通さないネットワークです。企業や学校のファイアウォールには、UDPの443番ポートを遮断する設定が今も残っています。経路上のミドルボックスが、見慣れないプロトコルを黙って落とす例もあります。QUICが中身の暗号化を徹底したのは、こうした中間装置がプロトコルの進化を妨げてきた反省からですが、遮断そのものは避けられません。
対応状況にも濃淡があります。主要なブラウザと大手CDNはHTTP/3に対応済みで、Webの世界では既定の選択肢になりつつあります。他方で、スマートテレビやセットトップボックスに組み込まれた再生環境は更新が遅く、HTTP/1.1やHTTP/2で止まっている機器が長く残ります。視聴環境を選べない放送・配信事業者にとって、ここは無視できない現実です。
だから実務の答えはフォールバック設計になります。HTTPにはAlt-Svcという仕組みがあり、まずTCPで接続してきた相手に「HTTP/3も使える」と伝え、次からQUICを試させます。試して駄目ならHTTP/2に戻る。QUICを前提にするのではなく、使えた視聴者から順に速くなる加点方式として組み込むのが現実的です。
結局のところ、配信の低遅延化は一つのプロトコルで解決する話ではありません。 局内の非圧縮IP伝送 、拠点間のコントリビューション、視聴者への配信。区間ごとに条件は違い、それぞれに向いた道具があります。QUICはそのうち視聴者にいちばん近い区間を作り直している最中で、どの範囲まで置き換わるかは、これからの数年で見えてくるはずです。
NAXAの取り組み
NAXAはテレビ業界向けに、日本語に特化した音声認識エンジンと、テロップ・字幕に対応した画像解析・OCRエンジンを保有し、放送・配信のシステム開発を手掛けています。配信経路が低遅延になるほど、字幕付与や映像解析といった処理に許される時間も短くなります。プロトコルの選定から処理系の設計までを一体で考える視点は、今後ますます重要になるはずです。
HTTP/3を含む配信基盤の構築や、低遅延パイプラインへのAI処理の組み込みに関心のある方は、お気軽にご相談ください。
