TCP/UDP 協議中的串流協定整理：RTP、RTSP、SRT、QUIC、RTMP 與 HLS

串流協定可以依據底層傳輸方式分成基於 UDP 和基於 TCP 兩大陣營：UDP 陣營（RTP、SRT、QUIC）追求低延遲，TCP 陣營（HLS、RTMP、MPEG-DASH）追求可靠與相容性。這篇文章逐一整理這些協定的特性、層次與應用場景，幫助你在架設串流服務時選對協定。

基於或可以使用 UDP 的協定有哪些？

RTP（Real-time Transport Protocol）

RTP（Real-time Transport Protocol，即時傳輸協定）是一個網絡協定，用於交付音頻和視頻等多媒體數據流。關鍵特性如下：

即時性：RTP 旨在實時交付數據，需要以最小的延遲和抖動來傳輸數據。
協議層次：RTP 通常運行在 UDP 之上，這樣可以降低延遲，但可能會導致一些封包丟失。在某些情況下，它也可以運行在 TCP 上。
封包結構：RTP 封包包括一個標頭和有效負載。標頭包括有關封包的資訊，如序列號、時間戳等，用於同步和順序排列。有效負載則包括媒體數據。
同步和排序：RTP 的頭部包含一個序列號，用於標識每個數據包。這使得接收端能夠檢測丟失的數據包並重新排序接收到的數據包。每個 RTP 數據包還包含一個時間戳，用於表示數據的取樣時刻，可以讓接收端同步不同類型的媒體流（例如音頻和視頻），並控制播放的速度和節奏。
與 RTCP 的組合使用：RTP 通常與 RTCP（RTP 控制協議）一同使用。RTCP 可以提供有關媒體傳輸質量的反饋，如丟包率、抖動等，這有助於調整和改進傳輸質量。
多播和單播：RTP 支持單播和多播傳輸，使其能夠服務於一對一通信和一對多通信的場景。
可擴展性：RTP 本身是一個相對簡單的協議，但它的設計允許通過擴展標頭和其他機制來添加新功能。
安全性：RTP 可以與 SRTP（安全 RTP）結合使用，以提供加密和數據完整性保護。

QRTP 和 WebRTC 有什麼不同？

RTP 和 WebRTC 是兩個密切相關但有所不同的技術：

定義和目的

RTP：是一個協議，用於實時傳輸多媒體數據，例如音頻和視頻流。它可以運行在各種應用和平台上。
WebRTC：是一個開放的框架，允許 Web 瀏覽器進行即時通信（RTC）。它包括一組協議和 API，用於在 Web 瀏覽器之間建立 P2P 連接。

組件和協議

RTP：是實時數據傳輸的核心協議之一，通常與 RTCP 一起使用。
WebRTC：使用了多個協議和技術，其中 RTP 就是其中之一，用於媒體數據的實時傳輸。WebRTC 還使用了其他協議，如 STUN/TURN/ICE（用於 NAT 穿透和對等發現）和 DTLS/SRTP（用於安全性）。

應用範圍

RTP：不限於 Web，可用於各種音頻和視頻通信應用。
WebRTC：主要用於 Web 應用，允許瀏覽器進行視頻和音頻通信。

傳輸層

RTP：通常運行在 UDP 上，也可以在 TCP 上。但 RTP 在 TCP 上運行時，可能會有一些效能方面的考量：RTP 自身具有序列號，用於檢測丟失的數據包並重新排序，與 TCP 的可靠傳輸機制重疊；另外 TCP 的可靠傳輸需要確認（ACK）機制，可能會增加傳輸的延遲。
WebRTC：使用 RTP 作為其媒體數據的傳輸協議，並使用 UDP 作為傳輸層協議。

在 WebRTC 應用中，你可能需要使用 WebSocket 作為信令通道，以此幫助建立和協調 P2P 連接。在這種情況下，WebSocket 用於傳送元數據（例如 SDP 描述和 ICE 結果），而 WebRTC 用於傳送實時語音、視頻和數據。

RTSP（Real Time Streaming Protocol）

RTMP 和 RTSP 都是使用 TCP 進行控制信令傳輸，但它們在傳輸媒體數據的方式上有所不同。RTMP 使用 TCP 進行媒體數據的傳輸，而 RTSP 使用 RTP/RTCP 在 UDP 上進行媒體數據的傳輸。RTSP 允許客戶端通過建立和控制媒體流會話來請求和傳輸實時媒體數據。

RTSP 的特點和功能：

實時性：RTSP 主要用於實時傳輸音頻和視頻等實時媒體數據，能夠提供較低的傳輸延遲，適用於實時的音視頻通訊。
客戶端/服務器模型：客戶端通過發送請求來控制服務器上的媒體流，並獲取媒體數據。
控制功能：客戶端可以發送請求來控制媒體流的播放、暫停、快進、倒退等操作。
媒體描述：客戶端可以通過請求獲取媒體流的描述信息，如編解碼器信息、媒體流格式等。
使用 RTP/RTCP：RTSP 常與 RTP 和 RTCP 結合使用，以在網絡上傳輸實時媒體數據。

RTSP 在視頻監控、視頻會議、流媒體直播等場景中得到廣泛應用。它為實時媒體數據的傳輸提供了一種靈活、高效的通信機制。

SRT（Secure Reliable Transport）

SRT 是一種基於 UDP 的開源傳輸協定，由 Haivision 公司發起並由 SRT 聯盟持續開發。它的主要目的是優化在公共網路（如互聯網）上進行高品質視訊串流的性能。

SRT 旨在解決在廣播等高品質視訊串流場景下，對於低延遲、丟包率低的傳輸要求。它在 UDP 之上實現了數據包重傳機制，並且加入了 AES 加密，以確保傳輸的安全性。此外，SRT 還提供了一個預測網路傳輸性能的機制（稱為「SRT 預測模型」），該模型可動態調整傳輸參數，以優化傳輸性能並減少延遲。

因此，SRT 協定將 UDP 的低延遲特性與 TCP 的可靠傳輸特性相結合，在公共網路上提供一種安全、可靠、低延遲的視訊傳輸解決方案，廣泛應用於廣播、遠程生產和 OTT 串流等領域。

QUIC（Quick UDP Internet Connections）

QUIC 是一種實驗性的傳輸層協議，旨在優化網絡連接性能並提高網絡傳輸的安全性。QUIC 主要依賴於 UDP 而非傳統的 TCP，這使得 QUIC 能夠降低網絡延遲、提高連接速度，並在保持安全性的同時減少握手次數。

要使用 QUIC，需要遵循以下幾個步驟：

確保瀏覽器或客戶端支持 QUIC：許多現代瀏覽器（如 Google Chrome 和 Mozilla Firefox）已默認啟用 QUIC。使用其他瀏覽器時，請查看其文檔確認是否支持。
使用支持 QUIC 的服務器：可以選擇支持 QUIC 的雲服務商，如 Google 雲平台，或者自行搭建支持 QUIC 的服務器，例如使用 Caddy 或 nginx。
配置服務器：對於 Caddy 和 nginx 等服務器軟件，可以參考相應的文檔來配置 QUIC 支持，並提供相應的加密證書。
測試 QUIC 連接：可以使用瀏覽器的開發者工具檢查網絡連接是否成功地使用了 QUIC 協議。
監控和優化：使用各種網絡分析工具來評估 QUIC 連接的表現，並根據結果優化服務器配置。

MPEG-DASH（Dynamic Adaptive Streaming over HTTP）

在使用 HTTP-TS 進行傳輸時，需要對數據進行分片，以提高傳輸效率和穩定性。可以使用各種分片技術，例如 MPEG-DASH 的架構技術、HLS 的 M3U8 文件等。雖然名稱中包含 "HTTP"，但 MPEG-DASH 可以在任何數據傳輸協議上運行，包括 UDP。

MPEG-DASH 通常使用 HTTP 協議，因此它可以通過標準的 HTTP 端口 80 進行傳輸，HTTPS 則是端口 443。這樣的設計使得 MPEG-DASH 能夠更容易通過防火牆和代理伺服器，並在現有的 Web 基礎設施上部署，因為它使用的是 Web 通信的標準端口和協議。這種基於 HTTP 的流媒體傳輸方式還有其他好處，例如緩存和兼容性，許多現有的 HTTP 伺服器和網絡設備已經能夠支持 MPEG-DASH，無需特殊配置或升級。

MPEG-DASH 是一種自適應比特率流媒體技術，允許高品質的流媒體通過 HTTP 進行交付，從不同的比特率和質量的媒體文件中進行選擇。因此，可以將其視為一種基於 HTTP 的分片技術，而非一個獨立的傳輸協議。

這種自適應技術的核心是將媒體內容分成多個小的段（或稱分片），然後通過 HTTP 傳輸。客戶端（例如視頻播放器）可以根據網絡條件和設備能力動態選擇不同質量和比特率的段進行播放。這使得 MPEG-DASH 可以在各種網絡條件下提供更好的視頻觀看體驗，適應網絡帶寬的變化，並提供流暢的播放。

RTMP（Real-Time Messaging Protocol）

RTMP 和 RTSP 都是基於 TCP 的應用層協議，主要使用 TCP 協議進行數據傳輸，但 RTMP 也可以使用 UDP。

RTMP 是一種用於實時數據傳輸的協議，主要用於音頻、視頻等媒體數據的傳輸。它使用 TCP 連接來傳輸數據，因為 TCP 提供了可靠的數據傳輸機制，適合實時數據的傳輸。

RTSP 則用於控制媒體流的傳輸和播放。它使用 TCP 連接來發送控制命令和接收媒體描述信息等控制數據，以確保控制信令的可靠傳輸；而媒體數據本身通常使用 RTP 和 RTCP 協議在 UDP 上進行傳輸，因為 UDP 具有較低的傳輸延遲，更適合實時媒體數據的傳輸。

那麼，同樣的數據，如果 RTSP 設計於 UDP 傳輸，有順序與可靠的檢查動作，而 RTMP 沒有，為什麼會這樣？

RTSP 是一個控制協議，主要用於控制媒體流的傳輸和播放。它使用 TCP 發送控制命令，媒體數據則由 RTP/RTCP 在 UDP 上傳輸。RTP 負責傳輸媒體數據，並提供時序、序列號等信息來保證數據順序和實時性；RTCP 則用於傳輸控制信息，例如檢查丟包率並做出相應的調整，以保證媒體數據的傳輸質量。
RTMP 是一種用於實時數據傳輸的協議，使用 TCP 連接來傳輸數據，保證數據的可靠性。RTMP 協議本身並沒有專門設計用於檢查丟包率和調整傳輸速率的機制，這些功能通常需要在應用層實現。

綜上所述，RTSP 主要用於控制媒體流的傳輸和播放，使用 RTP/RTCP 在 UDP 上進行媒體數據傳輸，並帶有丟包檢測；而 RTMP 則主要用於傳輸媒體數據，使用 TCP 進行數據傳輸，對於丟包率和傳輸速率的控制通常需要應用層實現。

基於 TCP 的串流協定有哪些？

HTTP Live Streaming (HLS)：由 Apple Inc. 提出的基於 HTTP 的串流協議，被廣泛使用在各種串流場景中。它將串流內容分割成一系列小型的基於 HTTP 的文件來傳遞給客戶端。
MPEG-DASH：一種領先的自適應比特率串流技術，使高品質的串流媒體成為可能，通過 HTTP 傳輸。
RTSP：雖然 RTSP 本身是一種控制協議，用於控制串流媒體服務器，但實際上，它的串流通常用 RTP 跨越 UDP 實現。然而，RTSP 也可以跨越 TCP 實現串流傳輸。
RTMP：由 Adobe Systems 為 Flash 播放器播放音訊、視訊和數據而開發的開放協議，主要使用 TCP。
Microsoft Smooth Streaming (MSS)：微軟開發的一種自適應串流協議，通過 HTTP 進行傳輸。
HTTP/2：HTTP 協議的第二個主要版本，它允許服務器將多個響應推送到客戶端，而無需客戶端明確的請求，這對於串流媒體來說是有利的。

常見問題

QRTP 為什麼通常跑在 UDP 而不是 TCP？

RTP 自身已有序列號與時間戳來處理排序與丟包偵測，若再疊加 TCP 的 ACK 重傳機制會造成功能重疊並增加延遲。UDP 低延遲的特性更適合即時音視頻傳輸。

QRTSP 和 RTMP 的最大差別是什麼？

RTSP 是控制協議，控制信令走 TCP，媒體數據由 RTP/RTCP 在 UDP 上傳輸並帶丟包反饋；RTMP 的控制與媒體數據都走 TCP，可靠但延遲較高。

QMPEG-DASH 是傳輸協定嗎？

嚴格來說不是。MPEG-DASH 是建立在 HTTP 之上的一種自適應比特率分片技術，雖然名稱含 HTTP，它也可以在其他傳輸協議上運行，包括 UDP。

QQUIC 解決了 TCP 的什麼問題？

QUIC 基於 UDP 實現，減少了握手次數，降低連線建立延遲，同時內建 TLS 加密，兼顧安全與傳輸性能。

參考資料

Haivision SRT 官方說明
本文其餘內容整理自個人實作筆記。

最後更新

2026-08-28（原文發布於 2022-08-02，本文保留原始筆記內容並補上 GEO 結構。）

關於作者 {#author}

Claire Chang ｜企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。

首次發布：2022-08-02