久久久久久久999,亚洲国产第一区二区香蕉日日

為什么要使用RTP

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

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

1. 維基百科的相關(guān)解釋

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這樣的可靠傳輸協(xié)議，通過(guò)超時(shí)和重傳機(jī)制來(lái)保證傳輸數(shù)據(jù)流中的每一個(gè)bit的正確性，但這樣會(huì)使得無(wú)論從協(xié)議的實(shí)現(xiàn)還是傳輸?shù)倪^(guò)程都變得非常的復(fù)雜。而且，當(dāng)傳輸過(guò)程中有數(shù)據(jù)丟失的時(shí)候，由于對(duì)數(shù)據(jù)丟失的檢測(cè)（超時(shí)檢測(cè)）和重傳，會(huì)數(shù)據(jù)流的傳輸被迫暫停和延時(shí)。

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

2. 為什么RTP可以解決上述時(shí)延問(wèn)題

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

3. 多播功能

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

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

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

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

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

V ― 版本。識(shí)別 RTP 版本。

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

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

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

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

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

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

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

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

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

5. RTP的profile機(jī)制

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

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

對(duì)于上面說(shuō)的合適的配置環(huán)境，主要是指RTP的相關(guān)配置和負(fù)載格式的定義。RTP協(xié)議為了廣泛地支持各種多媒體格式（如 H.264, MPEG-4, MJPEG, MPEG），沒(méi)有在協(xié)議中體現(xiàn)出具體的應(yīng)用配置，而是通過(guò)profile配置文件以及負(fù)載類型格式說(shuō)明文件的形式來(lái)提供。對(duì)于任何一種特定的應(yīng)用，RTP定義了一個(gè)profile文件以及相關(guān)的負(fù)載格式說(shuō)明，相關(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.wikipedia.org/wiki/RTP_audio_video_profile

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

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

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

（2）有較少的首部開(kāi)銷

TCP和XTP相對(duì)RTP來(lái)說(shuō)具有過(guò)多的首部開(kāi)銷(TCP和XTP3.6是40字節(jié)，XTP4.0是32字節(jié)，而RTP只有12字節(jié))