rtcp簡介
之前的文章，介紹了rtsp和rtp協議，rtsp用於建立連線及傳送請求等，rtp用於實際的**資料傳輸。整個rtsp的流程中，還有一種不可或缺的協議， 那就是rtcp。rtcp的全稱是rtp control protocol，從英文名稱可以看出，其是針對rtp的控制協議！rtcp主要用於提供資料分發質量反饋資訊，本文詳細介紹一下rtcp協議！
資料報格式
首先，讓我們來看一下rtcp的資料報格式，如下圖：
對照示意圖，可以看到如下字段，下面做詳細解釋：
v（2bit）：version，表示rtcp版本號，當前規範定義的版本號為2，需要注意的是rtp資料報中的版本號與rtcp資料報的中的版本號是一致的
p（1bit）：填充位，表示是否需要填充，0表示不填充，其不屬於控制資訊。在某些情況下（如加密）需要進行填充，在填充的情況下，padding的最後乙個位元組用於計算應該忽略多少個位元組！
rc(5bit) : 接收方報告計數，表示在該資料報中的接收方報告塊的數量，該欄位0值是有效的，但沒有實際意義！
pt(8bit) : rtcp的資料報的分組型別，rtcp包含的分組型別如下：
型別縮寫表示
意義sr（sender report）
傳送端報告
rr（receiver roport）
接收端報告
sdes（source descripition items）
源點bye
結束特定應用
length(16bit)：rtcp資料報的大小。該字段中大小的表示比較有意思，使用4個位元組為1組，長度共有幾個4個位元組的組，然後用該長度減去1，即為rtcp包中的長度！舉個栗子：假設rtcp資料報的長度為32個位元組，32/4=8，總共有8組4個位元組，8-1=7，此時rtcp資料報中length的值為7。
ssrc(32bit): 同步源標識
rr：recevier report，接受端報告。
ss：source description，源描述。
這樣，我們對rtcp報文的整體結構就比較了解了！上乙個抓包檔案，我們就會更直觀的感受了！
通過抓包檔案我們可以看到，rtcp包是應用層協議，截圖中的rtcp包是基於udp協議的！抓包中紅色部分為rtcp資料報的頭部分，藍色部分為receive report的具體內容，綠色部分為源描述的具體內容！
下面，我們來詳細看一下send report，recive report和source description的結構，首先來看send report!
通過結構圖，可以看到sender report有以下字段：
ntp時標：ntp時間戳
rtp時標：rtp時間戳
傳送者包計數：從開始傳輸到當前sr包生成的時間段內，傳送端傳送的rtp資料報的總個數！如果傳送者更改其ssrc，則該計數要被重置
傳送者資料8位組計數：從開始傳輸到當前sr包生成的時間段內，傳送端傳送的總的資料的大小的八位組計數，不包含頭資訊以及填充資訊！如果傳送者更改可ssrc，需要重置該值！該欄位可以用來估計平均位元速率！
來看乙個抓包
繼續看一下receiver report的結構：
通過結構，可以看到如下資訊：
ssrc（32bit）: 傳送端的信源識別符號，與傳送端的ssrc一致。
丟包數8（8bit）：前乙個sr或rr包傳送後，到當前的sr包或rr包的間隔內，來自源（用源ssrc標識）傳送的資料報的丟失個數
累積丟包數（24bit）: 自開始接受源（用源ssrc標識）傳送的資料開始，累積丟失的資料報的個數
擴充套件包序號（32bit）：低16位為當前接收到的來自源的（用源ssrc標識）資料報的最大序列號；高16位表示rt包序列號的迴圈計數！我們都知道rtp資料報中，表示序列號的長度為2個位元組，即最大的rtp序列號為65536，如果序列號超了65536，假設為655537，這個時候rtcp在擴充套件包序號中對其說明，如果沒有超過65536，則高16位為0，如果超過65536，則為1，如果再來一圈，則為3。做個不恰當的比喻，我們跑步一圈為65536，高16位表示我們當前正在跑第幾圈，從0開始計數！
間隔抖動（32bit）：rtp資料報間隔時間的統計估計，以時間戳為單位，用無符號整數表示！
lsr（32bit）：last sr timestamp，表示上乙個sr資料報的ntp時間戳！由於ntp時間戳為64bit，lsr為32bit，lsr取上乙個sr的ntp時間戳的中間32位：如上乙個sr資料報的ntp時間戳為「0x 00 01 7d 6e 3b 64 5a 1c 」，則lsr為0x 7d 6e 3b 64！
dlsr（32bit）：傳送當前rr包的時間與上乙個sr之間的時間間隔，以1/65536為單位，如，本次rr包與上一次sr的時間間隔為264ms，則本字段的值為0.264*65536=17301.54。
來看乙個抓包檔案:
該抓包檔案中的丟包數為0，累積丟包數為57，擴充套件的包序號為7070，間隔抖動為26，sr和dlsr均為0。
ss(source description)
接下來，我們看下source description:
通過結構圖，我們可以看到source description分組，也可以叫做sdes的組織結構是按照klv的格式組織的，key表示具體的型別，length為長度，value為具體的值, key占用1個位元組， length占用1個位元組！rtcp中可選的key如結構圖中所列，有如下幾種：
cname(值為1): 規範終端標識，像ssrc標識，cname標識在rtp連線的所有參加者中應是唯一的；
name（值為2）: 使用者名稱，用於描述源的使用者名稱；
e-mail（值為3）: 電子郵件位址，用於描述源的郵件位址，格式如 [email protected]；
phone（值為4）: 用於描述源的**號碼；
loc（值為5）: 用於描述源的地理位置；
tool（值為6）: 用於描述應用或工具的名稱，表示產生流的應用的名稱與版本，如"videotool 1.2"；
note（值為7）: 用於描述源當前狀態的過渡資訊；
priv（值為8）: 用於描述針對源的擴充套件項；
看乙個抓包：
通過抓包，我們可以看到該描述中包含乙個cname的字段，長度為7，值為「dell-pc」。
rtcp中通過sender report和receive report在rtp資料傳輸中提供當前連線中rtp包傳送的情況，rtp包接收的情況，rtp包丟失的情況，通過這些資訊反饋，我們可以實現對網路傳輸做一些調整和控制！這就是rtcp的主要功能！
結語
寫到這裡，關於rtsp傳輸的三大協議就都熟悉了！rtsp發起或停止連線，以及在連線的過程中控制流**資料的行為，如play，scale等，rtp負責資料傳輸，rtcp負責資訊反饋！如此，基於rtsp的流**傳輸就完整建立起來了！那麼關於rtsp的專題也可以告一段落了！期待下乙個專題吧！感謝朋友們的支援！
手撕rtsp協議系列（1）——rtsp基本流程
手撕rtsp協議系列（2）——rtsp訊息格式
手撕rtsp協議系列（3）——sdp格式詳解
手撕rtsp協議系列（4）——option
手撕rtsp協議系列（5）——describe
手撕rtsp協議系列（6）——setup
手撕rtsp協議系列（7）——play
手撕rtsp協議系列（8）——pause
手撕rtsp協議系列（9）——teardown
手撕rtsp協議系列（10）——get_parameter
手撕rtsp協議系列（11）——rtsp_set_parameter
手撕rtsp協議系列（12）——rtp包格式
RTSP協議分析 1
rtsp協議的proposed standard在rfc 2326中定義,是乙個被廣泛支援的處理流 傳輸的。目前real quicktime的流 解決方案並都支援rtsp。個人覺得，rtsp 在設計的時候參考了http的內容，rtsp同其下的rtp rtcp的關係類似於http同tcp的關係。但是仍...
刨死你系列 手撕ArrayList
不多bb,直接上 public class myarraylist 有參構造方法 public myarraylist int capacity elements new object capacity 獲取已使用陣列長度 public int size 判斷陣列是否為空 public boolea...
手撕演算法系列 2 top k問題
這道題也是很經典的面試題了，因為很多網際網路公司要處理海量資料，從海量資料中篩選第k大 小 的資料成為了很常見的問題，這道題也因為解法眾多而一直受到熱議。下面假定問題是要從n個不同大小的資料尋找第k大的元素，即有k 1個元素大於它。1 解法一 簡單粗暴排序 這個解法不用多說了，如果使用基於比較的排序...