一、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 接收包的情況
