一提到流媒體傳輸、一談到什么視頻監(jiān)控、視頻會議、語音電話（VOIP），都離不開RTP協(xié)議的應(yīng)用，但當(dāng)大家都根據(jù)經(jīng)驗(yàn)或者別人的應(yīng)用而選擇RTP協(xié)議的時候，你可曾想過，為什么我們要使用RTP來進(jìn)行流媒體的傳輸呢？為什么我們一定要用RTP？難道TCP、UDP或者其他的網(wǎng)絡(luò)協(xié)議不能達(dá)到我們的要求么？

本文就是根據(jù)我在RTP協(xié)議的學(xué)習(xí)和應(yīng)用過程中整理出來的思考，希望對大家有所啟發(fā)，同時，也歡迎大家留言探討，提出自己的想法和思考。

<!--[if !supportLists]-->1.      <!--[endif]-->維基百科的相關(guān)解釋

像TCP這樣的可靠傳輸協(xié)議，通過超時和重傳機(jī)制來保證傳輸數(shù)據(jù)流中的每一個bit的正確性，但這樣會使得無論從協(xié)議的實(shí)現(xiàn)還是傳輸?shù)倪^程都變得非常的復(fù)雜。而且，當(dāng)傳輸過程中有數(shù)據(jù)丟失的時候，由于對數(shù)據(jù)丟失的檢測（超時檢測）和重傳，會數(shù)據(jù)流的傳輸被迫暫停和延時。

或許你會說，我們可以利用客戶端構(gòu)造一個足夠大的緩沖區(qū)來保證顯示的正常，這種方法對于從網(wǎng)絡(luò)播放音視頻來說是可以接受的，但是對于一些需要實(shí)時交互的場合（如視頻聊天、視頻會議等），如果這種緩沖超過了200ms，將會產(chǎn)生難以接受的實(shí)時性體驗(yàn)。

2.  為什么RTP可以解決上述時延問題

RTP協(xié)議是一種基于UDP的傳輸協(xié)議，RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。這樣，對于那些丟失的數(shù)據(jù)包，不存在由于超時檢測而帶來的延時，同時，對于那些丟棄的包，也可以由上層根據(jù)其重要性來選擇性的重傳。比如，對于I幀、P幀、B幀數(shù)據(jù)，由于其重要性依次降低，故在網(wǎng)絡(luò)狀況不好的情況下，可以考慮在B幀丟失甚至P幀丟失的情況下不進(jìn)行重傳，這樣，在客戶端方面，雖然可能會有短暫的不清晰畫面，但卻保證了實(shí)時性的體驗(yàn)和要求。

3. 多播功能

多播在網(wǎng)絡(luò)視頻會議方面有著很廣泛的應(yīng)用，它主要應(yīng)用于這樣一種環(huán)境，即：

假設(shè)紅色的圓為存放有視頻數(shù)據(jù)的流媒體服務(wù)器，其他的圓為連接到該服務(wù)器的各個客戶端，當(dāng)所有的綠色的客戶端要求同時觀看紅色服務(wù)器上的某一個視頻時，如果服務(wù)器為每一路客戶端單獨(dú)建立連接進(jìn)行數(shù)據(jù)的傳輸，這樣明顯不太合理浪費(fèi)帶寬，因此，多播技術(shù)可以很好地解決這種問題，即同一份數(shù)據(jù)，由服務(wù)器發(fā)送到公共的多播地址，各個客戶端均監(jiān)聽同一個多播地址來獲取數(shù)據(jù)，這樣，既節(jié)省了帶寬，同時也保證了各個客戶端所觀看的視頻的同步。

這樣的多播應(yīng)用TCP協(xié)議是不支持的，而RTP協(xié)議在最初就是為了實(shí)現(xiàn)類似的視頻會議的應(yīng)用而誕生的，對其有非常好的支持。

4.  RTP包頭中的流媒體特性

首先，我們看看RTP的包頭。

V ― 版本。識別 RTP 版本。

P ― 填充。設(shè)置1時，數(shù)據(jù)包包含一個或多個附加填充比特，填充比特不屬于有效載荷。
     X ― 擴(kuò)展位。設(shè)置1時，在固定頭后面，跟隨一個頭擴(kuò)展。
     CSRC Count ― 包含 CSRC 標(biāo)識符（在固定頭后）的數(shù)目。
     M ― 標(biāo)志。標(biāo)志由描述文件（profile）文件定義。允許在比特流中標(biāo)記重要的事件，如幀邊界。

Payload Type ― 負(fù)載類型。由具體的應(yīng)用決定其解釋。某些profile 文件規(guī)定了從 Payload 編碼到 Payload 格式的缺省靜態(tài)映射。另外的 Payload Type 編碼也可以通過非 RTP 方法實(shí)現(xiàn)動態(tài)定義。

Sequence Number ― 序列號。每發(fā)送一個 RTP 數(shù)據(jù)包，序列號增加1。接收端可以據(jù)此檢測丟包和重建包序列。

Timestamp ―時間戳。反映了RTP 數(shù)據(jù)包中第一個字節(jié)的采樣時間。時鐘頻率依賴于負(fù)載數(shù)據(jù)格式，并在描述文件（profile）中進(jìn)行描述。

SSRC ― 同步源。該標(biāo)識符隨機(jī)生成，旨在確保在同一個 RTP 會話中不存在兩個同步源具有相同的 SSRC 標(biāo)識符。

CSRC ― 貢獻(xiàn)源標(biāo)識符。識別該數(shù)據(jù)包中的有效載荷的貢獻(xiàn)源。

從RTP包頭的規(guī)定中，我們可以非常清晰地看出，在RTP協(xié)議中，添加了非常多專為流媒體傳輸所使用的特性，更加有助于應(yīng)用于流媒體的傳輸。

比如用于幀邊界標(biāo)記的M標(biāo)志位，方便接收端快速定位幀邊界；比如負(fù)載類型字段，用來告訴接收端（或者播放器）傳輸?shù)氖悄姆N類型的媒體（例如G.729，H.264，MPEG-4等），這樣接收端（或者播放器）就知道數(shù)據(jù)流是什么格式，然后使用對應(yīng)的解碼器去解碼或者播放；比如時間戳字段，標(biāo)識了數(shù)據(jù)流的時間戳，接收端可以利用這個時間戳來去除由網(wǎng)絡(luò)引起的信息包的抖動，并且在接收端為播放提供同步功能，等等。

因此，相比于直接使用TCP或者UDP來進(jìn)行流媒體傳輸，這樣一個專門為傳輸音視頻而誕生的網(wǎng)絡(luò)協(xié)議更加合適。

5. RTP的profile機(jī)制

RTP為具體的應(yīng)用提供了非常大的靈活性，它將傳輸協(xié)議與具體的應(yīng)用環(huán)境、具體的控制策略分開，傳輸協(xié)議本身只提供完成實(shí)時傳輸?shù)臋C(jī)制，開發(fā)者可以根據(jù)不同的應(yīng)用環(huán)境，自主選擇合適的配置環(huán)境、以及合適的控制策略。

這里所說的控制策略指的是你可以根據(jù)自己特定的應(yīng)用需求，來實(shí)現(xiàn)特定的一些RTCP控制算法，比如前面提到的丟包的檢測算法、丟包的重傳策略、一些視頻會議應(yīng)用中的控制方案等等（這些策略我可能將在后續(xù)的文章中進(jìn)行描述）。

對于上面說的合適的配置環(huán)境，主要是指RTP的相關(guān)配置和負(fù)載格式的定義。RTP協(xié)議為了廣泛地支持各種多媒體格式（如 H.264, MPEG-4, MJPEG, MPEG），沒有在協(xié)議中體現(xiàn)出具體的應(yīng)用配置，而是通過profile配置文件以及負(fù)載類型格式說明文件的形式來提供。對于任何一種特定的應(yīng)用，RTP定義了一個profile文件以及相關(guān)的負(fù)載格式說明，相關(guān)的文件如下所示：

《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）

等等，想了解更多可以點(diǎn)擊這里：http://en./wiki/RTP_audio_video_profile

說明，如果應(yīng)用程序不使用專有的方案來提供有效載荷類型(payload type)、順序號或者時間戳，而是使用標(biāo)準(zhǔn)的RTP協(xié)議，應(yīng)用程序就更容易與其他的網(wǎng)絡(luò)應(yīng)用程序配合運(yùn)行，這是大家都希望的事情。例如，如果有兩個不同的公司都在開發(fā)因特網(wǎng)電話軟件，他們都把RTP合并到他們的產(chǎn)品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進(jìn)行通信。

6. RTP其他的一些良好特性

（1）RTP協(xié)議在設(shè)計上考慮到安全功能，支持加密數(shù)據(jù)和身份驗(yàn)證功能。

（2）有較少的首部開銷

     TCP和XTP相對RTP來說具有過多的首部開銷(TCP和XTP3.6是40字節(jié)，XTP4.0是32字節(jié)，而RTP只有12字節(jié))

（3）……（等待補(bǔ)充）

7. 相關(guān)資源列表

這里有些相關(guān)的RTP資源，希望對大家有所幫助。

（1）維基百科對RTP的介紹：

   http://en./wiki/Real-time_Transport_Protocol

（2）維基百科對流媒體的介紹：

   http://en./wiki/Streaming_media

（3）stackoverflows論壇關(guān)于RTP vs TCP的討論

   http:///questions/361943/why-does-rtp-use-udp-instead-of-tcp

（4）關(guān)于RTP的負(fù)載類型和時間戳的講解

   http://ticktick.blog.51cto.com/823160/350142

  （5） RTP FAQ

   Some Frequently Asked Questions about RTP

本文出自 “對影成三人” 博客，請務(wù)必保留此出處http://ticktick.blog.51cto.com/823160/462746