參考原文鏈接:
http://blog.csdn.net/maopig/article/details/6665250
http://www.cnblogs.com/qingquan/archive/2011/07/14/2106834.html

RTSP實(shí)時(shí)流協(xié)議

多媒體播放控制協(xié)議，TCP/IP協(xié)議體系中的一個(gè)應(yīng)用層協(xié)議，用來(lái)使用戶在播放從因特網(wǎng)下載的實(shí)時(shí)數(shù)據(jù)時(shí)能夠進(jìn)行控制。（暫停，播放，后退，前進(jìn)）

RTSP特性

• 流控分離：從控制邏輯上來(lái)說(shuō)RTSP和FTP相似，控制流和數(shù)據(jù)流是分開(kāi)的。
• 可擴(kuò)展性：因?yàn)镽TSP協(xié)議是基于文本的協(xié)議所以其具有較強(qiáng)的可擴(kuò)展性。
• 安全：RTSP 使用網(wǎng)頁(yè)安全機(jī)制。

RTSP協(xié)議條件

實(shí)現(xiàn)控制功能 除協(xié)議外還需

• 1 媒體播放器(media player)
• 2 媒體服務(wù)器(media server)

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)度都是不確定的。

請(qǐng)求報(bào)文

響應(yīng)報(bào)文

協(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ù)字編輯。
• 演示描述中立：協(xié)議未強(qiáng)加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少需包含一個(gè)RTSP URI。
• 代理與防火墻友好：協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開(kāi)一個(gè)“缺口”。
• 適當(dāng)?shù)姆?wù)器控制：如用戶啟動(dòng)一個(gè)流，則也可以停止一個(gè)流。
• 傳輸協(xié)調(diào)：實(shí)際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。
• 性能協(xié)調(diào)：如基本特征無(wú)效，則必須有一些清理機(jī)制讓用戶決定那種方法不生效。這允許用戶提出適合自己的界面。

與HTTP協(xié)議流控制協(xié)議的區(qū)別

• 都使用純文本來(lái)發(fā)送信息，語(yǔ)法類似
• RTSP協(xié)議是有狀態(tài)的協(xié)議，HTTP是無(wú)狀態(tài)的協(xié)議

協(xié)議的狀態(tài)是指下一次傳輸數(shù)據(jù)的時(shí)候能考慮到這次傳輸信息的狀態(tài)。也有是說(shuō)有狀態(tài)協(xié)議以前的請(qǐng)求導(dǎo)致協(xié)議所處的狀態(tài)會(huì)影響后續(xù)的狀態(tài)，協(xié)議會(huì)根據(jù)上一個(gè)狀態(tài)創(chuàng)建上下文。

• http協(xié)議里就是無(wú)狀態(tài)協(xié)議不用考慮上下文；每個(gè)請(qǐng)求都是與服務(wù)器的獨(dú)立連接，即下一次請(qǐng)求到來(lái)的時(shí)候協(xié)議不用維護(hù)這次請(qǐng)求中客戶機(jī)-服務(wù)器間交互的信息。
• RTSP通過(guò)維護(hù)一個(gè)session來(lái)維護(hù)其狀態(tài)的轉(zhuǎn)換

協(xié)議實(shí)現(xiàn)

1.初始化

在建立連接之前，客戶端應(yīng)向服務(wù)器提出測(cè)試請(qǐng)求，即要求服務(wù)器向客戶端發(fā)送相應(yīng)的測(cè)試數(shù)據(jù)包。初始化的目的，是為了獲取客 戶端和服務(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 TCP的方式發(fā)送數(shù)據(jù)。由于TCP沒(méi)有丟包（其自身具有重傳機(jī)制），網(wǎng)絡(luò)狀況又屬于良好，因此客戶端將有較高的視聽(tīng)享受。
當(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.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)丟包率處于一定范圍（75％～85％）之內(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ò)丟包，為客戶端被動(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)為目 前傳送的視頻文件可令客戶端獲得最大程度的音視頻享受;否則，考慮改為傳輸更低碼率的視頻文件或放棄這次RTSP會(huì)話，以避免更大范圍的擁塞。

5.實(shí)際效果

采取如上方法設(shè)計(jì)的系統(tǒng)，可以滿足視頻點(diǎn)播的基本要求，避免了服務(wù)器視頻文件下發(fā)的盲目性，同時(shí)使客戶端應(yīng)用效果最好