在前一篇學習完了 TCP 與 UDP 協議以後，咱們要介紹另一個傳輸層協議：
RTP 協議 (RTCP 後來會提到)
本篇文章將會分成幾個章節來理解 RTP 協議：
RTP 協議想可以完成『 端點到端點的串流媒體傳輸 』 (ex. 聲音、影像)
它目前廣泛的使用於流通訊領域，例如 VOIP、網路會議，網路電視等。
因為它只是專門用來傳輸串流媒體的協議，而不管實際如何應用。你列出幾個傳輸層應用想完成的事情，大概就可以理解為啥它是傳輸層的。
傳輸層
UDP：傳輸資料
TCP：可靠的傳輸資料
RTP：傳輸多媒體資料
應用層
HTTP：HTTP server 與客戶端的表準應答
它定義了要傳輸串流媒體的參數標準 (封包標準)
RTP 協議它定議好了多媒體傳輸的參數標準，咱們來思考一下，如果直接使用 UDP 或 TCP 來傳送媒體資料會發生什麼事情。
先以簡單的 UDP 為例子，它的封包大約會長的如下：
標頭
來源端 port： 5555
目的端 port： 7777
標身
一堆聲音的二進位編碼
那這時有人就說，那不就在標頭多加一個編碼類型就好了麻 ? 嗯對沒錯，說實話就是這樣，但這就已經不能算是 UDP 標準了，因為你多了一個標頭欄位，而且這不是所有類型傳輸都需要，例如我只是要傳普通的資料。
因此後來就產生了 RTP 協議。
前面的文章中有提到，所謂的串流傳輸就是將聲音一段一段的傳，然後一邊傳就可以一邊聽。
然後在筆者這篇文章『30-09之別人要如何聽到我的聲音呢 ?』中有提到，要進行串流傳輸，要執行的流程如下：
採集 -> 編碼 -> 轉換成流容器 -> 網路 -> 聽眾可以邊下載邊聽
而剛剛上面有說到，它是直接傳輸聲音編碼的，那它為何不用轉成流容容呢 ?
答案是 RTP 本身就算是一種流容器，不過它有個前提，那就是編碼為無損編碼，因為這樣代表每次傳進來的聲音都可以直接解碼，而如果是有損的就無法，因為會依賴前後的資料。
RTP 基本上可以選擇 UDP 或 TCP 來進行傳輸，但奇怪這它們三個不是都是在傳輸層嗎 ?
嗯對的，但只是因為他們處理的層級是相同的，不代表不能一起使用。
基本上你可以將它的封包想成：
RTP 表頭 + UDP/TCP 表頭 + 表身(就是資料)
這也代表在使用 RTP 時你有兩種選擇：
不過現階段 RTP 大部份都還是使用 UDP。
咱們來簡單的看一下它定義好的封包表頭結構。
| bit | field | describe |
|---|---|---|
| 2 | V (Version) | 用來說明使用的 RTP 版本 (default 為 2)。 |
| 1 | P (Padding) | 為 1 的話，就會在最後面的 payload 後面加填充位置。 |
| 1 | X (Extenstion) | 為 1 的話，就代表存在 header 的擴展。 |
| 4 | CC (CSRC count) | 用來記錄 CSRC 的數量。(csrc 後面會說)。 |
| 1 | M (Marker) | 配置文件定義。 |
| 7 | PT (payload type) | 就是說明你要傳輸的語音視頻的編碼是啥 (ex. H.264, PCM)。 |
| 16 | Sequence Number | 每發送一個封包就 + 1 ，接受端可以用它來判斷封包順序。 |
| 32 | Timestamp | 時間戳，用來記錄採樣第一個 bit 資料(音視頻)的時間。 |
| 32 | SSRC (Synchronization source) | 記錄封包的發送方，它只是隨機的從 md5 隨機演算法中選取，然後在同一個視頻會議中，不會有相同的 ssrc 值。 |
| (0~15) X 32 | CSRC (Contributing source) | 記錄這所有參於方的來源之 ssrc。 |
其中有兩個比較重要的我們拉出來說明一下。
首先是 SSRC 它的中文為同步來源，而其中來源就是建立這個媒體的來源，例如麥克風、攝影機等，然後就算是同一個 IP 位置，但是不同的兩個麥克風說話，還是會有不同的 SSRC 值。
然後另一個為 CSRC，它裡面存放了組成這個 RTP 流的所有同步來源，也就是說這個 RTP 可以是有多個麥克風或攝影機所共同組成的一個 RTP，然後 CSRC 就是存放所有這些來源的 SSRC。
事實上概念上就如下圖：
使用 RTCP 協議 ( 它是 RTP 的姐妹協議 )
RTP 是用來傳送串流媒體的東西，但它並且沒提供Qos (Quality of Service)也就是服務品質，也就是傳 RTP 它不保證這個串流中間有沒有掉封包或是有沒有傳送到，它只負責丟就對了。
而 RTCP 就是專門用來處理服務品質這件事情，它會在來源端與目的端定時的交換統計資訊，例如送出封包數與遺失封包數，並且根據這些數字，那改善 RTP 的傳輸率之類的事情，使得 RTP 傳輸更有品質。
接下來咱們來看看它的封包結構。
| bit | field | describe |
|---|---|---|
| 2 | Version | RTP 的版本號，預設為 2 。 |
| 3 | P (padding) | 在最後的位置增加空間，大部份都是給加密使用的地方。 |
| 8 | RC | 接受方報告的數量。 |
| 16 | Packet Type | 用來判斷這個封包是那一種 RTCP 類型。 |
上面的表頭中，我們有看到每個 packet 都有分類型，然後下面是類型種類。
| code | type | describe |
|---|---|---|
| 200 | SR（Sender Report） | 發送方的報告 |
| 201 | RR（Receiver Roport） | 接受方的報告 |
| 202 | SDES（Source Descripition Items） | 來源端 |
| 203 | BYE | 結束 |
| 204 | APP（Application） | 特定應用 |
接受方每收到一次 RTP 封包時，就產生一次接受方的報告 RR。(內容為 RTP 流的 SSRC、丟失率)
發送端每發送一次 RTP 封包時，就會發送一次 SR。用來給接受方知道發送端的資訊。
SEDS 會給出會議的參於者的描述，它包含了參於者的CNAME（Canonical NAME)，CNAME 被稱規範名稱，也就給一台機器設定別名的概念，用戶使用別名就可以找到你，然後一台機器可以設定多個別名。
本篇文章中咱們學習到了以下幾個重點：
RTP 協議想可以完成『 端點到端點的串流媒體傳輸 』 (ex. 聲音、影像)
它定義好了要傳輸封包的參數標準。
BTW RTP 本身可以算是個流容器。
RTP 本身是基於 TCP 與 UDP 來進行傳輸，其它它的封包裡面的參數大部份是在描述這個媒體流的相關資訊，例如從那裡來，編碼又是啥之類的。
使用 RTCP 協議，它會在來源端與目的端定時的發送 RTCP 封包，內容包含傳輸品質資訊，然後在依據這些資訊來優化 RTP 傳輸。
iThome鐵人賽
看影片追技術