【ITニュース解説】EP04: Transport showdown — RTMP / SRT / WHIP

ライブストリーミングの技術は、私たちの生活においてますます重要になっている。特に、配信元から視聴者まで、いかに映像を「遅延なく」「安定して」届けるかは、システムエンジニアが直面する大きな課題の一つだ。この解説では、ライブストリーミングにおける映像データ転送の仕組みと、それを支える主要なプロトコルであるRTMP、SRT、WHIPについて、それぞれの特徴とネットワークの不安定さにどう対応するかに焦点を当てて説明する。

まず、ライブストリーミングの黎明期から使われてきたプロトコルにRTMP（Real-Time Messaging Protocol）がある。RTMPは、インターネット通信の基盤であるTCPというプロトコル上で動作する。TCPは、データを確実に相手に届けるための仕組みを備えており、パケット（データの小包）が途中で失われた場合でも自動的に再送を要求し、正しい順序でデータを届けようとする。RTMPはこのTCPの信頼性を活用することで、プロトコル自身が再送処理を実装する手間を省いていた。これは、ネットワークが比較的安定していた時代には非常に有効な設計だったと言える。しかし、TCPには「ヘッドオブラインブロッキング」という課題がある。これは、もし一つのパケットが途中で失われると、そのパケットが再送されて届くまで、それ以降に到着したすべてのパケットも処理を待たされてしまう現象だ。現代のモバイルネットワークや不安定なWi-Fi環境では、パケットロスが頻繁に発生しやすく、このヘッドオブラインブロッキングが致命的な遅延を引き起こす原因となる。かつてRTMPはAdobe Flash Playerとセットで広く使われていたが、Flashのサポート終了に伴い、現在では一部の古い配信機器の「インジェスト」（配信元からの取り込み）に利用される程度で、その役割は終わりに近づいている。

次に、現代の不安定なネットワーク環境に特化して設計されたプロトコルがSRT（Secure Reliable Transport）である。SRTはTCPとは異なり、UDPというプロトコルを基盤としている。UDPは、データを高速に送ることを優先し、パケットが失われても再送要求はしないのが特徴だが、SRTはこのUDPに独自の信頼性確保の仕組みを追加している。主な仕組みは三つある。一つ目は「ARQ（Automatic Repeat reQuest）」だ。受信側はパケットの順番を示す番号で欠落を検知すると、送信側に再送を要求し、送信側は期限内にデータを再送する。これにより、失われたパケットを回復できる。二つ目は「TSBPD（Timestamp-Based Packet Delivery）」だ。これは、各パケットに付与されたタイムスタンプと、あらかじめ設定された「遅延」パラメーターに基づいて、パケットの配送タイミングを調整する仕組みだ。これにより、ネットワークの揺らぎ（ジッター、通信の遅延時間のばらつき）を吸収し、送られたときのタイミングを再現してデータを届けることができる。三つ目は「TLPKTDROP（Too-Late Packet Drop）」だ。これは、有効にした場合、設定された時間内に配送が間に合わない「古くなった」パケットは、潔く破棄することで、無駄な再送を避け、全体の遅延が増大するのを防ぐ仕組みである。SRTでは、設定する「遅延」パラメーターによって、再送とジッター吸収のための時間的予算を調整できる。この予算が大きいほど回復の可能性は高まるが、遅延も大きくなる。SRTは、AESによるペイロード暗号化も可能で、不安定なアップロード回線でも高品質な映像を届けられるように、遅延と堅牢性のバランスを取ることを目的として設計されている。

そして、Web技術をベースにした現代的なプロトコルがWHIP（WebRTC-HTTP Ingestion Protocol）である。WHIPは、それ自体が新しい転送プロトコルというよりは、既存のWebRTC（Web Real-Time Communication）という技術を、ライブストリーミングの「インジェスト」用途で標準化し、使いやすくするための「シグナリング手順」を定めたものだ。メディアの転送自体はWebRTCの仕組みを利用する。WebRTCは、以下の主要な要素で構成されている。まず、「ICE（Interactive Connectivity Establishment）」は、配信元とサーバーが互いのネットワークアドレスを見つけ出し、直接通信するための最適な経路を確立する。次に、「DTLS-SRTP（Datagram Transport Layer Security - Secure Real-time Transport Protocol）」は、メディアデータを暗号化し、通信の機密性と完全性を保護する。そして、「RTP（Real-time Transport Protocol）」は、実際のメディアデータ（映像や音声）を運ぶ役割を担う。RTPでは、パケットロスが発生した場合に「NACK（Negative ACKnowledgment）」（受信側からの再送要求）や、オプションでFEC（Forward Error Correction、事前に冗長なデータを付加して損失を回復する）といった技術を使って損失を処理する。また、「輻輳制御」（Congestion Control）という仕組みにより、ネットワークの帯域状況に合わせて送信するビットレート（データ量）を自動的に調整し、ネットワークの混雑を緩和する。SRTのTSBPDのように、厳密な時間ベースの配送スケジュールはないが、RTPの実装は通常、パケットの到着順序を整えたり、NACKの要求を生成したりするために、受信したパケットの履歴（ジッターバッファと呼ばれる一時的な貯蔵庫）を保持している。WHIPは、Webブラウザの標準的なAPIを通じてネイティブにサポートされており、リアルタイムな配信と再生において主流のプロトコルとなっている。

これらの三つのプロトコルを比較すると、RTMPはレガシーであり、SRTは不安定なネットワークにおける高い堅牢性を重視し、WHIPは標準的なWeb技術と低遅延なリアルタイム通信に強みを持つことがわかる。このプロジェクトでは、RTMPは利用せず、SRTとWHIPの両方を「インジェスト」プロトコルとして採用している。これは、それぞれが異なる問題解決に適しているためだ。例えば、ネットワークが比較的安定している環境で、可能な限り低い遅延を実現したい場合はWHIPが適している。一方で、アップロード回線が不安定で、多少の遅延を許容してでも映像の品質と安定性を最優先したい場合はSRTが有利となる。

ただし、SRTとWebRTC（WHIPの基盤）では、損失処理や統計情報の収集方法が異なるため、単純にそれぞれの「パケットロス率」といった生の数値を比較することはできない。このプロジェクトでは、これらの異なるプロトコルから得られる情報を、内部で「Unrecoverable Loss Rate（ULR）」のような統一された指標に変換している。この統一された指標を用いることで、SRTとWHIPの両方に対して共通の品質劣化判断ロジック（デグレード状態マシン）を適用している。具体的には、このロジックは一定のサンプリング期間でULRが特定のしきい値（例えば0.8%）を超えた場合に、映像品質を「劣化」させる判断を下す。逆に、ULRが回復し、別のしきい値（例えば0.3%）を下回れば、品質を「回復」させる判断を行う。この品質劣化の対応は二段階で行われる。まず、エンコーディングのビットレートをリアルタイムで下げる。これは視聴者への影響が少ないため、比較的頻繁に実行できる。それでも問題が解決しない場合、最終手段として、配信される解像度（Simulcastレイヤー）を下げて、より低い品質の映像に切り替える。この解像度変更は、一時的な配信の中断を伴うため、ビットレート変更よりも慎重に、本当に必要な場合のみ適用される。

このように、ライブストリーミングにおけるプロトコル選択は、ネットワーク環境と求められる品質特性によって大きく異なる。RTMPは役割を終えつつあり、SRTとWHIPが現代のライブストリーミングを支える二大柱となっている。システムエンジニアは、それぞれのプロトコルの特性、特にパケットロスや遅延に対する処理メカニズムを深く理解し、それらを適切に組み合わせることで、ユーザーに最高のライブストリーミング体験を提供するための設計と運用を行う必要がある。このプロジェクトも、異なるプロトコルの強みを活かし、共通の品質管理ロジックで一元的に制御することで、多様なネットワーク環境に対応した堅牢で低遅延なライブストリーミングシステムの構築を目指しているのである。