如果看看Internet的發(fā)展歷史可以發(fā)現(xiàn)，最早的Internet并不是為傳輸多媒體內(nèi)容而設(shè)計(jì)的網(wǎng)絡(luò)，它只用于傳輸純文本性的資料。經(jīng)過一段時(shí)間后才加入了圖像等數(shù)據(jù)形式，而到現(xiàn)在 Internet中越來越多地出現(xiàn)了多媒體內(nèi)容。對于現(xiàn)在的Internet來講，傳輸多媒體內(nèi)容存在著一定的困難而這些困難又是我們必須面對的。

就網(wǎng)絡(luò)傳輸而言，矛盾主要集中在3個(gè)方面：其一是與純文本性的數(shù)據(jù)相比，多媒體數(shù)據(jù)要占用更多的網(wǎng)絡(luò)帶寬，這種對帶寬需求的增加決不是幾倍、幾十倍的關(guān)系，而是幾百倍、上千倍的需求；其二是多媒體應(yīng)用需要實(shí)時(shí)的網(wǎng)絡(luò)傳輸，音頻和視頻數(shù)據(jù)必須進(jìn)行連續(xù)的播放。如果數(shù)據(jù)不能按時(shí)抵達(dá)目的地，多媒體播放就會停止或中斷。相信這不是任何一個(gè)觀眾所希望遇到的。如果在出現(xiàn)數(shù)據(jù)延時(shí)情況后不能夠合理的建立延時(shí)數(shù)據(jù)的丟棄、重發(fā)機(jī)制，那么網(wǎng)絡(luò)的阻塞就會更加嚴(yán)重，最終導(dǎo)致停滯狀態(tài)；其三是多媒體數(shù)據(jù)流突發(fā)性很強(qiáng)，僅僅是單純的增加帶寬往往不能夠解決數(shù)據(jù)流的突發(fā)問題。對于大多數(shù)的多媒體應(yīng)用程序來講數(shù)據(jù)接收端都有一個(gè)緩存限制，如果不能夠很好地調(diào)節(jié)數(shù)據(jù)流的平穩(wěn)度，那么就會導(dǎo)致應(yīng)用程序的緩存溢出。

解決上述問題的方法除了快速發(fā)展網(wǎng)絡(luò)軟硬件的建設(shè)以突破帶寬限制外，設(shè)計(jì)一種實(shí)時(shí)傳輸協(xié)議來迎接多媒體時(shí)代的到來也是勢在必行的。

為了在IP網(wǎng)上傳輸多媒體內(nèi)容，IETF（互聯(lián)網(wǎng)工程任務(wù)組）開發(fā)了一個(gè)Internet增強(qiáng)服務(wù)模型，包括“best-effort”（盡力傳送）服務(wù)和“real-time”服務(wù)。其中的“real-time”服務(wù)就是為在IP網(wǎng)絡(luò)中傳輸多媒體數(shù)據(jù)提供質(zhì)量保證，同時(shí)我們可以看到RSVP、RTP、RTCP、RTSP四種協(xié)議構(gòu)成了“real-time”服務(wù)的基礎(chǔ)。

1. 資源預(yù)留協(xié)議（RSVP協(xié)議）

資源預(yù)留協(xié)議RSVP（Resource Reservation Protocol）原本是為網(wǎng)絡(luò)會議應(yīng)用而開發(fā)的，后被互聯(lián)網(wǎng)工程任務(wù)組（IETF）的Integrated Services工作組集成到通用的資源預(yù)留解決方案中。RSVP協(xié)議是施樂公司的 Palo Alto研究中心、麻省理工學(xué)院（MIT）以及美國加州大學(xué)信息科學(xué)學(xué)院等研究機(jī)構(gòu)共同的成果。1994年11月提交到互聯(lián)網(wǎng)工程指導(dǎo)組（IESG）請求提議標(biāo)準(zhǔn)，1997年9月RSVP Version功能規(guī)范成了Internet標(biāo)準(zhǔn)。

RSVP 協(xié)議是網(wǎng)絡(luò)控制協(xié)議，它使 Internet 應(yīng)用傳輸數(shù)據(jù)流時(shí)能夠獲得特殊服務(wù)質(zhì)量（Qo Ss）。RSVP是非路由協(xié)議，它同路由協(xié)議協(xié)同工作，建立與路由協(xié)議計(jì)算出路由等價(jià)的動態(tài)訪問列表。RSVP協(xié)議屬于OSI 7層協(xié)議棧中的傳輸層。RSVP的組成元素有發(fā)送端、接收端和主機(jī)或路由器。發(fā)送端負(fù)責(zé)讓接收端知道數(shù)據(jù)將要發(fā)送，以及需要什么樣的Qo S；接收者負(fù)責(zé)發(fā)送一個(gè)通知到主機(jī)或路由器，這樣它們就可以準(zhǔn)備接收即將到來的數(shù)據(jù)；主機(jī)或路由器負(fù)責(zé)留出所有合適的資源。

RSVP的工作原理大致是這樣的：發(fā)送端首先向接收端發(fā)送一個(gè)RSVP信息，RSVP信息同其他IP數(shù)據(jù)包一樣通過各個(gè)路由器到達(dá)目的地。接收端在接收到發(fā)送端發(fā)送的信息之后。由接收端根據(jù)自身情況逆向發(fā)起資源預(yù)留請求，資源預(yù)留信息沿著與原來信息包相反的方向?qū)ρ赝镜穆酚善髦饌€(gè)進(jìn)行資源預(yù)留。

2.RTP協(xié)議

RTP（Real-time Transport Protocol）是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP 被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP通常使用UDP來傳送數(shù)據(jù)，但RTP也可以在TCP或ATM等其他協(xié)議之上工作。當(dāng)應(yīng)用程序開始一個(gè)RTP會話時(shí)將使用兩個(gè)端口：一個(gè)給RTP，一個(gè)給RTCP。

圖8.20 RTP數(shù)據(jù)包

RTP數(shù)據(jù)包中包括4項(xiàng)基本內(nèi)容。通過圖8.20可以形象地看到RTP數(shù)據(jù)包的位置及結(jié)構(gòu)。RTP數(shù)據(jù)包由固定報(bào)頭和有效載荷兩部分組成，其中固定報(bào)頭又包括時(shí)戳、順序標(biāo)號、同步源標(biāo)識、貢獻(xiàn)源標(biāo)識等，有效載荷就是傳輸?shù)囊纛l或視頻等多媒體數(shù)據(jù)。

時(shí)戳（Timestamping）是實(shí)時(shí)應(yīng)用中的一個(gè)重要概念。發(fā)送端會在數(shù)據(jù)包中插入一個(gè)即時(shí)的時(shí)間標(biāo)記，這個(gè)時(shí)間標(biāo)記就是所說的時(shí)戳。時(shí)戳?xí)S著時(shí)間的推移而增加，當(dāng)數(shù)據(jù)包抵達(dá)接收端后，接收端會根據(jù)時(shí)戳重新建立原始音頻或視頻的時(shí)序。時(shí)戳也可以用于同步多個(gè)不同的數(shù)據(jù)流，幫助接收方確定數(shù)據(jù)到達(dá)時(shí)間的一致性。

由于UDP協(xié)議發(fā)送數(shù)據(jù)包時(shí)無時(shí)間順序。因此人們就使用順序編號（Sequence Numbers）對抵達(dá)的數(shù)據(jù)包進(jìn)行重新排序，同時(shí)順序標(biāo)號也被用于對丟包的檢查。在實(shí)際的傳輸過程中會遇到如下的情況，在某些視頻格式中，一個(gè)視頻幀的數(shù)據(jù)可能會被分解到多個(gè)RTP數(shù)據(jù)包中傳遞，這些數(shù)據(jù)包會具有同一個(gè)時(shí)戳。因此僅憑時(shí)戳是不能夠?qū)?shù)據(jù)包重新排序的，還必須依賴順序編號。

源標(biāo)識（Source Identification）可以幫助接收端利用發(fā)送端生成的唯一數(shù)值來區(qū)分多個(gè)同時(shí)的數(shù)據(jù)流。得到數(shù)據(jù)的發(fā)送源，例如在網(wǎng)絡(luò)會議中通過源鑒定可以得到哪一個(gè)用戶在講話。

有效載荷類型（Payload Type）對傳輸?shù)囊纛l、視頻等數(shù)據(jù)類型予以說明，并說明數(shù)據(jù)的編碼方式，接收端從而知道如何破譯和播放負(fù)載數(shù)據(jù)。

同步源標(biāo)識（SSRC），占32 bit，從一個(gè)同步源出來的所有的包構(gòu)成了相同的時(shí)間和序列部分。所以在接收端就可以用同步源為包分組，從而進(jìn)行回放。

貢獻(xiàn)原標(biāo)識（CSRC），可以有0～15個(gè)項(xiàng)目，每個(gè)項(xiàng)目占32 bit，一列貢獻(xiàn)源標(biāo)識被插入到“Mixer”（混合器）中?；旌掀鞅硎緦⒍鄠€(gè)載荷數(shù)據(jù)組合起來產(chǎn)生一個(gè)將要發(fā)出去的包，允許接收端確認(rèn)當(dāng)前數(shù)據(jù)的貢獻(xiàn)源。它們具有相同的同步源標(biāo)識符。

RTP協(xié)議有如下優(yōu)點(diǎn)：

（1）協(xié)議簡單：RTP協(xié)議是建立在UDP協(xié)議上的，其本身不支持資源預(yù)留，不提供保證傳輸質(zhì)量任何機(jī)制。數(shù)礎(chǔ)包也是依靠下層協(xié)議提供長度標(biāo)識和長度限制、因此協(xié)議規(guī)定相對簡單得多。

（2）擴(kuò)展性好：RTP協(xié)議一般建立在UDP之上，充分利用了UDP協(xié)議的多路復(fù)用服務(wù)，當(dāng)然它也可以建立在其他的傳輸協(xié)議卜，像ATM、IPV6等。這主要得益于RTP協(xié)議不對下層協(xié)議作任何的指定，同時(shí)RTP對于新的負(fù)載類型和多媒體軟件來講也是完全開放的。

（3）數(shù)據(jù)流和控制流分離：RTP協(xié)議的數(shù)據(jù)傳輸和控制傳輸使用不同的端口，大大提高了協(xié)議的靈活性和處理的簡單性。

3.RTCP協(xié)議

RTCP是英文Real-Time Control Protocol的縮寫，中文稱為“實(shí)時(shí)傳輸控制協(xié)議”。RTCP是一個(gè)控制協(xié)議。它的設(shè)計(jì)目的是與RTP協(xié)議共同合作，為順序傳輸數(shù)據(jù)包提供可靠的傳送機(jī)制，并對網(wǎng)絡(luò)流量和阻塞進(jìn)行控制。

RTP協(xié)議是互聯(lián)網(wǎng)上廣泛應(yīng)用的流媒體傳輸協(xié)議。通常運(yùn)行于RTP/UDP模式下，而UDP協(xié)議本身不提供任何傳輸可靠性保證，傳輸層的控制功能主要由它的控制部分RTCP協(xié)議來實(shí)現(xiàn)。RTCP協(xié)議是RTP協(xié)議的控制部分。RTP用來傳遞實(shí)時(shí)多媒體數(shù)據(jù)信息，除了攜帶多媒體數(shù)據(jù)外，它還給出了所攜帶負(fù)載的時(shí)間戳、順序號等信息。為了可靠、高效地傳送實(shí)時(shí)數(shù)據(jù)，RTP和RTCP必須配合使用。RTCP依靠反饋機(jī)制根據(jù)已經(jīng)發(fā)送的數(shù)據(jù)報(bào)文對帶寬進(jìn)行調(diào)整、優(yōu)化，從而實(shí)現(xiàn)對流媒體服務(wù)的Qo S控制。RTCP反饋可以直接作用于編碼、發(fā)送、甚至協(xié)議選擇環(huán)節(jié)。

RTCP數(shù)據(jù)包是一個(gè)控制包，它由一個(gè)固定報(bào)頭和結(jié)構(gòu)元素組成。其報(bào)頭與RTP數(shù)據(jù)包的報(bào)頭相類似，一般都是將多個(gè)RTCP數(shù)據(jù)包合成一個(gè)包在底層協(xié)議中傳輸。RTP和 RTCP兩者配合能以有效的反饋和最小的開銷使傳輸效率最佳化，特別適合在Internet上傳輸實(shí)時(shí)數(shù)據(jù)。

4.RTSP協(xié)議

實(shí)時(shí)流協(xié)議RTSP（Real Time Streaming Protocol）是由RealNetworks和Netscape共同提出的，該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或RTP完成數(shù)據(jù)傳輸。HTTP與RTSP相比， HTTP傳送HTML，而RTP傳送的是多媒體數(shù)據(jù)。HTTP請求由客戶機(jī)發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時(shí)，客戶機(jī)和服務(wù)器都可以發(fā)出請求，即RTSP可以是雙向的。

實(shí)時(shí)流協(xié)議（RTSP）是應(yīng)用級協(xié)議，控制實(shí)時(shí)數(shù)據(jù)的發(fā)送。RTSP提供了一個(gè)可擴(kuò)展框架，使實(shí)時(shí)數(shù)據(jù)，如音頻與視頻的受控、點(diǎn)播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上的發(fā)送機(jī)制提供方法。

RTSP提供的操作主要有3種：

（1）從媒體服務(wù)器上取得多媒體數(shù)據(jù)，客戶端可以要求服務(wù)器建立會話并傳送被請求的數(shù)據(jù)。

（2）要求媒體服務(wù)器加入會議，并回放或錄制媒體。

（3）向已經(jīng)存在的表達(dá)中加入媒體。當(dāng)任何附加的媒體變?yōu)榭捎脮r(shí)，客戶端和服務(wù)器之間要互相通報(bào)。