WebRTC / HLS / SRT / RTMP、結局どれを選ぶのか

「WebRTCとHLSは、どちらが優れていますか」。配信の相談で時々受ける質問ですが、実はこの問いには答えられません。両者は競合する選択肢ではなく、担当する区間も、解いている課題も違うからです。

プロトコルの比較表を眺めても選べないのは、表の縦軸が揃っていないことが原因です。この記事では、4つのプロトコルを「どの区間で」「何を優先して」使うものかで整理し直し、用途から逆算して選ぶための判断基準をまとめます。

比較の前に、「どの区間の話か」を分ける

配信の経路は、大きく2つの区間に分かれます。

• 上り（コントリビューション） — カメラのある現場から配信サーバーまで。送る映像は1本で、相手も1つです
• 下り（ディストリビューション） — 配信サーバーから視聴者まで。届ける先は数十から数万になります

上りの課題は「1対1で、確実に、できるだけ低遅延で送る」こと。下りの課題は「不特定多数へ、視聴環境の差を吸収しながら届ける」ことです。求められるものが違うので、使われるプロトコルも分かれます。

区間	主に使われるプロトコル
上り	RTMP(S)、SRT
下り	HLS、WebRTC

「RTMPとHLSのどちらを使うべきか」という問いが成立しないのは、これが理由です。実際の配信の多くは、上りRTMP＋下りHLSのように両方を組み合わせて動いています。例外はWebRTCで、これだけは上りから下りまでを一気通貫で担えます。

4つのプロトコルの性格

	RTMP(S)	HLS	SRT	WebRTC
主な区間	上り	下り	上り	上下一貫
土台	TCP	HTTP (TCP)	UDP	UDP
遅延の目安	数秒	数秒〜数十秒	1秒前後	1秒以内
強み	対応サービスの多さ	大規模配信の安定性	不安定な回線での上り	同時性・双方向

RTMP(S) — どこでも受けてくれる古参

もともとはFlashの動画再生のために作られた技術で、Flash自体は2020年末にサポートを終えました。しかしプロトコルとしては、配信サービスへのアップロード手段の事実上の標準として生き残っています。TCPベースなので受信確認と再送が効き、安定性は高いぶん、遅延は大きめです。

現在はTLSで暗号化されたRTMPSが標準で、通信も443番ポートに集約されています。旧来の1935番ポートは、企業ネットワークでは閉じられている前提で考えるべきです。

HLS — 大規模配信の標準

映像を数秒単位のセグメントに切り、HTTPで配る方式です。ただのHTTP配信なのでCDNにそのまま載り、4つの中では視聴者数の増加に最も強い方式です。反面、セグメント長×バッファ本数のぶんだけ遅延が積み上がります。標準的な設定で数十秒、低遅延版のLL-HLSでも2〜5秒程度です。LL-HLSはサーバー・CDN・プレイヤーのすべてが対応して初めて成立する点にも注意が要ります。

SRT — 不安定な回線に強い、上りの本命

UDPの低遅延性能に、損失したパケットだけを再送要求する仕組みとAES暗号化を組み合わせたプロトコルです。TCPのように全体を止めて待つことがないため、再送能力を持ちながら低遅延を保てます。モバイル回線や共用Wi-Fiのような不安定な上り回線で真価を発揮し、RTMPSに代わって対応サービスが増えつつあります。

WebRTC — 同時性が要るなら、実質これ一択

テレビ会議のために設計されたプロトコルで、セグメント化を行わず、届いた端から再生します。遅延は1秒以内。演者と視聴者がその場でやり取りできる唯一の選択肢です。引き換えに、視聴者数にほぼ比例するコストと、バッファが薄いことによる回線品質への敏感さを受け入れることになります。

用途から逆算する選定フロー

順番に3つ問うだけで、ほとんどの場合は絞り込めます。

問1: 演者と視聴者の「同時性」が要るか。 質疑応答、挙手、投票——その場のやり取りが演出に含まれるならWebRTC。一方向に届けるだけならHLS系です。

ここで注意したいのは、同時性の要否が「双方向かどうか」だけでは決まらないことです。たとえば株主総会で議決権行使をライブで締め切る場合、映像自体は片方向でも、遅延のぶんだけ議場と視聴者の時計がずれます。進行と連動する要素があるなら、片方向でも遅延要件は厳しくなります。

問2: 上りの回線は信用できるか。 閉域接続や安定した有線ならRTMPSで十分です。モバイル回線、会場の共用回線、遠隔地からの中継など、揺らぎが想定されるならSRTを選びます。

問3: 視聴者は何人で、予算はいくらか。 数千人以上へ同時性なしで届けるなら、コスト構造的にHLSがほぼ唯一の解になります。少人数での対話ならWebRTCのコストは問題になりません。悩ましいのは「数百人で、同時性も欲しい」という中間帯で、ここが予算との相談になります。

1つのイベントの中でも、要件は変わります。SynQNowが超低遅延（WebRTCベース）と追いかけ再生（HLSベース）の2つの配信モードをイベント単位で選べる作りにしているのは、この使い分けを配信のたびにゼロから設計し直さなくて済むようにするためです。

現場で効く4つの注意点

プロトコルの選定が正しくても、設定で転ぶことがあります。実務で引っかかりやすいのは次の4点です。

1. SRTのCaller / Listenerは、映像の流れる向きと無関係。 「送る側だからCaller」ではありません。接続を待つ側がListener、かけにいく側がCallerで、映像がどちらへ流れるかとは独立に決めます。ペアが噛み合わないと、そもそも接続が確立しません
2. FECはメーカーを揃える。 パケットロスを補完するFEC（誤り訂正）には標準規格がほぼ無く、メーカー独自実装が大半です。エンコーダーとデコーダーは同メーカー・同シリーズで揃えるのが無難です。また、FECを強くかけるほど遅延とデータ量が増え、その増加自体がロスの原因になり得ます
3. MTUの既定値を確認する。 LANの標準は1,500バイトですが、フレッツ系回線では1,454バイトが推奨されています。RTPやRTSPで伝送するエンコーダーにMTU設定がある場合は、経路に合わせて確認しておきます
4. 1935番ポートは閉じている前提で。 使わないポートを閉じるのはネットワーク管理の基本で、Flashのサポート終了後、1935番を開けておく理由はありません。RTMPSの443番なら通ることが多いですが、会場のネットワークを借りるなら事前に管理者へ確認するのが確実です

まとめ

• RTMP/SRTは上り、HLS/WebRTCは下り。区間が違うものを並列に比較しない
• 下りは同時性で決める。進行と連動する要素があるなら、片方向でも遅延要件は厳しくなる
• 上りは回線品質で決める。揺らぎが想定されるならSRT
• 現場の落とし穴はプロトコル選定そのものより設定にある。ハンドシェイクの組み方、FECの相性、MTU、ポートの開放状況は事前に潰しておく

遅延がなぜ生まれるのかという土台の話は、ライブ配信の遅延は、どこで何秒生まれているのかで分解しています。あわせて読むと、この記事の選定基準の根拠がつながるはずです。