5┃音視頻直播系統之 WebRTC 中的協議UDP、TCP、RTP、RTCP詳解

• 2022 年 5 月 14 日
• 筆記
• 萬人在線音視頻直播系統, 音視頻直播系統

一、UDP/TCP

• 如果讓你自己開發一套實時互動直播系統，在選擇網絡傳輸協議時，你會選擇使用UDP協議還是TCP協議

• 假如使用 TCP 會怎樣呢？在極端網絡情況下，TCP 為了傳輸的可靠性，將會進行反覆重發信息的操作

• 在 TCP 協議中，為了避免重傳次數過多，定時器的超時時間會按 2 的指數增長，也就是說，假設第一次設置的超時時間是 1 秒，那麼第二次就是 2 秒，第三次是 4 秒……第七次是 64 秒。如果第七次之後仍然超時，則斷開 TCP 連接，而對於這麼長時間的延遲，實時互動的直播系統是根本無法接受的

• 所以做在線直播系統時候一定要選擇 UDP 協議

二、RTP 協議

• 在實時互動直播系統傳輸音視頻數據流時，我們並不直接將音視頻數據流交給UDP 傳輸，而是先給音視頻數據加個 RTP 頭，然後再交給 UDP 進行傳輸

• 因為視頻數據在傳輸時，數據量太大，所以傳輸1幀可能需要幾十個包，而數據傳到接受端的時候，要將這幾十個包進行組裝，才能還原成完整的圖像

• 而RTP 協議就是為瞭然對接端組裝數據之後，順序不會亂而存在的，你想想，如果組裝的時候，順序亂了，組裝出來的圖像還是傳輸過來的圖像嗎

• RTP 協議非常簡單，這裡對RTP進行簡單的介紹

• sequence number：序號，用於記錄包的順序

• timestamp：時間戳，同一個幀的不同分片的時間戳是相同的。不同幀的時間戳是不同的

• PT：Payload Type，數據的負載類型。音頻流的 PT 值與視頻的 PT 值是不同的，通過它就可以知道這個包存放的是什麼類型的數據

• SSRC：共享媒體流的源，它是全局唯一的，不同的SSRC標識不同的共享源

• CC：CSRC的個數

• CSRC：共享源，一般用在混音或混屏上

• X：RTP擴展頭標記，如果該位置是1，說明此RTP包還有擴展頭

• M：表示MARK位，用來界定視頻幀邊界

• P：填充位

三、RTP案例

• 如果你在網絡上接收了一組下面的音視頻數據

• 假設 PT=80 是視頻數據，PT=100 是音頻數據

• 按照上面的規則，是不是就很容易組裝數據了

{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:14,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:14,ts:123456789,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:15,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:15,ts:123456789,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:16,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:16,ts:123456789,ssrc=2345}

四、RTCP 協議

• 在使用 RTP 包傳輸數據時，難免會發生丟包、亂序、抖動等問題

• 比如：網絡線路質量問題引起丟包率高、傳輸的數據超過了帶寬的負載引起的丟包問題等等

• 而在處理這些問題之前，WebRTC首先要讓各端都知道它們自己的網絡質量到底是怎樣的，這就是 RTCP 的作用

• RTCP 有兩個最重要的報文：RR（Reciever Report）和 SR(Sender Report)

• 通過這兩個報文的交換，各端就知道自己的網絡質量了

• 該報文協議如下圖，其中字段的含義：

• V=2：指報文的版本。

• P：表示填充位，如果該位置 1，則在 RTCP 報文的最後會有填充位元組

• RC：全稱 Report Count，指 RTCP 報文中接收報告的報文塊個數

• PT=200：Payload Type，也就是說 SR 的值為 200

• Header：部分用於標識該報文的類型，比如是 SR 還是 RR

• Sender info：部分用於指明作為發送方，到底發了多少包

• Report block：部分指明發送方作為接收方時，它從各個 SSRC 接收包的情況