嗅探器的設(shè)計與實現(xiàn)

1、 目錄1、 問題背景概述二、協(xié)議分析說明分析 2.1 RTSP 總結(jié)2.2 MMS總結(jié)2.3 RTSP總結(jié)三、技術(shù)綜述報告四、前景展望1、 問題背景概述 流媒體指在Internet/Intranet中使用流式傳輸技術(shù)的連續(xù)時基媒體，如：音頻、視頻或多媒體文件。流式媒體在播放前并不下載整個文件，只將開始部分內(nèi)容存入內(nèi)存，流式媒體的數(shù)據(jù)流隨時傳送隨時播放，只是在開始時有一些延遲。流媒體實現(xiàn)的關(guān)鍵技術(shù)就是流式傳輸。 常見的流媒體協(xié)議有以下幾種：1、RTMP（RealTime Messaging Protocol），這是Adobe公司開發(fā)的流媒體傳輸協(xié)議，使用Flash Media Server來搭建

2、。2、MMS（Media Server Protocol,MMS），這是微軟定義的一種流媒體傳輸協(xié)議，可使用WIndows Media Server搭建。3、即時串流通訊協(xié)議（Real Time Streaming Protocol，RTSP），它是RealNetworks公司協(xié)助建立的一個用來傳送串流媒體的開放網(wǎng)頁標(biāo)準(zhǔn)，使用RealServer服務(wù)器搭建環(huán)境。二、協(xié)議分析說明分析 2.1RTSP 總結(jié) Real Time .1 RMessaging Protocol（實時消息傳送協(xié)議協(xié)議)概述實時消息傳送協(xié)議是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸開

3、發(fā)的私有協(xié)議。它有三種變種：1)工作在TCP之上的明文協(xié)議，使用端口1935；2)RTMPT封裝在HTTP請求之中，可穿越防火墻；3)RTMPS類似RTMPT，但使用的是HTTPS連接；介紹:RTMP協(xié)議是被Flash用于對象,視頻,音頻的傳輸.該協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上.RTMP協(xié)議就像一個用來裝數(shù)據(jù)包的容器,這些數(shù)據(jù)可以是AMF格式的數(shù)據(jù),也可以是FLV中的視/音頻數(shù)據(jù).一個單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流.這些通道中的包都是按照固定大小的包傳輸?shù)? 下面的文檔詳細(xì)說明了RTMP 消息塊流。它位高層多媒體流協(xié)議提供多路技術(shù)和包服務(wù)RTMP 消息塊流是為RTMP

4、 協(xié)議設(shè)計的。他可以處理任何傳送消息流的協(xié)議。每一個消息包含時間戳合有效負(fù)載類型標(biāo)示。RTMP 消息塊流和RTMP 一起適用于多樣性音視頻應(yīng)用程序，從一對一和一對多向視頻點播服務(wù)器直接廣播到交互式會議應(yīng)用程序。 當(dāng)用到實時傳輸協(xié)議就像TCP，RTMP 消息塊流提供可靠地規(guī)則時間戳的端到端全信息傳送。穿過多層流，RTMP 消息塊流不提供任何控制的優(yōu)先級別和相似形式，但是可以用于高層協(xié)議提供這樣的優(yōu)先級。例如，一段實時視頻服務(wù)會選擇丟棄給于緩慢的客戶的視頻信息確保音頻信息可以及時被接收。RTMP 消息塊流包含它自己的入隊協(xié)議控制消息，也提供一個高層協(xié)議機(jī)制用于嵌入用戶的控制消息。2. 定義 有效負(fù)

5、載 包含在包中的數(shù)據(jù)，就像音頻樣本或者壓縮的視頻數(shù)據(jù)。 包： 一個數(shù)據(jù)包由固定的包頭和有效負(fù)載數(shù)據(jù)組成，一些底層協(xié)議或許需要包的封裝來被定義 端口： 在TCP/P 協(xié)議中定義的用正整數(shù)表示的端口號用于在傳輸中提取以區(qū)分目標(biāo)主機(jī)的不同應(yīng)用于OSI 傳輸層的傳輸選擇。TSEL就是端口。 傳輸?shù)刂罚?網(wǎng)絡(luò)地址和端口的組合識別一個傳輸層終端端口。例如一個IP 地址和TCP 端口。數(shù)據(jù)包從一個源傳：輸層地址傳送到目標(biāo)段的傳輸層地址。 消息流：一個通信的邏輯通道，允許消息流通。 消息流ID：􀈍每一個消息擁有一個分配的ID 識別跟隨的消息流。 消息快：消息的片段，消息被分成小的部分。在他們

6、在網(wǎng)絡(luò)中發(fā)送之前交叉存儲。消息塊確保定制時間戳的端到端全消息傳送穿過多層流。 消息塊流：一個通信的邏輯通道允許消息塊在一個特定的方向上流通，消息塊流可以從客戶端傳送到服務(wù)器也可以相反。 消息塊流ID:每一個消息塊有一個分配的ID 用于識別更隨的消息塊流。 復(fù)合技術(shù):把分開的音視頻數(shù)據(jù)組合成一條音視頻流的過程，使同時傳送許多音視頻數(shù)據(jù)成為可能。 逆復(fù)合技術(shù):復(fù)合的反向過程交叉存取組裝的音頻視頻數(shù)據(jù)，使他們成為最初的音視頻數(shù)據(jù)3􀈅 字節(jié)順序，列隊和時間格式所有的整數(shù)字段有被網(wǎng)絡(luò)字節(jié)負(fù)載著，字節(jié)0 是第一個顯示出來的.也是一段文字和字段中最重要的。這種字節(jié)順序一般被認(rèn)為“大字節(jié)”.

7、數(shù)字常量在這種文檔里是用十進(jìn)制表示。 所有RTMP 消息塊流是以用字節(jié)列隊，例如，一個16 字節(jié)的字段也許會在字?jǐn)?shù)字節(jié)的偏移段。那里要填充被標(biāo)示.填充字節(jié)應(yīng)該有0 值。 在RTMP 消息塊流中的時間戳用整數(shù)表示，單位為毫秒。每一個消息塊流以時間戳0 開始但是這不是必須的，只要兩個終端在時間點上達(dá)成一致，注意那就意味著任何穿過多消息塊流異步傳輸(特別是分散的主機(jī)).在RTMP 消息塊流之外需要一些而外的機(jī)制。 時間戳必須始終在線性的增加，允許應(yīng)用程序處理異步傳輸，帶寬度量，檢測和流控制。 因為時間戳一般是只有32 字節(jié)的長度，他們周期小于50 天，因為六流是允許不停地流動的，最終可以運行幾年。一

8、個RTMP 消息塊流應(yīng)用必須用到模運算用于相減和比較，任何合理的方式都可以被接受，只要兩端都達(dá)成一致。一個應(yīng)用可以假設(shè)，例如，所有相近的時間戳在2 的31 次方以內(nèi)。所以10000 在4000000000 后面.3000000000 在4000000000 前面。 時間戳delta 作為一個表示毫秒的無符號整數(shù)也會被詳細(xì)介紹，和先前的時間戳相比，時間戳delta 可以是24 字節(jié)或者是32 字節(jié)的長度4。􀈅 消息格式： 一個消息的格式可以分裂成消息塊以支持復(fù)用，依靠高層協(xié)議，消息格式應(yīng)該包含創(chuàng)造消息塊的必須字段。 時間戳： 消息的時間戳，這個字段可以傳輸4 個字節(jié)。 長度：

9、消息的有效負(fù)載的長度，如果消息頭不能被省略，他應(yīng)該包含在長度中，這個字段在消息塊包頭中占有3 個字節(jié)。 類型ID：􀈍 協(xié)議控制消息的類型字段的范圍是被保留的，這些傳播信息的消息被RTMP 消息塊和高層協(xié)議處理。所有其他的類型ID 可被高層協(xié)議使用，被RTMP 消息塊當(dāng)做不透明的值事實上在RTMP 消息塊中需要這些值當(dāng)做類型的是沒有的，所有的消息可以成為通一種類型?；蛘邞?yīng)用程序用這個字段區(qū)分同步跡象而不是類型，這個字段占用1 個字節(jié)。 消息流ID: 消息流ID 可以是任意值，不同的消息復(fù)合依靠的同樣的消息塊流是基于他們的消息流ID 被逆復(fù)合而成的，在此之上，直到RTMP 消息塊

10、被關(guān)注，這是一個不透明的值，這個字段在包頭中占用4 個字節(jié)。5􀈅 握手 一個RTMP 通信以握手開始，握手不像其他的協(xié)議，他包含三個固定長度的消息塊。客戶（初始化通信的終端）和服務(wù)器每放發(fā)送同樣的三個消息塊，說明一下，被客戶段發(fā)送的消息塊被指定為C0，C1，C2，被服務(wù)器端發(fā)送的消息被指定為S0，S1，S2。2.2 MMS總結(jié) MMS (Microsoft Media Server Protocol)，中文“微軟媒體服務(wù)器協(xié)議”，用來訪問并流式接收 Windows Media 服務(wù)器中 .asf 文件的一種協(xié)議。MMS 協(xié)議用于訪問 Windows Media 發(fā)布點上的單播

11、內(nèi)容。MMS 是連接 Windows Media 單播服務(wù)的默認(rèn)方法。若觀眾在 Windows Media Player 中鍵入一個 URL 以連接內(nèi)容，而不是通過超級鏈接訪問內(nèi)容，則他們必須使用MMS 協(xié)議引用該流。MMS的預(yù)設(shè)埠（端口）是1755。 當(dāng)使用 MMS 協(xié)議連接到發(fā)布點時，使用協(xié)議翻轉(zhuǎn)以獲得最佳連接。“協(xié)議翻轉(zhuǎn)”始于試圖通過 MMSU 連接客戶端。 MMSU 是 MMS 協(xié)議結(jié)合 UDP 數(shù)據(jù)傳送。如果 MMSU 連接不成功，則服務(wù)器試圖使用 MMST。MMST 是 MMS 協(xié)議結(jié)合 TCP 數(shù)據(jù)傳送。 如果連接到編入索引的 .asf 文件，想要快進(jìn)、后退、暫停、開始和停止流，

12、則必須使用 MMS。不能用 UNC 路徑快進(jìn)或后退。若您從獨立的 Windows Media Player 連接到發(fā)布點，則必須指定單播內(nèi)容的 URL。若內(nèi)容在主發(fā)布點點播發(fā)布，則 URL 由服務(wù)器名和 .asf 文件名組成。例如：mms:/windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務(wù)器名，sample.asf 是您想要使之轉(zhuǎn)化為流的 .asf 文件名。 若您有實時內(nèi)容要通過廣播單播發(fā)布，則該 URL 由服務(wù)器名和發(fā)布點別名組成。例如：mms:/windows_media_server/Li

13、veEvents。這里 windows_media_server 是 Windows Media 服務(wù)器名，而 LiveEvents 是發(fā)布點名。 MMS是Multimedia Messaging Service的縮寫，中文譯為多媒體信息服務(wù)，也稱“彩信”，是按照3GPP的標(biāo)準(zhǔn)也是WAP論壇的標(biāo)準(zhǔn)有關(guān)多媒體信息的標(biāo)準(zhǔn)開發(fā)的最新業(yè)務(wù)，它最大的特色就是支持多媒體功能，可以在GPRS、CDMA 1X、3G、EDGE的支持下，以WAP無線應(yīng)用協(xié)議為載體傳送視頻短片、圖片、聲音和文字，傳送方式除了在手機(jī)間傳送外，還可以是手機(jī)與電腦之間的傳送。具有MMS功能的移動電話的獨特之處在于其內(nèi)置的媒體編輯器，使用

14、戶可以很方便地編寫多媒體信息。如果手機(jī)具有一個內(nèi)置或外置的照相機(jī)，用戶便可以制作出PowerPoint格式的信息或電子明信片，并把他們傳送給朋友或同事。目前，這一應(yīng)用服務(wù)已逐漸走向成熟，成為主流的短信格式。2.3 RTSP總結(jié) RTSP（Real Time Streaming Protocol），實時流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個應(yīng)用層協(xié)議，由哥倫比亞大學(xué)、網(wǎng)景和RealNetworks公司提交的IETF RFC標(biāo)準(zhǔn)。該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或RTP完成數(shù)據(jù)傳輸。HTTP與RTSP相比

15、，HTTP傳送HTML，而RTSP傳送的是多媒體數(shù)據(jù)。HTTP請求由客戶機(jī)發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時，客戶機(jī)和服務(wù)器都可以發(fā)出請求，即RTSP可以是雙向的。 概念RTSP是用來控制聲音或影像的多媒體串流協(xié)議，并允許同時多個串流需求控制，傳輸時所用的網(wǎng)絡(luò)通訊協(xié)定并不在其定義的范圍內(nèi)，服務(wù)器端可以自行選擇使用TCP或UDP來傳送串流內(nèi)容，它的語法和運作跟HTTP 1.1類似，但并不特別強(qiáng)調(diào)時間同步，所以比較能容忍網(wǎng) RTSP絡(luò)延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低服務(wù)器端的網(wǎng)絡(luò)用量，更進(jìn)而支持多方視訊會議（Video Conference）。因為與

16、HTTP1.1的運作方式相似，所以代理服務(wù)器Proxy的快取功能Cache也同樣適用于RTSP，并因RTSP具有重新導(dǎo)向功能，可視實際負(fù)載情況來轉(zhuǎn)換提供服務(wù)的服務(wù)器，以避免過大的負(fù)載集中于同一服務(wù)器而造成延遲。 簡介該協(xié)議用于C/S模型，是一個基于文本的協(xié)議，用于在客戶端和服務(wù)器端建立和協(xié)商實時流會話。 實時流協(xié)議（RTSP）是應(yīng)用級協(xié)議，控制實時數(shù)據(jù)的發(fā)送。RTSP提供了一個可擴(kuò)展框架，使實時數(shù)據(jù)，如音頻與視頻的受控點播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發(fā)送機(jī)制提供方

17、法。 實時流協(xié)議（RTSP）建立并控制一個或幾個時間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交換是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關(guān)閉多個對服務(wù)器的可傳輸連接以發(fā)出RTSP請求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機(jī)制。 協(xié)議支持的操作如下： (1）從媒體服務(wù)器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續(xù)媒體的的組播地址和端口。如演示僅

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

19、）、可靠數(shù)據(jù)報協(xié)議（RDP）；如要實現(xiàn)應(yīng)用級可靠，可使用可靠流協(xié)議。 (5) 多服務(wù)器支持：每個流可放在不同服務(wù)器上，用戶端自動與不同服務(wù)器建立幾個并發(fā)控制連接，媒體同步在傳輸層執(zhí)行。 (6) 記錄設(shè)備控制：協(xié)議可控制記錄和回放設(shè)備。 (7) 流控與會議開始分離：僅要求會議初始化協(xié)議提供，或可用來創(chuàng)建惟一會議標(biāo)識號。特殊情況下，可用SIP或H.323來邀請服務(wù)器入會。 (8) 適合專業(yè)應(yīng)用：通過SMPTE時標(biāo)，RTSP支持幀級精度，允許遠(yuǎn)程數(shù)字編輯。 (9) 演示描述中立：協(xié)議沒強(qiáng)加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包括一個RTSP URL。 (10) 代理與防火墻友

20、好：協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個“缺口”。 (11) HTTP友好：此處，RTSP明智地采用HTTP觀念，使現(xiàn)在結(jié)構(gòu)都可重用。結(jié)構(gòu)包括Internet內(nèi)容選擇平臺（PICS）。由于在大多數(shù)情況下控制連續(xù)媒體需要服務(wù)器狀態(tài)，RTSP不僅僅向HTFP添加方法。 (12) 適當(dāng)?shù)姆?wù)器控制：如用戶啟動一個流，必須也可以停止一個流。 (13) 傳輸協(xié)調(diào)：實際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。 (14) 性能協(xié)調(diào)：如基本特征無效，必須有一些清理機(jī)制讓用戶決定哪種方法沒生效。這允許用戶提出適合的用戶界面。 協(xié)議結(jié)構(gòu)RTSP是一種文本協(xié)議，采用UT

21、F-8編碼中的ISO 10646字符集。一行可通過CRLF終止，但接收端需要做好解釋CR和LF作為一行終止符的準(zhǔn)備。關(guān)于頭字段概述如下： Header Type Support Methods Accept R opt. entity Accept-EncodingR opt. entity Accept-Language R opt. all AllowR opt. all Authorization R opt. all Bandwidth R opt. all Blocksize R opt. All but OPTIONS,TEARDOWN Cache-Control G opt. S

22、ETUP Conference R opt. SETUP Connection G req. all Content-Base E opt. entity Content-Encoding E req. SET_PARAMETER Content-Encoding Ereq. DESCRIBE,ANNOUNCE Content-Language E req. DESCRIBE,ANNOUNCE Content-Length Ereq. SET_PARAMETER,ANNOUNCE Content-Length E req. entity Content-Location E opt. enti

23、ty Content-Type E req. SET_PARAMETER,ANNOUNCE Content-Type R req. entity CSeq G req. all Date G opt. all Expires E opt. DESCRIBE,ANNOUNCE From R opt. all If-Modified-Since R opt. DESCRIBE,SETUP Last-Modified E opt. entity Proxy-Authenticate Proxy-Require R req. all Public R opt. all Range R opt. PLA

24、Y,PAUSE,RECORD Range R opt. PLAY,PAUSE,RECORD Referer R opt. all Require R req. all Retry-After R opt. all RTP-Info R req. PLAY Scale Rr opt. PLAY,RECORD SessionRr req. All but SETUP,OPTIONS Server R opt. all Speed Rr opt. PLAY Transport Rr req. SETUP UnsupportedR req. all User-AgentR opt. all ViaG

25、opt. all WWW-AuthenticateR opt. all 類型"g"表示請求和響應(yīng)中的通用請求頭；類型“R”表示請求頭；類型“r”表示響應(yīng)頭；類型"e"表示實體頭字段。在“support”一欄中標(biāo)有“req.”的字段必須由接收者以特殊的方法實現(xiàn)；而“opt.”的字段是可選的。注意，不是所有“req.”字段在該類型的每個請求中都會被發(fā)送?！皉eq.”只表示客戶機(jī)（支持響應(yīng)頭）和服務(wù)器（支持請求頭）必須執(zhí)行該字段。最后一欄列出了關(guān)于頭字段產(chǎn)生作用的方法；其中“entity”針對于返回一個信息主體的所有方法。 協(xié)議參數(shù)1RTSP版本 H.321采

26、用，用RTSP代替HTTP。 2RTSPURL “rksp"和“rtspu"方案用于指RTSP協(xié)議使用的網(wǎng)絡(luò)資源，為RTSP URL定義方案特定的語法和語義。 3會議標(biāo)識 會議標(biāo)識對RTSP來說是模糊的，采用標(biāo)準(zhǔn)URI編碼方法編碼，可包含任何八位組數(shù)值。會議標(biāo)識必須全局惟一。 4連接標(biāo)識 連接標(biāo)識是長度不確定的字符串，必須隨機(jī)選擇，至少要8個八位組長，使其很難被猜出。 5SMPTE相關(guān)時標(biāo) SMPTE相關(guān)時標(biāo)表示相對剪輯開始的時間，相關(guān)時標(biāo)表示成SMPTE時間代碼，精確到幀級。時間代碼格式為小時：分鐘：秒：幀。缺省smpte格式是"SMPTE 30"，幀

27、速率為每秒29.97幀。其他SMPTE代碼可選擇使用smpte時間獲得支持（如"SMPIE 25")。時間數(shù)值中幀段值可從0到29。每秒30與29.97幀的差別可將每分鐘的頭兩幀丟掉來實現(xiàn)。如幀值為零，就可刪除。 6正常播放時間 正常播放時間（NPT）表示相對演示開始的流絕對位置。時標(biāo)由十進(jìn)制分?jǐn)?shù)組成。左邊部分用秒或小時、分鐘、秒表示；小數(shù)點右邊部分表示秒的部分。演示的開始對應(yīng)0.0秒，負(fù)數(shù)沒有定義。特殊常數(shù)定義成現(xiàn)場事件的當(dāng)前時刻，這也許只用于現(xiàn)場事件。直觀上，NPT是聯(lián)系觀看者與程序的時鐘，通常以數(shù)字式顯示在VCR上。 7絕對時間 絕對時間表示成ISO 8601時標(biāo)，采

28、用UTC(GMT）。 8可選標(biāo)簽 可選標(biāo)簽是用于指定RTSP新可選項的惟一標(biāo)記。這些標(biāo)記用在請求和代理-請求頭段。當(dāng)?shù)怯浶翿TSP選項時，需提供下列信息： （1）名稱和描述選項。名稱長度不限，但不應(yīng)該多于20個字符。名稱不能包括空格、控制字符。 （2）表明誰改變選項的控制。如IETF，ISO，ITU-T，或其他國際標(biāo)準(zhǔn)團(tuán)體、聯(lián)盟或公司。 （3）深入描述的參考，如RFC、論文、專利、技術(shù)報告、文檔源碼和計算機(jī)手冊。 （4）對專用選項，附上聯(lián)系方式。 RTSP信息RTSP是基于文本的協(xié)議，采用ISO 10646字符集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止

29、符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更容易。由于參數(shù)的數(shù)量和命令的頻率出現(xiàn)較低，處理效率沒引起注意。文本協(xié)議很容易以腳本語言（如：Tcl，Visual Basic與Perl）實現(xiàn)研究原型。 ISO 10646字符集避免敏感字符集切換，但對應(yīng)用來說不可見。RTCP也采用這種編碼方案。帶有重要意義位的ISO 8859-1字符表示如100001x 10x x x x x x。RTSP信息可通過任何低層傳輸協(xié)議攜帶。 請求包括方法、方法作用于其上的對象以及進(jìn)一步描述方法的參數(shù)。方法也可設(shè)計為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)。當(dāng)信息體包含在信息中，信息體長度由如下因素決定： (1）不管實體頭

30、段是否出現(xiàn)在信息中，不包括信息體的響應(yīng)，信息總以頭段后第一個空行結(jié)束。 (2）如出現(xiàn)內(nèi)容長度頭段，其值以字節(jié)計，表示信息體長度。如未出現(xiàn)頭段，其值為零。 (3）服務(wù)器關(guān)閉連接。 注意，RTSP目前并不支持HTTP 1.1“塊”傳輸編碼，需要有內(nèi)容長度頭。假如返回適度演示描述長度，即使動態(tài)產(chǎn)生，使塊傳輸編碼沒有必要，服務(wù)器也應(yīng)該能決定其長度。如有實體，即使必須有內(nèi)容長度，且長度沒顯式給出，規(guī)則可確保行為合理。 從用戶到服務(wù)器端的請求信息在第一行內(nèi)包括源采用的方法、源標(biāo)識和所用協(xié)議版本。RTSP定義了附加狀態(tài)代碼，但沒有定義任何HTTP代碼。 RTSP實體如不受請求方法或響應(yīng)狀態(tài)編碼限制，請求和響

31、應(yīng)信息可傳輸實體，實體則由實體頭文件和實體體組成，有些響應(yīng)僅包括實體頭。在此，根據(jù)誰發(fā)送實體、誰接收實體，發(fā)送者和接收者可分別指用戶和服務(wù)器。 實體頭定義實體體可選元信息，如沒有實體體，指請求標(biāo)識的資源。擴(kuò)展頭機(jī)制允許定義附加實體頭段，而不用改變協(xié)議，但這些段不能假定接收者能識別。不可識別頭段應(yīng)被接收者忽略，而讓代理轉(zhuǎn)發(fā)。 連接RTSP請求可以幾種不同方式傳送： ·持久傳輸連接，用于多個請求/響應(yīng)傳輸。 ·每個請求/響應(yīng)傳輸一個連接。 ·無連接模式。 傳輸連接類型由RTSP URL來定義。對“rtsp'方案，需要持續(xù)連接；而"rtspu"

32、;方案，調(diào)用RTSP請求發(fā)送，而不用建立連接。 不像HTTP，RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請求。然而，這僅在持久連接時才支持，否則媒體服務(wù)器沒有可靠途徑到達(dá)用戶，這也是請求通過防火墻從媒體服務(wù)器傳到用戶的惟一途徑。 流水線操作支持持久連接或無連接的客戶端可能給其請求排隊。服務(wù)器必須以收到請求的同樣順序發(fā)出響應(yīng)。如果請求不是發(fā)送給多播組，接收者就確認(rèn)請求，如沒有確認(rèn)信息，發(fā)送者可在超過一個來回時間（RTT）后重發(fā)同一信息。 在TCP中RTT估計的初始值為500ms。應(yīng)用緩存最后所測量的RTT，作為將來連接的初始值。如使用一個可靠傳輸協(xié)議傳輸RTSP，請求不允許重發(fā)，RTSP應(yīng)用反過來依賴

33、低層傳輸提供可靠性。如兩個低層可靠傳輸（如TCP和RTSP）應(yīng)用重發(fā)請求，有可能每個包損失導(dǎo)致兩次重傳。由于傳輸棧在第一次嘗試到達(dá)接收者前不會發(fā)送應(yīng)用層重傳，接收者也不能充分利用應(yīng)用層重傳。如包損失由阻塞引起，不同層的重發(fā)將使阻塞進(jìn)一步惡化。時標(biāo)頭用來避免重發(fā)模糊性問題，避免對圓錐算法的依賴。每個請求在CSeq頭中攜帶一個系列號，每發(fā)送一個不同請求，它就加一。如由于沒有確認(rèn)而重發(fā)請求，請求必須攜帶初始系列號。 實現(xiàn)RTSP的系統(tǒng)必須支持通過TCP傳輸RTSP，并支持UDP。對UDP和TCP，RTSP服務(wù)器的缺省端口都是554。許多目的一致的RTSP包被打包成單個低層PDU或TCP流。RTSP數(shù)

34、據(jù)可與RTP和RTCP包交叉。不像HTTP，RTSP信息必須包含一個內(nèi)容長度頭，無論信息何時包含負(fù)載。否則，RTSP包以空行結(jié)束，后跟最后一個信息頭。 擴(kuò)展RTSP由于不是所有媒體服務(wù)器有著相同的功能，媒體服務(wù)器有必要支持不同請求集。RTSP可以如下三種方式擴(kuò)展： (1) 以新參數(shù)擴(kuò)展。如用戶需要拒絕通知，而方法擴(kuò)展不支持，相應(yīng)標(biāo)記就加入要求的段中。 (2) 加入新方法。如信息接收者不理解請求，返回501錯誤代碼，發(fā)送者不應(yīng)再次嘗試這種方法。用戶可使用OPTIONS方法查詢服務(wù)器支持的方法。服務(wù)器使用公共響應(yīng)頭列出支持的方法。 (3) 定義新版本協(xié)議，允許改變所有部分（協(xié)議版本號位置除外）。

35、操作模式每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其他途徑用戶可獲得這個文件，它沒有必要保存在媒體服務(wù)器上。為了說明這個問題，假設(shè)演示描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參數(shù)外，網(wǎng)絡(luò)目標(biāo)地址和端口也需要決定。 下面區(qū)分幾種操作模式。 (1）單播：用戶選擇的端口號將媒體發(fā)送到RTSP請求源。 (2）服務(wù)器選擇地址多播：媒體服務(wù)器選擇多播地址和端口，這是現(xiàn)場直播或準(zhǔn)點播常用的方式。 (3）用戶選擇地址多播：如服務(wù)器加入正在進(jìn)行的多播會議

36、，多播地址、端口和密鑰由會議描述給出。 RTSP狀態(tài)RTSP控制通過單獨協(xié)議發(fā)送的流，與控制通道無關(guān)。例如，RTSP控制可通過TCP連接，而數(shù)據(jù)流通過UDP。因此，即使媒體服務(wù)器沒有收到請求，數(shù)據(jù)也會繼續(xù)發(fā)送。在連接生命期，單個媒體流可通過不同TCP連接順序發(fā)出請求來控制。所以，服務(wù)器需要維持能聯(lián)系流與RTSP請求的連接狀態(tài)。RTSP中很多方法與狀態(tài)無關(guān)，但下列方法在定義服務(wù)器流資源的分配與應(yīng)用上起著重要的作用： (1) SETUP：讓服務(wù)器給流分配資源，啟動RTSP連接。 (2) PLAY與RECORD：啟動SETUP分配流的數(shù)據(jù)傳輸。 (3) PAUSE：臨時停止流，而不釋放服務(wù)器資源。

37、(4) TEARDOWN：釋放流的資源，RTSP連接停止。 標(biāo)識狀態(tài)的RTSP方法使用連接頭段識別RTSP連接，為響應(yīng)SETUP請求，服務(wù)器連接產(chǎn)生連接標(biāo)識。 與其他協(xié)議的關(guān)系實時流協(xié)議在語法和操作上與HTTP/1.1類似，因此HTTP的擴(kuò)展機(jī)制大都可加入RTSP。然而，在很多重要方面RTSP仍不同于HTTP： RTSP引入了大量新方法并具有一個不同的協(xié)議標(biāo)識符； 在大多數(shù)情況下，RTSP服務(wù)器需要保持缺省狀態(tài)，與HTTP的無狀態(tài)相對； RTSP中客戶端和服務(wù)器都可以發(fā)出請求； 在多數(shù)情況下，數(shù)據(jù)由不同的協(xié)議傳輸； RTSP使用ISO 10646（UTF-8）而并非ISO 8859-1，與當(dāng)前

38、的國際標(biāo)準(zhǔn)HTML相一致； URI請求總是包含絕對URI。為了與過去的錯誤相互兼容，HTTP/1.1只在請求過程中傳送絕對路徑并將主機(jī)名置于另外的頭字段。 RTSP在功能上與HTTP有重疊，與HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過網(wǎng)頁的。目前的協(xié)議規(guī)范目的在于允許在網(wǎng)頁服務(wù)器與實現(xiàn)RTSP媒體服務(wù)器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP服務(wù)器與用戶不全依靠HTTP。 但是，RTSP與HTTP的本質(zhì)差別在于數(shù)據(jù)發(fā)送以不同協(xié)議進(jìn)行。HTTP是不對稱協(xié)議，用戶發(fā)出請求，服務(wù)器作出響應(yīng)。RTSP中，媒體用戶和服務(wù)器都可發(fā)出請

39、求，且其請求都是無狀態(tài)的；在請求確認(rèn)后很長時間內(nèi)，仍可設(shè)置參數(shù)，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近時，在緩存、代理和授權(quán)上采用HTTP功能是有價值的。 當(dāng)大多數(shù)實時媒體使用RTP作為傳輸協(xié)議時，RTSP沒有綁定到RTP。RTSP假設(shè)存在演示描述格式可表示包含幾個媒體流的演示的靜態(tài)與臨時屬性。 微軟與RTSP簡述RTSP并非只是微軟在用！這是一個公開的規(guī)范，在這個規(guī)范上開發(fā)了很多的流服務(wù)器。甚至Linux服務(wù)提供者和蘋果的程序員也使用rtsp協(xié)議以及Real Networks流媒體。似乎整個世界的網(wǎng)絡(luò)流傳輸都用這個協(xié)議。然而，微軟并不只在rtsp上有所作

40、為。 微軟和RTSP 在寫這個文檔的時候，微軟正處于從首選MMS協(xié)議轉(zhuǎn)換到首選采用RTSP協(xié)議的過程中。這個說明在Media Player 9.0版本和流媒體服務(wù)器2003版本之后，我們會看到微軟將rtsp協(xié)議作為流媒體傳輸?shù)闹饕獏f(xié)議。 隨著時間慢慢的流逝，我們會發(fā)現(xiàn)mms協(xié)議正逐步走出人們的視野。It is only assumed that this is so MS can say they are being open with their protocols (rtsp is an open standard) while at the same time disregarding

41、the need to publicise their own MMS protocol once its gone from media player. 然而，mms還沒有真的死亡，至少在接下來的幾年中我們依然可以看到它在流媒體傳輸中的身影。 是否微軟的RTSP協(xié)議和標(biāo)準(zhǔn)的開放式RTSP不同？ 是的。跟在RFC2326（1998年四月）中定義的原始RTSP協(xié)議相比，微軟的rtsp協(xié)議有一些輕微的改動。我們網(wǎng)站上有本文檔（還有后續(xù)版本）和一個簡單的研究，它們可以幫助你了解這些信息。 區(qū)別微軟的rtsp規(guī)范與標(biāo)準(zhǔn)rtsp協(xié)議相比最主要的改動是發(fā)送包payloads到客戶端的方式，另外還有一些請求

42、命令有一些改動。傳輸單個媒體包的機(jī)制并沒有文檔（就我目前所知），這可能是微軟要保留的信息。就像MMS和HTTP 1.0流協(xié)議使用一個媒體數(shù)據(jù)包頭一樣，RTSP也有。但是微軟的數(shù)據(jù)包頭格式?jīng)]有在任何的rtsp文檔中注明。在企圖連接微軟的rtsp服務(wù)器時，這是主要的問題。 微軟RTSP協(xié)議的命令采用的語法和標(biāo)準(zhǔn)rtsp協(xié)議的命令語法一樣，只有一些小的修改和添加，可以通過閱讀網(wǎng)上的一些文檔，就可以知道怎么去組成這些命令。微軟rtsp命令部分已經(jīng)有文檔了。3、 技術(shù)綜述報告 隨著Internet的迅猛發(fā)展，流媒體技術(shù)已經(jīng)廣泛應(yīng)用于新聞發(fā)布、廣播電視、教育、金融、視頻會議、安防等領(lǐng)域，對人們的工作及生活

43、方式產(chǎn)生深遠(yuǎn)的影響。本文通過對現(xiàn)有的流媒體技術(shù)的原理、系統(tǒng)構(gòu)成、傳輸協(xié)議等的總結(jié)分析，系統(tǒng)的介紹了流媒體的基本概念及特點，研究了流媒體的關(guān)鍵技術(shù)，并從用戶的角度對流媒體的應(yīng)用前景做了展望。 關(guān)鍵詞：流媒體；傳輸協(xié)議；系統(tǒng)結(jié)構(gòu) 流媒體（Streaming Media）是指采用流式傳輸?shù)姆绞皆贗nternet播放的多媒體格式。在流媒體出現(xiàn)之前，人們在互聯(lián)網(wǎng)上獲取音視頻信息的唯一方式就是將音視頻文件下載到本地計算機(jī)進(jìn)行觀看。而流媒體技術(shù)把連續(xù)的影像和聲音信息以數(shù)據(jù)流的方式實時發(fā)布，即邊下邊播的方式，使得用戶無需等待下載或只需少量時間緩沖即可觀看，大大提高了音視頻信息的可觀賞性，節(jié)約用戶時間及系統(tǒng)資源

44、。自從1995年progressive Network公司（即RealNetwork公司）發(fā)布第一個流產(chǎn)品以來，流媒體得到巨大的發(fā)展，已經(jīng)成為目前互聯(lián)網(wǎng)上呈現(xiàn)音、視頻信息的主要方式。1. 流媒體傳輸?shù)姆椒髅襟w傳輸技術(shù)分為兩類：:順序流傳輸(Progressive streaming )和實時流傳輸(Realtime streaming)。順序流方式又叫漸進(jìn)式下載，其傳輸方式是順序下載，在下載文件的同時用戶可觀看在線內(nèi)容，用戶只能觀看已下載的部分，而不能跳到還未下載的部分。由于標(biāo)準(zhǔn)的HTTP服務(wù)器可發(fā)送順序流式傳輸?shù)奈募?，也不需要其他特殊協(xié)議，所以順序流式傳輸經(jīng)常被稱作HTTP流式傳輸。實時流

45、方式：實時流式傳輸使媒體可被實時觀看到，特別適合現(xiàn)場廣播并提供VCR 功能，具備交互性，可以在播放的過程中響應(yīng)用戶的快進(jìn)或后退等操作。實時流式傳輸必須匹配網(wǎng)絡(luò)帶寬，其出錯的部分一般被忽略，傳輸質(zhì)量特別時低帶寬時的質(zhì)量要比順序傳輸?shù)牟?。實時流傳輸需要專門的流媒體服務(wù)器和流傳輸協(xié)議。2. 流媒體技術(shù)原理流式傳輸方式是指通過特定算法將音頻和視頻等多媒體文件分解成多個小的數(shù)據(jù)包，由服務(wù)器向客戶端連續(xù)傳送，用戶可播放已經(jīng)接收到的數(shù)據(jù)包，而不需要將整個文件下載到客戶端。由于TCP協(xié)議不太適合傳輸多媒體數(shù)據(jù)，故在實時流媒體方案中，一般采用HTTP/TCP來傳輸控制信息，而用RTP/UDP來傳輸實時數(shù)據(jù)。3.

46、 流媒體技術(shù)的系統(tǒng)結(jié)構(gòu)目前不同公司的流媒體解決方案各不相同。但就其本質(zhì)來說，一個完整的流媒體系統(tǒng)至少包括三個組件:編碼工具、服務(wù)器及播放器。這三個組件間通過特定的通信協(xié)議相互聯(lián)系，按特定的格式相互交換數(shù)據(jù)。4. 傳輸協(xié)議流媒體系統(tǒng)各組件通過傳輸協(xié)議相互通信。對于順序流傳輸，可采用HTTP協(xié)議進(jìn)行傳輸。但HTTP協(xié)議并不適合傳輸實時流數(shù)據(jù)。在流式傳輸?shù)膶崿F(xiàn)方案中，一般采用HTTP/TCP來傳輸控制信息，而用RTP/UDP來傳輸實時多媒體數(shù)據(jù)。傳輸協(xié)議是流媒體技術(shù)的一個重要組成部分，也是基礎(chǔ)組成部分。它包括"RSVP(資源預(yù)留協(xié)議)"、"RTP(實時傳輸協(xié)議)&quo

47、t;、"R T C P (實時傳輸控制協(xié)議)" 和"RTSP(實時流協(xié)議)"，這四種協(xié)議構(gòu)成了"rea1-time"服務(wù)的基礎(chǔ)。4.1 資源預(yù)留協(xié)議RSVP (Resource Reserve Protocol)RSVP是Internet上的資源預(yù)訂協(xié)議，使用RSVP可以讓流數(shù)據(jù)的接收者主動請求流數(shù)據(jù)上的路由器，為該數(shù)據(jù)流預(yù)留一分網(wǎng)絡(luò)資源（即帶寬），在一定程度上為流媒體的傳輸提供服務(wù)質(zhì)量。4.2 實時傳輸協(xié)議RTP與RTCPRTP是用于Internet/Intranet針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對一或一對多傳輸

48、的情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RTP通常使用UDP來傳送數(shù)據(jù)，但它本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。RTCP和RTP一起提供流量控制和擁塞控制服務(wù)。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，特別適合傳送網(wǎng)上的實時數(shù)據(jù)。4.3 實時流協(xié)議RTSP RTSP是由Real Networks和Netscape共同提出的，該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或RTP完成數(shù)據(jù)傳輸。RTSP 是應(yīng)用級協(xié)議，它以底層的RTP和RSVP為依托，控制實時數(shù)據(jù)的發(fā)送，它提供了可擴(kuò)展框架，使實時數(shù)據(jù)的受控、點播成為可能。在客戶端應(yīng)用程序中對流式多媒體內(nèi)容的播放、暫停等操作都是通過RTSP協(xié)議實現(xiàn)的。4.4 MMS協(xié)議（Microsoft Media Serve