協定的選擇不是一個選項而是兩個：第一哩路（現場 → 雲端）與最後一哩路（雲端 → 觀眾）需求相反，必須分開選。第一哩路是一條流、要絕對可靠、頻寬可控；最後一哩路是一變百萬、要能快取、要容忍各種網路。把兩段混為一談是這個領域最常見的架構錯誤。
📖 學
一、第一哩路：RTMP、SRT、RIST
RTMP（Real-Time Messaging Protocol）——1990 年代末的 Flash 遺產，跑在 TCP 上。Flash 死了二十年，RTMP 卻活著，因為幾乎每個平台都收 RTMP，它成了事實上的最低共同標準。
它的問題也是結構性的：TCP 的重傳與擁塞控制是為了檔案傳輸設計的，遇到丟包時會降速並且無上限地等待重傳，於是延遲會累積而不是丟棄舊資料。跨國或行動網路推流時，RTMP 的表現可以非常糟。另外它原生只支援 H.264 ＋ AAC（增強版 E-RTMP 試圖擴充，但支援度參差）。
SRT（Secure Reliable Transport）——Haivision 開源，跑在 UDP 上，自己做選擇性重傳（ARQ）。
它的關鍵設計是延遲是一個明確設定的參數：你告訴它「我願意接受 200 ms 的緩衝」，它就在這個預算內盡可能重傳救回丟包，救不回來的就放棄。這把「延遲」從不可控的後果變成可控的輸入，這正是 RTMP 做不到的事。SRT 另有 AES 加密與三種連線模式（caller／listener／rendezvous），rendezvous 讓兩端都在 NAT 後面也能連上。
RIST（Reliable Internet Stream Transport）——VSF（Video Services Forum）標準化，定位與 SRT 幾乎相同，差別在治理模式（開放標準 vs 單一廠商主導的開源）與一些工程細節：RIST 的 ARQ 只用 NACK，SRT 同時用 NACK 與 ACK；在高丟包率的窄頻鏈路上，RIST 的重傳頻寬控制通常較保守。
實務結論：公網推流預設選 SRT，理由是生態系明顯較大、整合較快、工具鏈成熟（OBS、FFmpeg、多數雲端服務都原生支援）。RIST 在廣電圈與要求開放標準、多廠商互通的場合較有優勢。兩者都遠優於 RTMP，而繼續用 RTMP 的唯一好理由是「目標平台只收這個」。
二、最後一哩路：HTTP 分片型（HLS／DASH）
核心機制：把連續的流切成一段段檔案（segment），搭配一個描述清單（HLS 的 .m3u8、DASH 的 .mpd），播放器反覆下載清單、看到新分片就抓下來播。
這個設計的全部價值在於「它只是 HTTP」：可以用任何 CDN 快取、穿透任何防火牆、水平擴展到任意規模，一個分片被一百萬人下載跟被一個人下載對源站的成本相同。這是為什麼全世界的大規模直播都跑在這套上。
代價是延遲。傳統 HLS 的延遲來源是乘法關係：
延遲 ≈ 分片長度 × 播放器緩衝分片數 + 其他
例：6 秒分片 × 3 個緩衝 = 18 秒起跳
HLS 與 DASH 的差別比多數人想的小。 兩者的機制幾乎相同，差在清單格式與生態：HLS 是 Apple 的，iOS／Safari 原生支援（且 Apple 平台上幾乎強制）；DASH 是 MPEG 標準，Android／智慧電視／歐洲廣電較常見。2026 年的常見做法是兩者都出，但底層分片共用——這就是 CMAF。
三、CMAF：一套分片餵兩種清單
CMAF（Common Media Application Format） 的核心主張是：HLS 與 DASH 的差別只在清單，分片本身可以用同一種容器（fMP4）。於是你打包一次、存一份分片、產出兩個清單。
好處是直接的：儲存減半、CDN 快取命中率提高、轉碼成本不變。而且在加密層面，CMAF ＋ cbcs 加密模式讓同一份分片可以同時被 Widevine、PlayReady、FairPlay 解密——這在 CMAF 之前是不可能的，過去必須為 FairPlay 單獨打包一份。這一點對 內容保護 的成本影響極大。
四、LL-HLS：在分片架構裡擠出低延遲
LL-HLS（Low-Latency HLS） 的做法是把分片再切成 partial segment（part），典型 200–500 ms 一個，並讓播放器在 part 產出的同時就能拿到。它用了幾個機制：
- Partial segments：不必等整個 6 秒分片編完才能發。
- Blocking playlist reload：播放器請求「下一個版本的清單」，伺服器壓住這個請求不回應，直到新 part 準備好才回——消除輪詢的空轉延遲。
- Preload hints：清單預告下一個 part 的 URL，播放器可以提前發出請求。
- Delta playlists：只回傳清單的增量，減少每次請求的大小。
這些加起來可以把 HLS 的延遲從 15–30 秒拉到個位數秒。
但它有前提，而且前提很容易被忽略：整條鏈路都要支援（編碼器要能產 part、打包器要能寫、CDN 要能處理 blocking request 而不是把它當成逾時、播放器要實作）。只換了播放器或只換了打包器，延遲不會變——這是「上了 LL-HLS 但延遲沒降」最常見的原因。
另一個被低估的後果是請求量暴增。分片從 6 秒變成 0.5 秒的 part，請求數變 12 倍。對一個十萬人的直播，這是每秒數十萬個請求量級，而每個請求如果都要做鑑權查詢，鑑權系統會先倒。這直接影響安全架構的設計，見 案例拆解 裡的容量模型。
五、WebRTC：唯一真正的次秒級方案
WebRTC 不走分片也不走 HTTP。它用 RTP over UDP 直接送封包，jitter buffer 以毫秒計，並且有一整套即時擁塞控制與碼率調適。
它的延遲是結構性地低——沒有任何 HTTP 分片型協定能達到次秒級，因為分片本身就必須先累積內容才能產出。WebRTC 跳過了這個累積。
代價同樣是結構性的：
不能用一般 HTTP CDN。 每一路都是獨立的有狀態連線，需要專門的媒體伺服器（SFU／MCU）轉發。規模化成本比 HTTP 分片高一個量級。
連線建立複雜。 ICE／STUN／TURN 的協商，在企業防火牆、對稱 NAT、UDP 被封鎖的網路下會失敗，必須回退到 TURN over TCP/TLS（而那會增加延遲與成本）。
瀏覽器差異大。 Safari／iOS、Android WebView 的行為與桌面 Chrome 不同，必須逐一驗證。
內容保護的做法完全不同。 WebRTC 的媒體加密是 DTLS-SRTP（傳輸層），與 HLS 的內容加密／DRM 是兩套互不相通的機制；OTT 的 A/B 浮水印作法依賴「分片」這個單位，WebRTC 沒有。這是 安全篇 反覆強調的一個斷層。
一個必須澄清的常見混淆：WebRTC 的標準媒體走 RTP（由 DTLS-SRTP 保護），而 Data Channel 走 SCTP over DTLS。把視訊塞進 Data Channel 是另一條實作路線（有些廠商這麼做），不能跟標準 RTP 媒體混為一談——它們的安全模型、擁塞控制與瀏覽器支援都不同。這一點在 RFC 8827（WebRTC 安全架構）裡有明確區分。
六、對照表
| 協定 | 位置 | 典型 glass-to-glass | 可用 HTTP CDN | 規模經濟 | 主要代價 |
|---|---|---|---|---|---|
| RTMP | 第一哩 | 2–5 秒 | 否 | — | TCP 行為差，codec 受限 |
| SRT | 第一哩 | 延遲可設定（典型 0.5–2 秒） | 否 | — | 需雙端支援 |
| RIST | 第一哩 | 同 SRT 量級 | 否 | — | 生態較小 |
| HLS／DASH | 最後一哩 | 10–30 秒 | 是 | 最佳 | 延遲高 |
| LL-HLS／LL-DASH | 最後一哩 | 2–6 秒 | 是（需支援） | 好 | 全鏈路都要支援；請求量暴增 |
| WebRTC | 最後一哩 | 0.2–0.5 秒 | 否 | 差 | 連線複雜、保護機制斷層 |
表中的延遲數字應該當成量級而非規格。 各家供應商報的數字差異很大、測法不一，而且「協定延遲」與「glass-to-glass」常被混用，見 主張 vs 可佐證。
七、混合架構：2026 年的常見解法
當你同時需要「少數人次秒級互動」與「多數人可規模化觀看」時，標準做法是兩條線路並行：
- WebRTC 給需要即時互動的那一小群（主播、連麥來賓、下注中的玩家）。
- LL-HLS 給大眾觀眾。
兩條線路共用同一個授權與撤銷控制面是這個架構的關鍵安全要求——否則攻擊者只要切換到保護較弱的那條線就繞過了所有控制。這正是使用者提供的方案文件裡「任何備用域名、低碼率、音軌或回退線路，都不能成為鑑權旁路」那條原則在講的事，詳見 案例拆解。
🧠 記
第一哩路與最後一哩路分開選：前者要可靠（SRT／RIST），後者要可快取（HLS／DASH）。
SRT 把延遲變成可設定的輸入，這是它勝過 RTMP 的根本理由。
CMAF 讓一套分片餵兩種清單，並讓 cbcs 加密同時服務三家 DRM。
LL-HLS 需要全鏈路支援，只換一端不會降延遲；而它讓請求量暴增十倍以上。
只有 WebRTC 能做到次秒級，代價是放棄 HTTP CDN 的規模經濟與既有的內容保護工具鏈。
混合架構必須共用同一個控制面，否則回退線路就是旁路。
✍️ 實踐
用 FFmpeg 實測 SRT 的延遲可控性，約 30 分鐘：
# 接收端（listener）：先起來等
ffmpeg -i "srt://0.0.0.0:9000?mode=listener&latency=200000" \
-c copy -f mpegts out.ts
# 推送端（caller）：latency 單位是微秒，200000 = 200ms
ffmpeg -re -i input.mp4 -c:v libx264 -tune zerolatency -c:a aac \
-f mpegts "srt://<接收端IP>:9000?mode=caller&latency=200000"然後把 latency 分別設成 20000（20 ms）、200000（200 ms）、1000000（1 秒），在有丟包的網路上各測一次（可以用 tc netem 人工加丟包）。觀察的重點不是延遲數字本身，是畫面在丟包時的行為差異：低 latency 會直接出現破圖，高 latency 會成功救回。這個練習會讓「延遲是用來買抗丟包能力的預算」這件事變成直覺。
🔗 延伸學習
- IETF RFC 8827 — WebRTC Security Architecture——標準原文，明確區分 RTP 媒體（DTLS-SRTP）與 Data Channel（SCTP over DTLS）的安全模型。要跟廠商釐清「你們的 WebRTC 是哪一種」時，這是依據。
- OBS Project — Streaming With SRT or RIST Protocols——實際可操作的 URL 格式與模式設定。
- Elecard — RIST and SRT overview: what to choose and why——兩者的工程差異比較（ARQ 機制、重傳頻寬行為），比多數行銷文具體。