溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
實時傳輸協議RTP（Real-time Transport Protocol）是一個網絡傳輸協議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的，后在RFC3550中進行更新。
國際電信聯盟ITU-T也發布了自己的RTP文檔，作為H.225.0，但是后來當IETF發布了關于它的穩定的標準RFC后就被取消了。它作為因特網標準在 [ RFC 3550 ] 有詳細說明.
RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。它一開始被設計為一個多播協議，但后來被用在很多單播應用中。RTP協議常用于流媒體系統（配合RTSP協議），視頻會議和一鍵通（Push toTalk）系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一起使用，而且它是建立在用戶數據報協議上的（UDP）。
RTP廣泛應用于流媒體相關的通訊和娛樂，包括電話、視頻會議、電視和基于網絡的一鍵通業務（類似對講機的通話）
RTP標準定義了兩個子協議 ，RTP和RTCP
數據傳輸協議RTP，用于實時傳輸數據。該協議提供的信息包括：時間戳（用于同步）、序列號（用于丟包和重排序檢測）、以及負載格式（用于說明數據的編碼格式）。
控制協議RTCP，用于QoS反饋和同步媒體流。相對于RTP來說，RTCP所占的帶寬非常小，通常只有5%。
一提到流媒體傳輸、一談到什么視頻監控、視頻會議、語音電話（VOIP），都離不開RTP協議的應用，但當大家都根據經驗或者別人的應用而選擇RTP協議的時候，你可曾想過，為什么我們要使用RTP來進行流媒體的傳輸呢？為什么我們一定要用RTP？難道TCP、UDP或者其他的網絡協議不能達到我們的要求么？
像TCP這樣的可靠傳輸協議，通過超時和重傳機制來保證傳輸數據流中的每一個bit的正確性，但這樣會使得無論從協議的實現還是傳輸的過程都變得非常的復雜。而且，當傳輸過程中有數據丟失的時候，由于對數據丟失的檢測（超時檢測）和重傳，會數據流的傳輸被迫暫停和延時。
或許你會說，我們可以利用客戶端構造一個足夠大的緩沖區來保證顯示的正常，這種方法對于從網絡播放音視頻來說是可以接受的，但是對于一些需要實時交互的場合（如視頻聊天、視頻會議等），如果這種緩沖超過了200ms，將會產生難以接受的實時性體驗。
RTP協議是一種基于UDP的傳輸協議，RTP本身并不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。這樣，對于那些丟失的數據包，不存在由于超時檢測而帶來的延時，同時，對于那些丟棄的包，也可以由上層根據其重要性來選擇性的重傳。比如，對于I幀、P幀、B幀數據，由于其重要性依次降低，故在網絡狀況不好的情況下，可以考慮在B幀丟失甚至P幀丟失的情況下不進行重傳，這樣，在客戶端方面，雖然可能會有短暫的不清晰畫面，但卻保證了實時性的體驗和要求。
圖 1給出了流媒體應用中的一個典型的協議體系結構。
從圖中可以看出，RTP被劃分在傳輸層，它建立在UDP上。同UDP協議一樣，為了實現其實時傳輸功能，RTP也有固定的封裝形式。RTP用來為端到端的實時傳輸提供時間信息和流同步，但并不保證服務質量。服務質量由RTCP來提供。
當應用程序建立一個RTP會話時，應用程序將確定一對目的傳輸地址。目的傳輸地址由一個網絡地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數據能夠正確發送。RTP數據發向偶數的UDP端口，而對應的控制信號RTCP數據發向相鄰的奇數UDP端口（偶數的UDP端口＋1），這樣就構成一個UDP端口對。 RTP的發送過程如下，接收過程則相反。
1) RTP協議從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。 2) RTP將RTP 數據包發往UDP端口對中偶數端口；RTCP將RTCP控制包發往UDP端口對中的奇數端口。
RTP分組只包含RTP數據，而控制是由RTCP協議提供。RTP在1025到65535之間選擇一個未使用的偶數UDP端口號，而在同一次會話中的RTCP則使用下一個奇數UDP端口號。端口號5004和5005分別用作RTP和RTCP的默認端口號。RTP分組的首部格式如圖2所示，其中前12個字節是必須的。
從應用開發者的角度看，RTP 應當是應用層的一部分。在應用的發送端，開發者必須編寫用 RTP 封裝分組的程序代碼，然后把 RTP 分組交給 UDP 插口接口。在接收端，RTP 分組通過 UDP 插口接口進入應用層后，還要利用開發者編寫的程序代碼從 RTP 分組中把應用數據塊提取出來。
首先，我們看看RTP的包頭。
RTP報文頭格式（見RFC3550 Page12）：
版本號（V）：2比特，用來標志使用的RTP版本。
填充位（P）：1比特，如果該位置位，則該RTP包的尾部就包含附加的填充字節。
擴展位（X）： 1比特，如果該位置位的話，RTP固定頭部后面就跟有一個擴展頭部。
CSRC計數器（CC）：4比特，含有固定頭部后面跟著的CSRC的數目。
標記位（M）： 1比特,該位的解釋由配置文檔（Profile）來承擔.
載荷類型（PayloadType）： 7比特，標識了RTP載荷的類型。
序列號（SN）：16比特，每發送一個 RTP 數據包，序列號增加1。接收端可以據此檢測丟包和重建包序列。
時間戳(Timestamp): 2比特，記錄了該包中數據的第一個字節的采樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即使在沒有信號發送時，時間戳的數值也要隨時間而不斷地增加（時間在流逝嘛）。時鐘頻率依賴于負載數據格式，并在描述文件（profile）中進行描述。
同步源標識符(×××C)：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的×××C值。該標識符是隨機選取的 RFC1889推薦了MD5隨機算法。
貢獻源列表（CSRC List）：0～15項，每項32比特，用來標志對一個RTP混合器產生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的×××C標識符插入表中。×××C標識符都被列出來，以便接收端能正確指出交談雙方的身份。
圖 Rtp擴展頭
若 RTP 固定頭中的擴展比特位置 1（注意：如果有CSRC列表，則在CSRC列表之后），則一個長度可變的頭擴展部分被加到 RTP 固定頭之后。頭擴展包含 16 比特的長度域，指示擴展項中 32 比特字的個數，不包括 4 個字節擴展頭(因此零是有效值)。
RTP 固定頭之后只允許有一個頭擴展。為允許多個互操作實現獨立生成不同的頭擴展，或某種特定實現有多種不同的頭擴展,擴展項的前 16 比特用以識別標識符或參數。這 16 比特的格式由具體實現的上層協議定義。基本的 RTP 說明并不定義任何頭擴展本身。
當應用程序建立一個RTP會話時，應用程序將確定一對目的傳輸地址。目的傳輸地址由一個網絡地址和一對端口組成，有兩個端口：一個給RTP包，一個給RTCP包，使得RTP/RTCP數據能夠正確發送。RTP數據發向偶數的UDP端口，而對應的控制信號RTCP數據發向相鄰的奇數UDP端口（偶數的UDP端口＋1），這樣就構成一個UDP端口對。
RTP的發送過程如下，接收過程則相反。
RTP協議從上層接收流媒體信息碼流（如H.263），封裝成RTP數據包；RTCP從上層接收控制信息，封裝成RTCP控制包。
RTP將RTP 數據包發往UDP端口對中偶數端口；RTCP將RTCP控制包發往UDP端口對中的接收端口。
RTP為具體的應用提供了非常大的靈活性，它將傳輸協議與具體的應用環境、具體的控制策略分開，傳輸協議本身只提供完成實時傳輸的機制，開發者可以根據不同的應用環境，自主選擇合適的配置環境、以及合適的控制策略。
這里所說的控制策略指的是你可以根據自己特定的應用需求，來實現特定的一些RTCP控制算法，比如前面提到的丟包的檢測算法、丟包的重傳策略、一些視頻會議應用中的控制方案等等（這些策略我可能將在后續的文章中進行描述）。
對于上面說的合適的配置環境，主要是指RTP的相關配置和負載格式的定義。RTP協議為了廣泛地支持各種多媒體格式（如 H.264, MPEG-4, MJPEG, MPEG），沒有在協議中體現出具體的應用配置，而是通過profile配置文件以及負載類型格式說明文件的形式來提供。對于任何一種特定的應用，RTP定義了一個profile文件以及相關的負載格式說明，相關的文件如下所示：
《RTP Profile for Audio and Video Conferences with Minimal Control》（RFC3551）
《RTP Payload Format for H.264 Video》（RFC3984）
《RTP Payload Format for MPEG-4 Audio/Visual Streams》（RFC3016）
等等，想了解更多可以點擊這里：http://en.wikipedia.org/wiki/RTP_audio_video_profile
說明：如果應用程序不使用專有的方案來提供有效載荷類型(payload type)、順序號或者時間戳，而是使用標準的RTP協議，應用程序就更容易與其他的網絡應用程序配合運行，這是大家都希望的事情。例如，如果有兩個不同的公司都在開發因特網電話軟件，他們都把RTP合并到他們的產品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進行通信。
RTCP的主要功能：
服務質量的監視與反饋、媒體間的同步，以及多播組中成員的標識。在RTP會話期 間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，各參與者可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。
RTCP也是用UDP來傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組類型。
| 類型 | 縮寫表示 | 用途 |
|---|---|---|
| 200 | SR（Sender Report） | 發送端報告 |
| 201 | RR（Receiver Report） | 接收端報告 |
| 202 | SDES（Source Description Items） | 源點描述 |
| 203 | BYE | 結束傳輸 |
| 204 | . APP | 特定應用 |
上述五種分組的封裝大同小異，下面只講述SR類型，而其它類型請參考RFC3550。
發送端報告分組SR（Sender Report）用來使發送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有：相應的RTP流的×××C，RTP流中最新產生的RTP分組的時間戳和NTP，RTP流包含的分組數，RTP流包含的字節數。SR包的封裝如圖3所示。
版本（V）：同RTP包頭域。
填充（P）：同RTP包頭域。
接收報告計數器（RC）：5比特，該SR包中的接收報告塊的數目，可以為零。
包類型（PT）：8比特，SR包是200。
長度域（Length）：16比特，其中存放的是該SR包以32比特為單位的總長度減一。
同步源（×××C）：SR包發送者的同步源標識符。與對應RTP包中的×××C一樣。
NTP Timestamp（Network time protocol）SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。
RTP Timestamp：與NTP時間戳對應，與RTP數據包中的RTP時間戳具有相同的單位和隨機初始值。
Sender’s packet count：從開始發送包到產生這個SR包這段時間里，發送者發送的RTP數據包的總數. ×××C改變時，這個域清零。
Sender`s octet count：從開始發送包到產生這個SR包這段時間里，發送者發送的凈荷數據的總字節數（不包括頭部和填充）。發送者改變其×××C時，這個域要清零。
同步源n的×××C標識符：該報告塊中包含的是從該源接收到的包的統計信息。
丟失率（Fraction Lost）：表明從上一個SR或RR包發出以來從同步源n(×××C_n)來的RTP數據包的丟失率。
累計的包丟失數目：從開始接收到×××C_n的包到發送SR,從×××C_n傳過來的RTP數據包的丟失總數。
收到的擴展最大序列號：從×××C_n收到的RTP數據包中最大的序列號，
接收抖動（Interarrival jitter）：RTP數據包接受時間的統計方差估計
上次SR時間戳（Last SR,LSR）：取最近從×××C_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。
上次SR以來的延時（Delay since last SR,DLSR）：上次從×××C_n收到SR包到發送本報告的延時。
/*
* RTP header
*/typedef struct {#if 0 //BIG_ENDIA
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */#else
unsigned int cc:4; /* CSRC count */
unsigned int x:1; /* header extension flag */
unsigned int p:1; /* padding flag */
unsigned int version:2; /* protocol version */
unsigned int pt:7; /* payload type */
unsigned int m:1; /* marker bit */
unsigned int seq:16; /* sequence number */#endif
u_int32 ts; /* timestamp */
u_int32 ***c; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */} rtp_hdr_t;1234567891011121314151617181920212223242526272829/*
* RTCP common header word
*/typedef struct {#if 0 //BIG_ENDIA
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int count:5; /* varies by packet type */#else
unsigned int count:5; /* varies by packet type */
unsigned int p:1; /* padding flag */
unsigned int version:2; /* protocol version */#endif
unsigned int pt:8; /* RTCP packet type */
unsigned short length; /* pkt len in words, w/o this word */} rtcp_common_t;掃描下方二維碼 關注
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
