[TOC] 參考：[https://zhuanlan.zhihu.com/p/94570212](https://zhuanlan.zhihu.com/p/94570212) 參考：[https://blog.csdn.net/moyebaobei1/article/details/86703258](https://blog.csdn.net/moyebaobei1/article/details/86703258) ## RTSP **RTSP(Real-Time Stream Protocol)協議** RTSP以客戶端方式工作，對流媒體提供播放、暫停、后退、前進等操作。該標準由IETF指定，對應的協議是RFC2326。 RTSP作為一個應用層協議，提供了一個可供擴展的框架，使得流媒體的受控和點播變得可能，它主要用來控制具有實時特性的數據的發送，但其本身并不用于傳送流媒體數據，而必須**依賴下層傳輸協議(如RTP/RTCP)所提供的服務來完成流媒體數據的傳送**。RTSP負責定義具體的控制信息、操作方法、狀態碼，以及描述與RTP之間的交互操作。RTSP媒體服務協議框架如下：  ## RTP 協議 我們現在已經決定好用UDP做實時語音。 我們以視頻為例，在視頻中，一個 I 幀的數據量是非常大的（假設要幾十 K）。而以太網的最大傳輸單元是多少呢？ 1.5K，所以要傳輸一個 I 幀需要幾十個UDP包。這幾十個包傳到對端后，還要重新組裝成 I 幀，這樣才能進行解碼還原出一幅幅的圖像。那么我必須要在包中，添加額外的標記才能夠完成組裝。這至少包括： * **序號**：用于標識傳輸包的序號，這樣就可以知道這個包是第幾個分片了。 * **起始標記**：記錄分幀的第一個 UDP 包。 * **結束標記**：記錄分幀的最后一個 UDP 包。 有了上面這幾個標識字段，我們就可以在發送端進行拆包，在接收端將視頻幀重新再組裝起來了。 其實，這樣的需求在很早之前就已經有了。因此就有了**RTP**協議。下面讓我們來詳細看一下 RTP 協議吧。一般情況下，在實時互動直播系統傳輸音視頻數據流時，我們并不直接將音視頻數據流交給 UDP 傳輸，而是**先給音視頻數據加個 RTP 頭，然后再交給 UDP 進行傳輸**。   知道了上面這些字段的含義后，下面我們還是來看一個具體的例子吧！假設你從網上接收到一組音視頻數據，如下： ``` ... {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:13,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:14,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:14,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:15,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:15,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:16,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:16,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:17,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:17,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:18,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:18,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:19,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:19,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:20,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=1,PT:98,seq:20,ts:1122334455,ssrc=2345}, ... ``` 假設 PT=98 是視頻數據，PT=111 是音頻數據，seq 是序號 ，ts 表示時間戳 。 按照上面的規則很容易就能將視頻幀組裝起來。 ## RTCP 協議 實時傳輸控制協議(Real-time ControlProtocol，RTCP)是和 RTP一起工作的**控制**協議。在RTP會話期間，每個會話參與者周期性地向所有其他參與者發送RTCP控制信息包。  **RTCP功能** 在使用 RTP 包傳輸數據時，難免會發生丟包、亂序、抖動等問題，下面我們來看一下使用的網絡一般都會在什么情況下出現問題： * 網絡線路質量問題引起丟包率高； * 傳輸的數據超過了帶寬的負載引起的丟包問題； * 信號干擾（信號弱）引起的丟包問題； * 跨運營商引入的丟包問題 ; WebRTC 對這些問題在底層都有相應的處理策略，但在處理這些問題之前，它首先要讓各端都知道它們自己的網絡質量到底是怎樣的，**這就是 RTCP 的作用**。 **RTCP 報文的種類** RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。 根據所攜帶的控制信息不同，RTCP信息包可分為**RR（接收者報告包）、SR（源報告包）、SEDS（源描述包）、BYE（離開申明）和APP（特殊應用包）**五類5類： RTCP 有兩個最重要的報文：RR 和 SR 。通過這兩個報文的交換，各端就知道自己的網絡質量到底如何了。  **SR 報文**   從上圖中我們可以了解到，SR 報文分成三部分：**Header、Sender info**和**Report block**。 * Header 部分用于標識該報文的類型，比如是 SR 還是 RR。 * Sender info 部分用于指明作為發送方，到底發了多少包。 * Report block 部分指明發送方作為接收方時，它從各個 SSRC 接收包的情況。 通過以上的分析，你可以發現**SR 報文**并不僅是指發送方發了多少數據，它還報告了作為接收方，它接收到的數據的情況。當發送端收到對端的接收報告時，它就可以根據接收報告來評估它與對端之間的網絡質量了，隨后再根據網絡質量做傳輸策略的調整。