一提到流媒體傳輸、一談到什麼視頻監控、視頻會議、語音電話VOIP），都離不開RTP協議的應用，但當大家都根據經驗或者別人的應用而選擇RTP協議的時候，你可曾想過，為什麼我們要使用RTP來進行流媒體的傳輸呢？為什麼我們一定要用RTP？難道TCP、UDP或者其他的網絡協議不能達到我們的要求麼？
本文就是根據我在RTP協議的學習和應用過程中整理出來的思考，希望對大家有所啟發，同時，也歡迎大家留言探討，提出自己的想法和思考。
1. 維基百科的相關解釋
Reliable protocols, such as the Transmission Control Protocol (TCP), guarantee correct delivery of each bit in the media stream. However, they accomplish this with a system of timeouts and retries, which makes them more complex to implement. It also means that when there is data loss on the network, the media stream stalls while the protocol handlers detect the loss and retransmit the missing data. Clients can minimize this effect by buffering data for display. While delay due to buffering is acceptable in video on demand scenarios, users of interactive applications such as video conferencing will experience a loss of fidelity if the delay that buffering contributes to exceeds 200 ms.
像TCP這樣的可靠傳輸協議，通過超時和重傳機制來保證傳輸數據流中的每一個bit的正確性，但這樣會使得無論從協議的實現還是傳輸的過程都變得非常的復雜。而且，當傳輸過程中有數據丟失的時候，由於對數據丟失的檢測超時檢測）和重傳，會數據流的傳輸被迫暫停和延時。
或許你會說，我們可以利用客戶端構造一個足夠大的緩沖區來保證顯示的正常，這種方法對於從網絡播放音視頻來說是可以接受的，但是對於一些需要實時交互的場合如視頻聊天、視頻會議等），如果這種緩沖超過了200ms，將會產生難以接受的實時性體驗。
2. 為什麼RTP可以解決上述時延問題
RTP協議是一種基於UDP的傳輸協議，RTP本身並不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。這樣，對於那些丟失的數據包，不存在由於超時檢測而帶來的延時，同時，對於那些丟棄的包，也可以由上層根據其重要性來選擇性的重傳。比如，對於I幀、P幀、B幀數據，由於其重要性依次降低，故在網絡狀況不好的情況下，可以考慮在B幀丟失甚至P幀丟失的情況下不進行重傳，這樣，在客戶端方面，雖然可能會有短暫的不清晰畫面，但卻保證了實時性的體驗和要求。
3. 多播功能
多播在網絡視頻會議方面有著很廣泛的應用，它主要應用於這樣一種環境，即：
假設紅色的圓為存放有視頻數據的流媒體服務器，其他的圓為連接到該服務器的各個客戶端，當所有的綠色的客戶端要求同時觀看紅色服務器上的某一個視頻時，如果服務器為每一路客戶端單獨建立連接進行數據的傳輸，這樣明顯不太合理浪費帶寬，因此，多播技術可以很好地解決這種問題，即同一份數據，由服務器發送到公共的多播地址，各個客戶端均監聽同一個多播地址來獲取數據，這樣，既節省了帶寬，同時也保證了各個客戶端所觀看的視頻的同步。
這樣的多播應用TCP協議是不支持的，而RTP協議在最初就是為了實現類似的視頻會議的應用而誕生的，對其有非常好的支持。
4. RTP包頭中的流媒體特性
首先，我們看看RTP的包頭。
V ― 版本。識別 RTP 版本。
X ― 擴展位。設置1時，在固定頭後面，跟隨一個頭擴展。
CSRC Count ― 包含 CSRC 標識符在固定頭後）的數目。
M ― 標志。標志由描述文件profile）文件定義。允許在比特流中標記重要的事件，如幀邊界。
Sequence Number ― 序列號。每發送一個 RTP 數據包，序列號增加1。接收端可以據此檢測丟包和重建包序列。
Timestamp ―時間戳。反映了RTP 數據包中第一個字節的采樣時間。時鐘頻率依賴於負載數據格式，並在描述文件profile）中進行描述。
SSRC ― 同步源。該標識符隨機生成，旨在確保在同一個 RTP 會話中不存在兩個同步源具有相同的 SSRC 標識符。
CSRC ― 貢獻源標識符。識別該數據包中的有效載荷的貢獻源。
從RTP包頭的規定中，我們可以非常清晰地看出，在RTP協議中，添加了非常多專為流媒體傳輸所使用的特性，更加有助於應用於流媒體的傳輸。
比如用於幀邊界標記的M標志位，方便接收端快速定位幀邊界；比如負載類型字段，用來告訴接收端或者播放器）傳輸的是哪種類型的媒體例如G.729，H.264，MPEG-4等），這樣接收端或者播放器）就知道數據流是什麼格式，然後使用對應的解碼器去解碼或者播放；比如時間戳字段，標識了數據流的時間戳，接收端可以利用這個時間戳來去除由網絡引起的信息包的抖動，並且在接收端為播放提供同步功能，等等。
因此，相比於直接使用TCP或者UDP來進行流媒體傳輸，這樣一個專門為傳輸音視頻而誕生的網絡協議更加合適。
5. RTP的profile機制
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合並到他們的產品中，這樣就有希望：使用不同公司電話軟件的用戶之間能夠進行通信。
6. RTP其他的一些良好特性
1）RTP協議在設計上考慮到安全功能，支持加密數據和身份驗證功能。
2）有較少的首部開銷
TCP和XTP相對RTP來說具有過多的首部開銷(TCP和XTP3.6是40字節，XTP4.0是32字節，而RTP只有12字節)
3）……等待補充）
7. 相關資源列表
這裡有些相關的RTP資源，希望對大家有所幫助。
1）維基百科對RTP的介紹：
http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
2）維基百科對流媒體的介紹：
http://en.wikipedia.org/wiki/Streaming_media
3）stackoverflows論壇關於RTP vs TCP的討論
http://stackoverflow.com/questions/361943/why-does-rtp-use-udp-instead-of-tcp
4）關於RTP的負載類型和時間戳的講解
http://ticktick.blog.51cto.com/823160/350142
5） RTP FAQ
Some Frequently Asked Questions about RTP
本文出自 “對影成三人” 博客，請務必保留此出處http://ticktick.blog.51cto.com/823160/462746
