實(shí)時(shí)流協(xié)議rtsp_第1頁(yè)
實(shí)時(shí)流協(xié)議rtsp_第2頁(yè)
實(shí)時(shí)流協(xié)議rtsp_第3頁(yè)
實(shí)時(shí)流協(xié)議rtsp_第4頁(yè)
實(shí)時(shí)流協(xié)議rtsp_第5頁(yè)
已閱讀5頁(yè),還剩7頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、1. 實(shí)時(shí)流協(xié)議RTSPRTSP3協(xié) 議以客戶服務(wù)器方式工作,它是一個(gè)多媒體播放控制協(xié)議,用來(lái)使用戶在播放從因特網(wǎng)下載的實(shí)時(shí)數(shù)據(jù)時(shí)能夠進(jìn)行控制,如:暫停/繼 續(xù)、后退、前進(jìn)等。因此 RTSP 又稱為“因特網(wǎng)錄像機(jī)遙控協(xié)議”。1.1. RTSP協(xié) 議簡(jiǎn)介要 實(shí)現(xiàn) RTSP 的控制功能,不僅要有協(xié)議,而且要有專門的媒體播放器(media player)和 媒體服務(wù)器(media server)。媒體服務(wù)器與媒體播放器的關(guān)系是服務(wù)器與客戶的關(guān)系。媒 體服務(wù)器與普通的萬(wàn)維網(wǎng)服務(wù)器的最大區(qū)別就是媒體服務(wù)器支持流式音頻和視頻的傳送,因而在客戶端的媒體播放器可以邊下載邊播放(需要先緩存一小段時(shí)間的節(jié) 目)。

2、但從普通萬(wàn)維網(wǎng)服務(wù)器下載多媒體節(jié)目時(shí),是先將整個(gè)文件下載完畢,然后再進(jìn)行播放。圖1 RTSP與RTP和RTCP的關(guān)系RTSP 僅僅是使媒體播放器能控制多媒體流的傳送。因此,RTSP 又稱為帶外協(xié)議,而多媒體流是使用 RTP 在帶內(nèi)傳送的。1.2. RTSP的 報(bào)文結(jié)構(gòu)RTSP有 兩類報(bào)文:請(qǐng)求報(bào)文和響應(yīng)報(bào)文。請(qǐng)求報(bào)文是指從客戶向服務(wù)器發(fā)送請(qǐng)求報(bào)文,響應(yīng)報(bào)文是指從服務(wù)器到客戶的回答。由 于 RTSP 是面向正文的(text-oriented),因此在報(bào)文中的每一個(gè)字段都是一些 ASCII 碼串,因而每個(gè)字段的長(zhǎng)度都是不確定的。RTSP報(bào) 文由三部分組成,即開始行、首部行和實(shí)體主體。在請(qǐng)求報(bào)文中,

3、開始行就是請(qǐng)求行,RTSP請(qǐng)求報(bào)文的結(jié)構(gòu)如圖2所 示。圖2 RTSP請(qǐng)求報(bào)文的結(jié)構(gòu)RTSP請(qǐng) 求報(bào)文的方法包括:OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。RTSP請(qǐng) 求報(bào)文的常用方法及作用如表1所示。表1 RTSP請(qǐng)求報(bào)文的常用方法及 作用方法作用OPTIONS獲得服務(wù) 器提供的可用方法DESCRIBE得到會(huì)話 描述信息SETUP客戶端提 醒服務(wù)器建立會(huì)話,并確定傳輸模式TEARDOWN客戶端發(fā) 起關(guān)閉請(qǐng)求PLAY客戶端發(fā) 送播放請(qǐng)求響 應(yīng)報(bào)文的開始行是狀態(tài)行,RTSP響應(yīng)報(bào)文的結(jié)構(gòu)如圖3所示。

4、圖3 RTSP響應(yīng)報(bào)文的結(jié)構(gòu)1.3. RTSP交 互過(guò)程C表 示RTSP客戶端,S表示RTSP服務(wù)端 C->S: OPTION request /詢問(wèn)S有 哪些方法可用S->C: OPTION response /S回 應(yīng)信息中包括提供的所有可用方法 C->S: DESCRIBE request /要求得到S提供 的媒體初始化描述信息S->C: DESCRIBE response /S回 應(yīng)媒體初始化描述信息,主要是sdp C->S: SETUP request /設(shè)置會(huì)話屬性,以及傳輸模式,提醒S建 立會(huì)話S->C: SETUP response /S建

5、立會(huì)話,返回會(huì)話標(biāo)識(shí)符及會(huì)話相關(guān)信息 C->S: PLAY request /C請(qǐng)求播放S->C: PLAY response /S回 應(yīng)請(qǐng)求信息S->C: 發(fā) 送流媒體數(shù)據(jù) C->S: TEARDOWN request /C請(qǐng) 求關(guān)閉會(huì)話S->C: TEARDOWN response /S回應(yīng)請(qǐng)求上 述的過(guò)程是標(biāo)準(zhǔn)的RTSP流程,其中第3步和第4步是必需的。RTSP,實(shí)時(shí)流協(xié)議,是一個(gè)C/S多媒體節(jié)目協(xié)議, 它可以控制流媒體數(shù)據(jù)在IP網(wǎng)絡(luò)上的發(fā)送,同時(shí)提供用于音頻和視頻流的“VCR模式”遠(yuǎn)程控制功能,如停止、快進(jìn)、快退和定位。同時(shí)RTSP又是一個(gè)應(yīng)用 層協(xié)議,用

6、來(lái)與諸如RTP、RSVP等更低層的協(xié)議一起,提供基于Internet的整套流化服務(wù)?;赗TSP協(xié)議流媒體服務(wù)器的實(shí)現(xiàn)方案可以讓流媒體在IP 上自由翱翔。 RTSP協(xié)議1協(xié)議特點(diǎn)RTSP協(xié)議具有如下的特點(diǎn): 可擴(kuò)展性:新方法和參數(shù)很容易加入RTSP。 易解析:RTSP可由標(biāo)準(zhǔn) HTTP或MIME解析器解析。 安全:RTSP使用網(wǎng)頁(yè)安全機(jī)制。 獨(dú)立于傳輸:RTSP傳輸通道,可使用不可靠數(shù)據(jù)包協(xié)議(UDP)或可靠數(shù)據(jù)包協(xié)議(RDP),如要實(shí)現(xiàn)應(yīng)用級(jí)可靠,可使用諸如TCP的可靠流協(xié)議。 記錄設(shè)備控制:協(xié)議可控制記錄和回放設(shè)備。 適合專業(yè)應(yīng)用:通過(guò)SMPTE 時(shí)標(biāo),RTSP支持幀級(jí)精度,允許遠(yuǎn)程數(shù)字編

7、輯。 演示描述中立:協(xié)議未強(qiáng)加特殊演示或元文件,可傳送所用格式類型;然而,演示描述至少需包含一個(gè)RTSP URI。 代理與防火墻友好:協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法,為UDP媒體流打開一個(gè)“缺口”。 適當(dāng)?shù)姆?wù)器控制:如用戶啟動(dòng)一個(gè)流,則也可以停止一個(gè)流。 傳輸協(xié)調(diào):實(shí)際處理連續(xù)媒體流前,用戶可協(xié)調(diào)傳輸方法。 性能協(xié)調(diào):如基本特征無(wú)效,則必須有一些清理機(jī)制讓用戶決定那種方法不生效。這允許用戶提出適合自己的界面。2同其他協(xié)議的關(guān)系RTSP在功能上與HTTP有重疊,最明顯的交叉是在流媒體內(nèi)容的發(fā)布上大多是通過(guò)網(wǎng)頁(yè)進(jìn)行的。目前的協(xié)議規(guī)范同時(shí)允 許網(wǎng)頁(yè)服務(wù)器和流媒體服務(wù)器

8、支持RTSP實(shí)現(xiàn)。例如,演示描述可通過(guò)HTTP或RTSP獲取,這樣減少了基于瀏覽器情況下的往返傳遞時(shí)間,同時(shí)也支持獨(dú)立 的RTSP 服務(wù)器與不依賴HTTP的客戶端通信。但是,RTSP與HTTP 的本質(zhì)差別在于以下五個(gè)方面 RTSP和HTTP是兩個(gè)不同的協(xié)議,它們采用不同的方法和協(xié)議標(biāo)志符。 RTSP協(xié)議的數(shù)據(jù)發(fā)送不占用協(xié)議帶寬,并且以不同的協(xié)議發(fā)送。 HTTP是一個(gè)不對(duì)稱協(xié)議,客戶端發(fā)出請(qǐng)求,服務(wù)器應(yīng)答。在RTSP中,客戶端和服務(wù)器都可發(fā)出請(qǐng)求,且請(qǐng)求是有狀態(tài)的。 HTTP是一個(gè)無(wú)狀態(tài)協(xié)議,而RTSP在任何情況下,必須保持一定狀態(tài),以便在請(qǐng)求確認(rèn)后的很長(zhǎng)時(shí)間內(nèi),仍可設(shè)置參數(shù),控制媒體流。 RT

9、SP使用ISO 10646(UTF-8)定義,而不使用ISO 8859-1定義,保持與當(dāng)前的HTML一致。雖然大多數(shù)實(shí)時(shí)媒體采用RTP作為傳輸協(xié)議,但RTSP并不綁定RTP。重用HTTP的功能至少在兩個(gè)方面有好處:安全和代理。由于要求非常接近,因此在緩存、代理和授權(quán)上采用HTTP功能是有 價(jià)值的。RTSP的實(shí)現(xiàn)RTSP功能實(shí)現(xiàn)結(jié)構(gòu)如下圖所示。RTSP在流媒體傳輸過(guò)程中,僅僅為雙方建立連接,并不具備任何智能,也就不能很好地應(yīng)付難以預(yù)料的網(wǎng)絡(luò)狀態(tài)。因此,必須 在它原有功能的基礎(chǔ)上,進(jìn)行改進(jìn)。1、初始化在建立連接之前,客戶端應(yīng)向服務(wù)器提出測(cè)試請(qǐng)求,即要求服務(wù)器向客戶端發(fā)送相應(yīng)的測(cè)試數(shù)據(jù)包。初始化的目

10、的,是為了獲取客 戶端和服務(wù)器之間的一些網(wǎng)絡(luò)參數(shù),估測(cè)基本網(wǎng)絡(luò)狀況,并以此選擇相應(yīng)的網(wǎng)絡(luò)傳輸協(xié)議,使客戶端獲得最佳觀看效果。接到這個(gè)請(qǐng)求之后,服務(wù)器將根據(jù)自身情況進(jìn)行如下測(cè)試: 利用同客戶端建立的RTSP通道,采用TCP協(xié)議,下發(fā)測(cè)試數(shù)據(jù)包。 采用UDP協(xié)議,向客戶端下發(fā)測(cè)試數(shù)據(jù)包。測(cè)試數(shù)據(jù)包僅做測(cè)試用,上面帶有相應(yīng)的時(shí)間和順序信息,其內(nèi)部數(shù)據(jù)并無(wú)任何意義。需要向RTSP增加一個(gè)新的方法TEST,以支持這種傳輸前的測(cè)試工作。2、TCP傳輸如果在TCP測(cè)試中,客戶端反饋良好,即丟包率在可承受范圍之內(nèi),并且在規(guī)定時(shí)間內(nèi)到達(dá),那么就認(rèn)為客戶端同服務(wù)器之間的 網(wǎng)絡(luò)狀況良好, 可以采用RTP over

11、TCP的方式發(fā)送數(shù)據(jù)。由于TCP沒(méi)有丟包(其自身具有重傳機(jī)制),網(wǎng)絡(luò)狀況又屬于良好,因此客戶端將有較高的視聽享受。當(dāng)子網(wǎng)內(nèi)存在防火墻時(shí),就需要采用RTSP附加數(shù)據(jù)傳輸方式。即把音視頻數(shù)據(jù)直接打包,在RTSP通信信道內(nèi)傳輸。這種傳 輸方式也存在一定的問(wèn)題: 傳輸過(guò)程中,只是把音視頻文件當(dāng)成一個(gè)普通文件來(lái)處理,而沒(méi)有考慮到它的音視頻特性,不利于以后的擴(kuò)展。 音頻與視頻文件沒(méi)有分離,不利于某些特殊需求的場(chǎng)合。例如,客戶端需要對(duì)音、視頻做不同的處理。 客戶端的反饋和RTSP的控制信息也是通過(guò)同一條RTSP信道傳送,因此控制效率不高。因此,一般情況下,都默認(rèn)使用RTP over TCP的方式發(fā)送數(shù)據(jù)。3

12、、UDP傳輸如果在TCP測(cè)試中,客戶端的反饋存在比較大的問(wèn)題,即網(wǎng)絡(luò)情況不理想,就應(yīng)該考慮進(jìn)行UDP測(cè)試。目前初步采取的措施,在服務(wù)器端準(zhǔn)備了兩種碼率的視頻文件高碼率和低碼率。收到客戶端的TEST方法后,將采用UDP協(xié)議下發(fā)測(cè)試包。采取的策略是每間隔2秒,下發(fā)一個(gè)1500字節(jié)的UDP數(shù)據(jù) 包。當(dāng)丟包率處于一定范圍(7585)之內(nèi),就認(rèn)為客戶端的網(wǎng)絡(luò)狀況基本良好,可以下發(fā)高碼率的電影文件;否則,認(rèn)為測(cè)試不成功,由于網(wǎng)絡(luò)狀況的限 制,僅對(duì)客戶端下發(fā)低碼率的電影文件。在基于UDP的播放過(guò)程中,可能會(huì)出現(xiàn)輕微的馬賽克,這是完全可以接受的。這些馬賽克出現(xiàn)的主要原因是: 不可靠連接造成的網(wǎng)絡(luò)丟包,為客戶端

13、被動(dòng)丟包。 高質(zhì)量文件(DVD>MP4)的高數(shù)據(jù)量,使得客戶端解碼線程和顯示線程出現(xiàn)擁塞,從而出現(xiàn)客戶端主動(dòng)丟包。但從整體而言,UDP傳輸消耗的帶寬,要比TCP小許多。在一般的視頻點(diǎn)播要求下,使用基于UDP的傳輸線路,是完全可以 滿足要求的。4、傳輸反饋在傳輸過(guò)程中,主要采取的方式是RTP over TCP或RTP over UDP,因此,在RTP端口之外,還存在一個(gè)回傳端口RTCP。在服務(wù)器收到客戶端的RTCP回傳信息后,需要對(duì)其進(jìn)行判斷。如果客戶端的丟包率、解碼率等指標(biāo)在一定限度之下,就認(rèn)為目 前傳送的視頻文件可令客戶端獲得最大程度的音視頻享受;否則,考慮改為傳輸更低碼率的視頻文件或

14、放棄這次RTSP會(huì)話,以避免更大范圍的擁塞。5、實(shí)際效果采取如上方法設(shè)計(jì)的系統(tǒng),可以滿足視頻點(diǎn)播的基本要求,避免了服務(wù)器視頻文件下發(fā)的盲目性,同時(shí)使客戶端應(yīng)用效果最好。引入智能流技術(shù)隨著針對(duì)流媒體技術(shù)研究的不斷深入,簡(jiǎn)單的流媒體實(shí)現(xiàn)已經(jīng)不能滿足人們?nèi)找嬖鲩L(zhǎng)的網(wǎng)絡(luò)文化需求。即使在寬帶條件下,當(dāng)網(wǎng)絡(luò) 用戶達(dá)到一定限額時(shí),簡(jiǎn)單的流媒體技術(shù)將面臨著網(wǎng)絡(luò)擁塞、丟包等常見的網(wǎng)絡(luò)問(wèn)題。因此,如何在網(wǎng)絡(luò)出現(xiàn)異常的情況下,依然保證客戶端音視頻享受的最大化, 就成為現(xiàn)在研究的熱點(diǎn)。一種解決方法是服務(wù)器減少發(fā)送給客戶端的數(shù)據(jù)而阻止再緩沖,在RealSystem 5.0中,這種方法稱為“視頻流瘦化”。這種方法的限制是

15、RealVideo文件必須是一種數(shù)據(jù)速率設(shè)計(jì),結(jié)果可通過(guò)抽取內(nèi)部幀擴(kuò)展到更低速率,導(dǎo)致質(zhì)量 較低,離原始數(shù)據(jù)速率越遠(yuǎn),質(zhì)量越差。另一種解決方法是根據(jù)不同連接速率創(chuàng)建多個(gè)文件,根據(jù)用戶連接,服務(wù)器發(fā)送相應(yīng)文件,這種方法帶來(lái)制作和管理上的困難,而 且,用戶連接是動(dòng)態(tài)變化的,服務(wù)器也無(wú)法實(shí)時(shí)協(xié)調(diào)。智能流技術(shù)通過(guò)兩種途徑克服帶寬協(xié)調(diào)和流瘦化:首先,確立一個(gè)編碼框架,允許不同速率的多個(gè)流同時(shí)編碼,合并到同一個(gè)文件 中;第二,采用一種復(fù)雜客戶/服務(wù)器機(jī)制探測(cè)帶寬變化。針對(duì)軟件、設(shè)備和數(shù)據(jù)傳輸速度上的差別,用戶以不同帶寬瀏覽音視頻內(nèi)容。為滿足客戶要求,Real Networks公司編碼、記錄不同速率下媒體數(shù)

16、據(jù),并保存在單一文件中,此文件被稱為智能流文件,即創(chuàng)建可擴(kuò)展流式文件。當(dāng)客戶端發(fā)出請(qǐng)求時(shí),它將其帶 寬容量傳給服務(wù)器,媒體服務(wù)器根據(jù)客戶帶寬將智能流文件相應(yīng)部分傳送給用戶。以此方式,用戶可使用最優(yōu)質(zhì)的傳輸,制作人員只需要壓縮一次,管理員也只需要 維護(hù)單一文件,而媒體服務(wù)器根據(jù)所得帶寬自動(dòng)切換。智能流通過(guò)描述Internet上變化的帶寬特點(diǎn)來(lái)發(fā)送高質(zhì)量媒體并保證其可靠性,并對(duì)混合連接環(huán)境的 內(nèi)容授權(quán)提供了解決方法。這樣流媒體實(shí)現(xiàn)方式如下:對(duì)所有連接速率環(huán)境創(chuàng)建一個(gè)文件。在混合環(huán)境下以不同速率傳送媒體。根據(jù)網(wǎng)絡(luò)的變化情況,無(wú)縫切換到其 他速率。關(guān)鍵幀優(yōu)先,音頻比部分視頻幀數(shù)據(jù)更重要,向后兼容老版本

17、RealPlayer。端口說(shuō)明:554端口默認(rèn)情況下用于“Real Time Streaming Protocol”(實(shí)時(shí)流協(xié)議,簡(jiǎn)稱RTSP),該協(xié)議是由RealNetworks和Netscape共同提出的,通過(guò)RTSP協(xié)議可以借助于 Internet將流媒體文件傳送到RealPlayer中播放,并能有效地、最大限度地利用有限的網(wǎng)絡(luò)帶寬,傳輸?shù)牧髅襟w文件一般是Real服務(wù)器發(fā)布 的,包括有.rm、.ram。如今,很多的下載軟件都支持RTSP協(xié)議,比如FlashGet、影音傳送帶等等。端口漏洞:目前,RTSP協(xié)議所發(fā)現(xiàn)的漏洞主要就是RealNetworks早期發(fā)布的Helix Universa

18、l Server存在緩沖區(qū)溢出漏洞,相對(duì)來(lái)說(shuō),使用的554端口是安全的。操作建議:為了能欣賞并下載到RTSP協(xié)議的流媒體文件,建議開啟554端口。1024端口端口說(shuō)明:1024端口一般不固定分配給某個(gè)服務(wù),在英文中的解釋是“Reserved”(保留)。之前,我們?cè)?jīng)提到過(guò)動(dòng)態(tài)端口的范圍是從 102465535,而1024正是動(dòng)態(tài)端口的開始。該端口一般分配給第一個(gè)向系統(tǒng)發(fā)出申請(qǐng)的服務(wù),在關(guān)閉服務(wù)的時(shí)候,就會(huì)釋放1024端口,等待其他 服務(wù)的調(diào)用。端口漏洞:著名的YAI木馬病毒默認(rèn)使用的就是1024端口,通過(guò)該木馬可以遠(yuǎn)程控制目標(biāo)計(jì)算機(jī),獲取計(jì)算機(jī)的屏幕圖像、記錄鍵盤事件、獲取密 碼等,后果是比較

19、嚴(yán)重的。操作建議:一般的殺毒軟件都可以方便地進(jìn)行YAI病毒的查殺,所以在確認(rèn)無(wú)YAI病毒的情況下建議開啟該端口。1080端口端口說(shuō)明:1080端口是Socks代理服務(wù)使用的端口,大家平時(shí)上網(wǎng)使用的WWW服務(wù)使用的是HTTP協(xié)議的代理服務(wù)。而Socks代理服務(wù) 不同于HTTP代理服務(wù),它是以通道方式穿越防火墻,可以讓防火墻后面的用戶通過(guò)一個(gè)IP地址訪問(wèn)Internet。Socks代理服務(wù)經(jīng)常被使用在局域 網(wǎng)中,比如限制了QQ,那么就可以打開QQ參數(shù)設(shè)置窗口,選擇“網(wǎng)絡(luò)設(shè)置”,在其中設(shè)置Socks代理服務(wù)(如圖1)。另外,還可以通過(guò)安裝Socks代 理軟件來(lái)使用QQ,比如Socks2HTTP、So

20、cksCap32等。端口漏洞:著名的代理服務(wù)器軟件WinGate默認(rèn)的端口就是1080,通過(guò)該端口來(lái)實(shí)現(xiàn)局域網(wǎng)內(nèi)計(jì)算機(jī)的共享上網(wǎng)。不過(guò),如 Worm.Bugbear.B(怪物II)、Worm.Novarg.B(SCO炸彈變種B)等蠕蟲病毒也會(huì)在本地系統(tǒng)監(jiān)聽1080端口,給計(jì)算機(jī)的安全 帶來(lái)不利。操作建議:除了經(jīng)常使用WinGate來(lái)共享上網(wǎng)外,那么其他的建議關(guān)閉該端口。1755端口端口說(shuō)明:1755端口默認(rèn)情況下用于“Microsoft Media Server”(微軟媒體服務(wù)器,簡(jiǎn)稱MMS),該協(xié)議是由微軟發(fā)布的流媒體協(xié)議,通過(guò)MMS協(xié)議可以在Internet上實(shí)現(xiàn)Windows Media

21、服務(wù)器中流媒體文件的傳送與播放。這些文件包括.asf、.wmv等,可以使用Windows Media Player等媒體播放軟件來(lái)實(shí)時(shí)播放。其中,具體來(lái)講,1755端口又可以分為TCP和UDP的MMS協(xié)議,分別是MMST和MMSU,一般采用TCP 的MMS協(xié)議,即MMST。目前,流媒體和普通下載軟件大部分都支持MMS協(xié)議。端口漏洞:目前從微軟官方和用戶使用MMS協(xié)議傳輸、播放流媒體文件來(lái)看,并沒(méi)有什么特別明顯的漏洞,主要一個(gè)就是MMS協(xié)議與防火墻和 NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)之間存在的兼容性問(wèn)題。操作建議:為了能實(shí)時(shí)播放、下載到MMS協(xié)議的流媒體文件,建議開啟該端口。rtsp和http類似,屬于應(yīng)

22、用層協(xié)議通過(guò)socket rtsp命令來(lái)進(jìn)行通訊。常用控制命令執(zhí)行順序常用的是5個(gè)命令:1,OPTIONS,/詢問(wèn)server,那些命令可用2,DESCRIBE,/請(qǐng)求rtsp路徑的媒體描述信息3,SETUP,/設(shè)置會(huì)話的屬性,以及傳輸模式,建立會(huì)話GET_PARAMETER,/取得流控制參數(shù),可能某些服務(wù)器不支持SET_PARAMETER,/設(shè)置流控制參數(shù),可能某些服務(wù)器不支持4,PLAY,/開始播放流媒體數(shù)據(jù)5,TEARDOWN /關(guān)閉對(duì)話ANNOUNCE, /更新會(huì)話描述PAUSE,/臨時(shí)停止流,而不釋放服務(wù)器資源client有請(qǐng)求(request),server就有應(yīng)答(respons

23、e)一般控制命令基于tcp協(xié)議。媒體數(shù)據(jù)傳輸使用udp。參考http:和rtsp在功能上有相似重疊的地方,RTSP采用了HTTP/1.1 大多數(shù)的狀態(tài)碼,并且增加了RTSP特定的狀態(tài)碼。HTTP協(xié)議定義了8種可能的請(qǐng)求方法:GET 檢索URI中標(biāo)識(shí)資源的一個(gè)簡(jiǎn)單請(qǐng)求HEAD 與GET方法相同,服務(wù)器只返回狀態(tài)行和頭標(biāo),并不返回請(qǐng)求文檔POST 服務(wù)器接受被寫入客戶端輸出流中的數(shù)據(jù)的請(qǐng)求PUT 服務(wù)器保存請(qǐng)求數(shù)據(jù)作為指定URI新內(nèi)容的請(qǐng)求DELETE 服務(wù)器刪除URI中命名的資源的請(qǐng)求OPTIONS 關(guān)于服務(wù)器支持的請(qǐng)求方法信息的請(qǐng)求TRACE Web服務(wù)器反饋Http請(qǐng)求和其頭標(biāo)的請(qǐng)求CONN

24、ECT 已文檔化但當(dāng)前未實(shí)現(xiàn)的一個(gè)方法,預(yù)留做隧道處理rtsp和http的協(xié)議規(guī)范分別在RFC2326 和 RFC2616有詳細(xì)描述mms協(xié)議為微軟的私有協(xié)議,未公開協(xié)議。采用私有自定義控制結(jié)構(gòu)體來(lái)發(fā)送命令,而不是像http,rtsp協(xié)議采用發(fā)送文本命令控制實(shí)時(shí)流協(xié)議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的,該協(xié)議定 義了一 對(duì)多應(yīng)用程序如何有效地通過(guò)IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上,它使用TCP或RTP完成數(shù)據(jù)傳輸。HTTP與 RTSP相比,HTTP傳送HTML,而RTP傳送的是

25、多媒體數(shù)據(jù)。HTTP請(qǐng)求由客戶機(jī)發(fā)出,服務(wù)器作出響應(yīng);使用RTSP時(shí),客戶機(jī)和服務(wù)器都可以發(fā) 出請(qǐng)求,即RTSP可以是雙向的。6.3 RTSP協(xié)議實(shí)時(shí)流協(xié)議(RTSP)是應(yīng)用級(jí)協(xié)議,控制實(shí)時(shí)數(shù)據(jù)的發(fā)送。RTSP提供了一個(gè)可 擴(kuò)展框架,使實(shí)時(shí)數(shù)據(jù),如音頻與視頻,的受控、點(diǎn)播成為可能。數(shù)據(jù)源包括 現(xiàn)場(chǎng)數(shù)據(jù)與存儲(chǔ)在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接,為選擇發(fā)送通道,如UDP、組播UDP與TCP,提供途徑,并為選擇基于RTP上發(fā)送 機(jī)制提供方法。6.3.1 簡(jiǎn)介 目的實(shí)時(shí)流協(xié)議(RTSP)建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體。盡管 連續(xù)媒體流與控制流交叉是可能的,通常它本

26、身并不發(fā)送連續(xù)流。換言之,RTSP充 當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒(méi)有綁定到傳輸層連接,如TCP。在RTSP連接期間,RTSP用戶可打開或關(guān)閉多個(gè)對(duì)服務(wù)器的可靠傳輸連接 以發(fā)出RTSP 請(qǐng)求。此外,可使用無(wú)連接傳輸協(xié)議,如UDP。RTSP流控制的流可能用到RTP,但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機(jī)制。實(shí)時(shí)流協(xié)議在語(yǔ)法 和操作上與HTTP/1.1類似,因此HTTP的擴(kuò)展機(jī)制大都可加入RTSP。協(xié)議支持的操作如下:從媒體服務(wù)器上檢索媒體:用戶可通過(guò)HTTP或其它方法提交一個(gè)演示描述。如演示是組播,演示式就包含用于連續(xù)媒體的的組播地址和端口。如演示僅通過(guò)單播發(fā)送給用戶,用戶

27、為了安全 應(yīng)提供目的地址。媒體服務(wù)器邀請(qǐng)進(jìn)入會(huì)議:媒體服務(wù)器可被邀請(qǐng)參加正進(jìn)行的會(huì)議,或回放媒體,或記錄其中一部分,或全部。這種模式在分布式教育應(yīng)用上很有用,會(huì)議中幾方可輪流按遠(yuǎn)程控制按鈕。將媒體加到現(xiàn)成講座中:如服務(wù)器告訴用戶可獲得附加媒體內(nèi)容,對(duì)現(xiàn)場(chǎng)講座顯得尤其有用。如HTTP/1.1中類似,RTSP請(qǐng)求可由代理、通道與緩存處理。 協(xié)議特點(diǎn)RTSP 特性如下:可擴(kuò)展性:新方法和參數(shù)很容易加入RTSP。易解析:RTSP可由標(biāo)準(zhǔn) HTTP或MIME解吸器解析。安全:RTSP使用網(wǎng)頁(yè)安全機(jī)制。獨(dú)立于傳輸:RTSP可使用不可靠數(shù)據(jù)報(bào)協(xié)議(UDP)、可靠數(shù)據(jù)報(bào)協(xié)議(RDP),如要實(shí)現(xiàn)應(yīng)

28、用級(jí)可靠,可使用可靠流協(xié)議。多服務(wù)器支持:每個(gè)流可放在不同服務(wù)器上,用戶端自動(dòng)同不同服務(wù)器建立幾個(gè)并發(fā)控制連接,媒體同步在傳輸層執(zhí)行。記錄設(shè)備控制:協(xié)議可控制記錄和回放設(shè)備。流控與會(huì)議開始分離:僅要求會(huì)議初始化協(xié)議提供,或可用來(lái)創(chuàng)建唯一會(huì)議標(biāo)識(shí)號(hào)。特殊情況下, SIP或H.323可用來(lái)邀請(qǐng)服務(wù)器入會(huì)。適合專業(yè)應(yīng)用:通過(guò)SMPTE 時(shí)標(biāo),RTSP支持幀級(jí)精度,允許遠(yuǎn)程數(shù)字編輯演示描述中立:協(xié)議沒(méi)強(qiáng)加特殊演示或元文件,可傳送所用格式類型;然而,演示描述至少必須包含一個(gè)RTSP URI。代理與防火墻友好:協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法,為UDP媒體流打開一個(gè)"

29、缺口"。HTTP友好:此處,RTSP明智的采用HTTP觀念,使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Internet 內(nèi)容選擇平臺(tái)(PICS)。由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài), RTSP不僅僅向HTTP 添加方法。適當(dāng)?shù)姆?wù)器控制:如用戶啟動(dòng)一個(gè)流,他必須也可以停止一個(gè)流。傳輸協(xié)調(diào);實(shí)際處理連續(xù)媒體流前,用戶 可協(xié)調(diào)傳輸方法。性能協(xié)調(diào):如基本特征無(wú)效,必須有一些清理機(jī)制讓用戶決定那種方法沒(méi)生效。這允許用戶提出適合的用戶界面。擴(kuò)展RTSP由于不是所有媒體服務(wù)器有著相同的功能,媒體服務(wù)器有必要支持不同請(qǐng)求集。RTSP 可以如下三種方式擴(kuò)展,這里以改變大小排序:以新參數(shù)擴(kuò)展

30、。如用戶需要拒絕通知,而方法擴(kuò)展不支持,相應(yīng)標(biāo)記就加入要求的段中。加入新方法。如信息接收者不理解請(qǐng)求,返回501錯(cuò)誤代碼(還未實(shí)現(xiàn)),發(fā)送者不應(yīng)再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務(wù)器支持的方 法。服務(wù)器使用公共響應(yīng)頭列出支持的方法。定義新版本協(xié)議,允許改變所有部分。(除了協(xié)議版本號(hào)位置)操作模式每個(gè)演示和媒體流可用RTSP URL識(shí)別。演示組成的整個(gè)演示與媒體屬性由演示描述文件定義。使用HTTP或其它途徑用戶可獲得這個(gè)文件,它沒(méi)有必要保存在媒體服務(wù)器上。為了說(shuō)明,假設(shè)演示描述描述了多個(gè)演示,其中每個(gè)演示維持了一個(gè)公共時(shí)間軸。為簡(jiǎn)化說(shuō)明,且不失一般性,假定演示描述

31、的確包含這樣一個(gè)演示。演示可包含多 個(gè)媒體流。除媒體參數(shù)外,網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。下面區(qū)分幾種操作模式:?jiǎn)尾ィ阂杂脩暨x擇的端口號(hào)將媒體發(fā)送到RTSP請(qǐng)求源。組播,服務(wù)器選擇地址:媒體服務(wù)器選擇組播地址和端口,這是現(xiàn)場(chǎng)直播或準(zhǔn)點(diǎn)播常用的方式。組播,用戶選擇地址:如服務(wù)器加入正在進(jìn)行的組播會(huì)議,組播地址、端口和密匙由會(huì)議描述給出。 RTSP狀態(tài)RTSP 控制通過(guò)單獨(dú)協(xié)議發(fā)送的流,與控制通道無(wú)關(guān)。例如,RTSP控制可通過(guò)TCP連接,而數(shù)據(jù)流通過(guò)UDP。因此,即使媒體服務(wù)器沒(méi)有收到請(qǐng)求,數(shù)據(jù) 也會(huì)繼續(xù)發(fā)送。在連接生命期,單個(gè)媒體流可通過(guò)不同TCP連接順序發(fā)出請(qǐng)求來(lái)控制。所以,服務(wù)

32、器需要維持能聯(lián)系流與RTSP請(qǐng)求的連接狀態(tài)。RTSP中很 多方法與狀態(tài)無(wú)關(guān),但下列方法在定義服務(wù)器流資源的分配與應(yīng)用上起著重要的作用:SETUP:讓服務(wù)器給流分配資源,啟動(dòng)RTSP連接。PLAY與RECORD:?jiǎn)?dòng)SETUP 分配流的數(shù)據(jù)傳輸。PAUSE:臨時(shí)停止流,而不釋放服務(wù)器資源。TEARDOWN:釋放流的資源,RTSP連接停止。標(biāo)識(shí)狀態(tài)的RTSP方法使用連接頭段識(shí)別RTSP連接,為響應(yīng)SETUP請(qǐng)求,服務(wù)器連接產(chǎn)生連接標(biāo)識(shí)。 與其他協(xié)議關(guān)系RTSP 在功能上與HTTP有重疊,與HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過(guò)網(wǎng)頁(yè)的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁(yè)服務(wù)器與實(shí)

33、現(xiàn)RTSP媒 體服務(wù)器之間存在不同傳遞點(diǎn)。例如,演示描述可通過(guò)HTTP和RTSP檢索,這降低了瀏覽器的往返傳遞,也允許獨(dú)立RTSP 服務(wù)器與用戶不全依靠HTTP。但是,RTSP與HTTP 的本質(zhì)差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進(jìn)行。HTTP是不對(duì)稱協(xié)議,用戶發(fā)出請(qǐng)求,服務(wù)器作出響應(yīng)。RTSP中,媒體用戶和服務(wù)器都可發(fā)出請(qǐng)求,且其請(qǐng)求都是 無(wú)狀態(tài)的;在請(qǐng)求確認(rèn)后很長(zhǎng)時(shí)間內(nèi),仍可設(shè)置參數(shù),控制媒體流。重用HTTP功能至少在兩個(gè)方面有好處,即安全和代理。要求非常接近,在緩存、代理和授權(quán) 上采用HTTP功能是有價(jià)值的。當(dāng)大多數(shù)實(shí)時(shí)媒體使用RTP作為傳輸協(xié)議時(shí),RTSP沒(méi)有綁定到RTP。RTSP假設(shè)存在演示描

34、述格式可表示包含幾個(gè)媒體流的演示的靜態(tài)與臨時(shí)屬性。6.3.2 協(xié)議參數(shù)6.3.3 RTSP 信息RTSP 是基于文本的協(xié)議,采用ISO 10646 字符集,使用UTF-8編碼方案。行以CRLF中斷,但接收者本身可將CR和LF解釋成行終止符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更容易。由于 參數(shù)的數(shù)量和命令的頻率出現(xiàn)較低,處理效率沒(méi)引起注意。如仔細(xì)研究,文本協(xié)議很容易以腳本語(yǔ)言(如:Tcl、Visual Basic與Perl)實(shí)現(xiàn)研究原型。10646字符集避免敏感字符集切換,但對(duì)應(yīng)用來(lái)說(shuō)不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10xx

35、xxxx.。RTSP信息可通過(guò)任何低層傳輸協(xié)議攜帶。請(qǐng)求包括方法、方法作用于其上的對(duì)象和進(jìn)一步描述方法的參數(shù)。方法也可設(shè)計(jì)為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)。當(dāng)信息體包含在信息中,信息體長(zhǎng)度有 如下因素決定:不管實(shí)體頭段是否出現(xiàn)在信息中,不包括信息體的的響應(yīng)信息總以頭段后第一和空行結(jié)束。如出現(xiàn)內(nèi)容長(zhǎng)度頭段,其值以字節(jié)計(jì),表示信息體長(zhǎng)度。如未出現(xiàn)頭段,其值為零。服務(wù)器關(guān)閉連接。注意:RTSP目前并不支持HTTP/1.1"塊"傳輸編碼,需要有內(nèi)容長(zhǎng)度頭。假如返回適度演示描述長(zhǎng)度,即使動(dòng)態(tài)產(chǎn)生,使塊傳輸編碼沒(méi)有必要,服務(wù)器 也應(yīng)該能決定其長(zhǎng)度。如有實(shí)體,即使必須有內(nèi)容長(zhǎng)度,且

36、長(zhǎng)度沒(méi)顯式給出,規(guī)則可確保行為合理。從用戶到服務(wù)器端的請(qǐng)求信息在第一行內(nèi)包括源采用的方法、源標(biāo)識(shí)和所用協(xié)議版本。RTSP定義了附加狀態(tài)代碼,而沒(méi)有定義任何HTTP代碼。6.3.4 實(shí)體如不受請(qǐng)求方法或響應(yīng)狀態(tài)編碼限制,請(qǐng)求和響應(yīng)信息可傳輸實(shí)體,實(shí)體由實(shí)體頭文件和試題體組成,有些響應(yīng)僅包括實(shí)體頭。在此,根據(jù)誰(shuí)發(fā)送實(shí)體、誰(shuí)接收實(shí) 體,發(fā)送者和接收者可分別指用戶和服務(wù)器。實(shí)體頭定義實(shí)體體可選元信息,如沒(méi)有實(shí)體體,指請(qǐng)求標(biāo)識(shí)的資源。擴(kuò)展頭機(jī)制允許定義附加實(shí)體頭段,而不用改變協(xié)議,但這些段不能假定接收者能識(shí)別。不可識(shí) 別頭段應(yīng)被接收者忽略,而讓代理轉(zhuǎn)發(fā)。6.3.5 連接RTSP請(qǐng)求可以幾種不同方式傳送:1、持久傳輸連接,用于多個(gè)請(qǐng)求/響應(yīng)傳輸。2、每個(gè)請(qǐng)求/響應(yīng)傳輸一個(gè)連接。3、無(wú)

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論