RTP 與 RTCP 協議詳解

1. 流媒體

1.1 概念

流媒體技術是網絡與多媒體技術發展到一定階段的產物。術語「流媒體」既可指網上傳輸連續時基媒體的流式技術，也可指使用流式技術的連續時基媒體本身。網上傳輸音視頻主要有兩種方式：下載與流式傳輸。下載方式需先下載整個媒體檔案才能播放，受頻寬限制延遲大。流式傳輸關鍵技術是流式傳輸：先對多媒體預處理（降低質量、高效壓縮），再用緩存系統保證數據連續正確傳輸。用戶無需等待整個檔案下載完，只需幾秒到幾十秒啟動延時即可播放，剩餘部分在後台繼續下載。相比純下載，邊下載邊播放大幅縮短啟動延時，降低系統緩存需求。另一好處是使傳輸事先不知或無法知曉大小的媒體數據（如網上直播、視頻會議）成為可能。

目前 Internet 上常用流式視頻格式主要有三種：RealNetworks 的 RealMedia、Apple 的 QuickTime、Microsoft 的 Advanced Streaming Format (ASF)。

1.2 支援流媒體的協議

多媒體應用顯著特點是數據量大、許多應用對實時性要求高。傳統 TCP 協議面向連接，其重傳與擁塞控制機制不適用於實時多媒體傳輸。RTP 是應用層傳輸協議，不提供傳輸可靠性保證與流量擁塞控制，位於 UDP 之上。UDP 雖不如 TCP 可靠，無法保證實時業務服務質量，需 RTCP 實時監控數據傳輸與服務質量。但 UDP 傳輸時延低於 TCP，能與音視頻良好配合。實際應用中，RTP/RTCP/UDP 用於音視頻媒體，TCP 用於數據與控制信令傳輸。支援流媒體傳輸的協議主要有 RTP、RTCP、RTSP 等。流媒體協議棧如圖 1 所示。

圖 1. 流媒體協議棧

2. 實時傳輸協議 RTP

RTP 針對 Internet 多媒體數據流，由 IETF 作為 RFC1889 發布。RTP 定義為在一對一或一對多傳輸情況下工作，目的是提供時間資訊與實現流同步。典型應用建立在 UDP 上，也可在 TCP 或 ATM 等協議上工作。RTP 僅保證實時數據傳輸，不提供按順序傳送數據包的可靠機制，無流量控制或擁塞控制，依靠 RTCP 提供這些服務。

2.1 RTP 工作機制

威脅多媒體數據傳輸的尖銳問題是不可預測的數據到達時間。流媒體傳輸需數據適時到達用以播放回放。RTP 協議提供時間標籤、序列號等結構控制適時數據流放。在流概念中「時間標籤」是最重要資訊。發送端依即時採樣在數據包隱蔽設置時間標籤。接收端收到數據包後，依時間標籤按正確速率恢復原始適時數據。不同媒體格式調時屬性不同。但 RTP 本身不負責同步，為簡化傳輸層處理提高效率，將部分傳輸層功能（如流量控制）上移到應用層完成。同步屬於應用層協議完成。RTP 無傳輸層協議完整功能，不提供機制保證實時傳輸，不支援資源預留，不保證服務質量。RTP 報文甚至不包括長度與報文邊界描述。同時 RTP 數據報文與控制報文使用相鄰不同端口，大大提高協議靈活性與處理簡單性。

RTP 與 UDP 共同完成傳輸層功能。UDP 傳輸數據包，不管時間順序。RTP 協議數據單元用 UDP 分組承載。承載 RTP 數據包時，有時一幀數據被分割成幾個包具相同時間標籤，則時間標籤非必須。UDP 多路復用讓 RTP 利用顯式多點投遞，滿足多媒體會話需求。RTP 雖是傳輸層協議但未作為 OSI 體系結構單獨一層實現，通常根據具體應用提供服務，僅提供協議框架，開發者可按應用具體要求充分擴展。

2.2 RTP 協議報文結構

RTP 頭格式如圖 2 所示：

前 12 個八位元組出現在每個 RTP 包中，CSRC 標識列表僅在混合器插入時出現。各段含義：

1. 版本 (V)：2 位，標識 RTP 版本。
2. 填充標識 (P)：1 位，若設置，包尾包含附加填充字，不屬有效載荷。最後一個八位元組包含應忽略的八位元組計數。某些加密演算法需固定大小填充字，或為在底層協議數據單元攜帶多個 RTP 包。
3. 擴展 (X)：1 位，若設置，固定頭後跟一個頭擴展。
4. CSRC 計數 (CC)：4 位，包含緊接固定頭後 CSRC 標識符個數。
5. 標記 (M)：1 位，解釋由設置定義，允許重要事件在包流中標記。設置可定義其他標示位或通過改變位數量指定無標記位。
6. 載荷類型 (PT)：7 位，記錄後面資料使用哪種 Codec，接收端找出相應解碼器解碼。常用類型見表。
7. 序列號：16 位，隨每個 RTP 數據包增加 1，接收者用來探測包損失。初值隨機，使加密文本攻擊更難。
8. 時間戳：32 位，反映 RTP 數據包中第一個八位元組的採樣時刻，必須從單調線性增加的時鐘導出，允許同步與抖動計算。讓接收端知道在正確時間播放資料。
9. SSRC：32 位，標識同步源。非隨機選擇，目的使同一 RTP 包連接中無兩個同步源有相同 SSRC。雖多源選同一標識概率極低，所有 RTP 實現必須探測並解決衝突。源改變傳輸地址時也必須選新 SSRC 避免環路源。
10. CSRC 列表：0 到 15 項，每項 32 位。表示包內對載荷起作用的源。標識數量由 CC 段給出。超過 15 個作用源僅標識 15 個。CSRC 標識由混合器插入，採用作用源的 SSRC 標識。

若只有序列號，無法完整按順序播放 data，因 data 中間可能無資料，只靠序列號會出錯，需搭配時間戳讓它知道在哪個時間正確播放，才能播放正確無誤資訊。

3. 實時傳輸控制協議 RTCP

RTCP 負責管理傳輸質量，在當前應用進程間交換控制資訊。RTP 會話期間，各參與者週期性傳送 RTCP 包，含已發送數據包數量、丟失數據包數量等統計資料。服務器可利用這些資訊動態改變傳輸速率，甚至改變有效載荷類型。RTP 與 RTCP 配合使用，能以有效反饋與最小開銷使傳輸效率最佳化，特別適合傳送網上實時數據。

3.1 RTCP 工作機制

應用程序啟動 RTP 會話時使用兩個端口：一個給 RTP，一個給 RTCP。RTP 本身無可靠傳送機制、無流量控制或擁塞控制，依靠 RTCP 提供。RTP 會話間週期發送 RTCP 包以監聽服務質量、交換會話用戶資訊。RTCP 包含統計資料，服務器可動態改變傳輸速率或載荷類型。RTP/RTCP 配合使傳輸效率最佳化。根據用戶間數據傳輸反饋資訊可制定流量控制策略，會話用戶資訊交互可制定會話控制策略。

3.2 RTCP 數據報類型

• SR (Sender Report)：發送端報告，發送端指發出 RTP 數據報的應用程序或終端，發送端同時也可以是接收端。
• RR (Receiver Report)：接收端報告，指僅接收不發送 RTP 數據報的應用程序或終端。
• SDES (Source Description)：源描述，作為會話成員相關標識資訊載體（用戶名、郵件地址、電話號碼等），也具向會話成員傳達會話控制資訊功能。
• BYE：通知離開，指示某個或幾個源不再有效，即通知其他成員自己將退出會話。
• APP：應用程序自定義，解決 RTCP 擴展性問題，為協議實現者提供極大靈活性。

4. 資源預訂協議 RSVP

音視頻數據流比傳統數據對網絡延時更敏感。要在網絡傳輸高質量音視頻，除頻寬要求外，還需更多條件。RSVP 是 Internet 資源預訂協議，使用 RSVP 預留部分網絡資源（即頻寬），能在一定程度上為流媒體傳輸提供 QoS。

本文出自「子 孑」博客，請務必保留出處 https://zhangjunhd.blog.51cto.com/113473/25481