RTSP、HTTP、HTTPS、SDP四種協議詳解

 

RTSP、HTTP、HTTPS、SDP四種協議詳解

分類： ffmpeg 2013-08-07 14:11   246人閱讀   評論(0)   收藏   舉報

RTSP、HTTP、HTTPS、SDP四種協議詳解

 

從這篇開始咱們將進入流媒體的環節，流媒體在android中有nuplayer來實現的，在開始講解android流媒體前，咱們先來說講流媒體傳輸協議，瞭解了基本協議，咱們在看代碼的過程當中，就會有事半功倍的效果。咱們將主要講解RTSP，HTTP,HTTPS, SDP四種協議。

 一：RTSP協議簡介
實時流協議RTSP是一個應用層協議，用於控制具備實時特性的數據（例如多媒體流）的傳送。

RTSP協議通常與RTP/RTCP和RSVP等底層協議一塊兒協同工做，提供基於Internet的整套的流服務。它能夠選擇發送通道（例如：UDP、組播UDP和TCP）和基於RTP的發送機制。它能夠應用於組播和點播。RTP, RTCP,RSVP 定義以下：

1. 實時傳輸協議RTP(Real-time Transport protocol)

2. 實時傳輸控制協議RTCP(Real-time Transport Control protocol)

3. 實時流協議RTSP(Real Time Streaming protocol)

4. 資源預留協議RSVP(Resource Reserve Protocol)

RTSP協議機理：

客戶機在向視頻服務器請求視頻服務以前，首先經過HTTP協議從Web服務器獲取所請求視頻服務的演示描述（Presentation description ）文件，在RTSP中，每一個演示（Presentation）及其所對應的媒體流都由一個RTSP URL標識。整個演示及媒體特性都在一個演示描述（Presentation description ）文件中定義，該文件可能包括媒體編碼方式、語言、RTSP URLs、目標地址、端口及其它參數。用戶在向服務器請求某個連續媒體流的服務以前，必須首先從服務器得到該媒體流的演示描述（Presentation description ）文件以獲得必需的參數，演示描述文件的獲取可採用HTTP、email或其餘方法。利用該文件提供的信息定位視頻服務地址（包括視頻服務器地址和端口號）及視頻服務的編碼方式等信息。而後客戶機根據上述信息向視頻服務器請求視頻服務。視頻服務初始化完畢，視頻服務器爲該客戶創建一個新的視頻服務流，客戶端與服務器運行實時流控制協議RTSP，以對該流進行各類VCR控制信號的交換，如播放（PLAY）、中止（PAUSE）、快進、快退等。當服務完畢，客戶端提出拆線（TEARDOWN）請求。服務器使用RTP/UDP協議將媒體數據傳輸給客戶端，一旦數據抵達客戶端，客戶端應用程序便可播放輸出。在流式傳輸中，使用RTP/RTCP/UDP和RTSP/TCP兩種不一樣的通訊協議在客戶端和服務器間創建聯繫。以下圖：

RTSP中的全部的操做都是經過服務器和客戶方的消息應答來完成的，其消息包括請求（Request）和響應（Response）兩種，RTSP正是經過服務器和客戶端的消息應答來完成媒體流的建立、初始化（SETUP）、VCR控制（PLAY、PAUSE）以及拆線（TEARDOWN）等操做的。以下圖：

RSTP 一些基本方法及用途：

OPTIONS  得到有效方法

SETUP    創建傳輸

ANNOUNCE 改變媒體文件的類型

DESCRIBE 得到媒體文件的類型

PLAY     播放

RECORD   刻錄

REDIRECT  轉換客戶端到新的服務器

PAUSE     暫停

SET PARAMETER 設置設備，編碼等參數

TEARDOWN  移除狀態

 

完整的播放過程：

GET 過程：

C->W: GET /twister.sdp HTTP/1.1

Host: www.example.com

Accept: application/sdp

W->C: HTTP/1.0 200 OK

Content-Type: application/sdp

v=0

o=- 2890844526 2890842807 IN IP4 192.16.24.202

s=RTSP Session

m=audio 0 RTP/AVP 0

a=control:rtsp://audio.com/twister/audio.en

m=video 0 RTP/AVP 31

a=control:rtsp://video.com/twister/video

SETUP過程：

C->A（audio）: SETUP rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 1

Transport: RTP/AVP/UDP;unicast

;client_port=3056-3057

A->C: RTSP/1.0 200 OK

CSeq: 1

Session: 12345678

Transport: RTP/AVP/UDP;unicast

;client_port=3056-3057;

;server_port=5000-5001

C->V（video）: SETUP rtsp://video.com/twister/video RTSP/1.0

CSeq: 1

Transport: RTP/AVP/UDP;unicast

;client_port=3058-3059

 

V->C: RTSP/1.0 200 OK

CSeq: 1

Session: 23456789

Transport: RTP/AVP/UDP;unicast

;client_port=3058-3059

;server_port=5002-5003

 

PLAY 過程：

C->V: PLAY rtsp://video.com/twister/video RTSP/1.0

CSeq: 2

Session: 23456789

Range: smpte=0:10:00-

V->C: RTSP/1.0 200 OK

CSeq: 2

Session: 23456789

Range: smpte=0:10:00-0:20:00

RTP-Info: url=rtsp://video.com/twister/video

;seq=12312232;rtptime=78712811

C->A: PLAY rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 2

Session: 12345678

Range: smpte=0:10:00-

 

A->C: RTSP/1.0 200 OK

CSeq: 2

Session: 12345678

Range: smpte=0:10:00-0:20:00

RTP-Info: url=rtsp://audio.com/twister/audio.en

;seq=876655;rtptime=1032181

close 過程：

C->A: TEARDOWN rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 3

Session: 12345678

A->C: RTSP/1.0 200 OK

CSeq: 3

C->V: TEARDOWN rtsp://video.com/twister/video RTSP/1.0

CSeq: 3

Session: 23456789

V->C: RTSP/1.0 200 OK

CSeq: 3

關於RTSP的一些時間概念：

 

normal play time (NPT): seconds, microseconds

MPTE timestamps (seconds, frames)

absolute time (for live events)
二　HTTP協議簡介

HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。

1：HTTP協議的主要特色可歸納以下：

1.支持客戶/服務器模式。

2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。

因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

2：HTTP協議的幾個重要概念

1.鏈接(Connection)：一個傳輸層的實際環流，它是創建在兩個相互通信的應用程序之間。

2.消息(Message)：HTTP通信的基本單位，包括一個結構化的八元組序列並經過鏈接傳輸。

3.請求(Request)：一個從客戶端到服務器的請求信息包括應用於資源的方法、資源的標識符和協議的版本號

4.響應(Response)：一個從服務器返回的信息包括HTTP協議的版本號、請求的狀態(例如「成功」或「沒找到」)和文檔的MIME類型。

5.資源(Resource)：由URI標識的網絡數據對象或服務。

6.實體(Entity)：數據資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的自己內容。

7.客戶機(Client)：一個爲發送請求目的而創建鏈接的應用程序。

8.用戶代理(User agent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。

9.服務器(Server)：一個接受鏈接並對請求返回信息的應用程序。

10.源服務器(Origin server)：是一個給定資源能夠在其上駐留或被建立的服務器。

11.代理(Proxy)：一箇中間程序，它能夠充當一個服務器，也能夠充當一個客戶機，爲其它客戶機創建請求。請求是經過可能的翻譯在內部或通過傳遞到其它的服務器中。一個代理在發送請求信息以前，必須解釋而且若是可能重寫它。

代理常常做爲經過防火牆的客戶機端的門戶，代理還能夠做爲一個幫助應用來經過協議處理沒有被用戶代理完成的請求。

12.網關(Gateway)：一個做爲其它服務器中間媒介的服務器。與代理不一樣的是，網關接受請求就好象對被請求的資源來講它就是源服務器；發出請求的客戶機並無意識到它在同網關打交道。
網關常常做爲經過防火牆的服務器端的門戶，網關還能夠做爲一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。

13.通道(Tunnel)：是做爲兩個鏈接中繼的中介程序。一旦激活，通道便被認爲不屬於HTTP通信，儘管通道多是被一個HTTP請求初始化的。當被中繼的鏈接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通信時通道被常用。

14.緩存(Cache)：反應信息的局域存儲。

3：創建鏈接的方式

HTTP支持2中創建鏈接的方式：非持久鏈接和持久鏈接(HTTP1.1默認的鏈接方式爲持久鏈接)。

1) 非持久鏈接

讓咱們查看一下非持久鏈接狀況下從服務器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML文件和10個JPEG圖像構成，並且全部這些對象都存放在同一臺服務器主機中。再假設該基本HTML文件的URL爲：gpcuster.cnblogs.com/index.html。

下面是具體步騾:

1.HTTP客戶初始化一個與服務器主機gpcuster.cnblogs.com中的HTTP服務器的TCP鏈接。HTTP服務器使用默認端口號80監聽來自HTTP客戶的鏈接創建請求。

2.HTTP客戶經由與TCP鏈接相關聯的本地套接字發出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。

3.HTTP服務器經由與TCP鏈接相關聯的本地套接字接收這個請求消息，再從服務器主機的內存或硬盤中取出對象/somepath/index.html，經由同一個套接字發出包含該對象的響應消息。

4.HTTP服務器告知TCP關閉這個TCP鏈接(不過TCP要到客戶收到剛纔這個響應消息以後纔會真正終止這個鏈接)。

5.HTTP客戶經由同一個套接字接收這個響應消息。TCP鏈接隨後終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析後發現其中有10個JPEG對象的引用。

6.給每個引用到的JPEG對象重複步騾1-4。

上述步驟之因此稱爲使用非持久鏈接，緣由是每次服務器發出一個對象後，相應的TCP鏈接就被關閉，也就是說每一個鏈接都沒有持續到可用於傳送其餘對象。每一個TCP鏈接只用於傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生11個TCP鏈接。

2) 持久鏈接

非持久鏈接有些缺點。首先，客戶得爲每一個待請求的對象創建並維護一個新的鏈接。對於每一個這樣的鏈接，TCP得在客戶端和服務器端分配TCP緩衝區，並維持TCP變量。對於有可能同時爲來自數百個不一樣客戶的請求提供服務的web服務器來講，這會嚴重增長其負擔。其次，如前所述，每一個對象都有2個RTT的響應延長——一個RTT用於創建TCP鏈接，另—個RTT用於請求和接收對象。最後，每一個對象都遭受TCP緩啓動，由於每一個TCP鏈接都起始於緩啓動階段。不過並行TCP鏈接的使用可以部分減輕RTT延遲和緩啓動延遲的影響。

在持久鏈接狀況下，服務器在發出響應後讓TCP鏈接繼續打開着。同一對客戶/服務器之間的後續請求和響應能夠經過這個鏈接發送。整個Web頁面(上例中爲包含一個基本HTMLL文件和10個圖像的頁面)自不用說能夠經過單個持久TCP鏈接發送:甚至存放在同一個服務器中的多個web頁面也能夠經過單個持久TCP鏈接發送。一般，HTTP服務器在某個鏈接閒置一段特定時間後關閉它，而這段時間一般是能夠配置的。持久鏈接分爲不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。若是是不帶流水線的版本，那麼客戶只在收到前一個請求的響應後才發出新的請求。這種狀況下，web頁面所引用的每一個對象(上例中的10個圖像)都經歷1個RTT的延遲，用於請求和接收該對象。與非持久鏈接2個RTT的延遲相比，不帶流水線的持久鏈接已有所改善，不過帶流水線的持久鏈接還能進一步下降響應延遲。不帶流水線版本的另外一個缺點是，服務器送出一個對象後開始等待下一個請求，而這個新請求卻不能立刻到達。這段時間服務器資源便閒置了。

HTTP/1.1的默認模式使用帶流水線的持久鏈接。這種狀況下，HTTP客戶每碰到一個引用就當即發出一個請求，於是HTTP客戶能夠一個接一個緊挨着發出各個引用對象的請求。服務器收到這些請求後，也能夠一個接一個緊挨着發出各個對象。若是全部的請求和響應都是緊挨着發送的，那麼全部引用到的對象一共只經歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每一個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久鏈接中服務器空等請求的時間比較少。與非持久鏈接相比，持久鏈接(不管是否帶流水線)除下降了1個RTT的響應延遲外，緩啓動延遲也比較小。其緣由在於既然各個對象使用同一個TCP鏈接，服務器發出第一個對象後就沒必要再以一開始的緩慢速率發送後續對象。相反，服務器能夠按照第一個對象發送完畢時的速率開始發送下一個對象。

4： 緩存的機制

HTTP/1.1中緩存的目的是爲了在不少狀況下減小發送請求，同時在許多狀況下能夠不須要發送完整響應。前者減小了網絡迴路的數量；HTTP利用一個「過時（expiration）」機制來爲此目的。後者減小了網絡應用的帶寬；HTTP用「驗證（validation）」機制來爲此目的。具體能夠參考：

http://www.chedong.com/tech/cache_docs.html

 

 

三 RTSP協議與HTTP協議的聯繫與區別

RTSP協議負責在服務器和客戶端之間創建並控制一個或多個時間上同步的連續流媒體，其目標是象HTTP協議爲用戶提供文字和圖形服務那樣爲用戶提供連續媒體服務。所以，RTSP協議的設計在語法和操做上與HTTP協議很類似，這樣，對於HTTP的大部分擴展也適用於RTSP。
可是RTSP協議和HTTP協議在不少方面有着區別：
1. HTTP是一個無狀態協議，而RTSP協議是有狀態的。
2. HTTP本質上是一個非對稱協議，客戶端提出請求而服務器響應；而RTSP是對稱的，服務器和客戶端均可發送和響應請求。

 

四  HTTPS傳輸協議

HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議，它是一個安全通訊通道，它基於HTTP開發，用於在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來講它是HTTP的安全版。
它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操做，並返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）做爲HTTP應用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通訊。）SSL使用40 位關鍵字做爲RC4流加密算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，若是須要的話用戶能夠確認發送者是誰。

HTTPS和HTTP的區別：

1：http和https使用的是徹底不一樣的鏈接方式,用的端口也不同,前者是80,後者是443。
2：https協議須要到ca申請證書，通常免費證書不多，須要交費。
3：http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議
4：http的鏈接很簡單,是無狀態的，而HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全

HTTPS解決的問題：
1 . 信任主機的問題. 採用https 的server 必須從CA 申請一個用於證實服務器用途類型的證書. 改證書只有用於對應的server 的時候,客戶度纔信任次主機. 因此目前全部的銀行系統網站,關鍵部分應用都是https 的. 客戶經過信任該證書,從而信任了該主機. 其實這樣作效率很低,可是銀行更側重安全. 這一點對咱們沒有任何意義,咱們的server ,採用的證書無論本身issue 仍是從公衆的地方issue, 客戶端都是本身人,因此咱們也就確定信任該server.
2 . 通信過程當中的數據的泄密和被竄改
1. 通常意義上的https, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點同樣.
b) 服務端和客戶端之間的全部通信,都是加密的.
i. 具體講,是客戶端產生一個對稱的密鑰,經過server 的證書來交換密鑰. 通常意義上的握手過程.
ii. 加下來全部的信息往來就都是加密的. 第三方即便截獲,也沒有任何意義.由於他沒有密鑰. 固然竄改也就沒有什麼意義了.
2. 少量對客戶端有要求的狀況下,會要求客戶端也必須有一個證書.
a) 這裏客戶端證書,其實就相似表示我的信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應爲我的證書通常來講上別人沒法模擬的,全部這樣可以更深的確認本身的身份.
b) 目前少數我的銀行的專業版是這種作法,具體證書多是拿U盤做爲一個備份的載體.
HTTPS 必定是繁瑣的.
a) 原本簡單的http協議,一個get一個response. 因爲https 要還密鑰和確認加密算法的須要.單握手就須要6/7 個往返.
i. 任何應用中,過多的round trip 確定影響性能.
b) 接下來纔是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容作加密/解密.
i. 儘管對稱加密/解密效率比較高,但是仍然要消耗過多的CPU,爲此有專門的SSL 芯片. 若是CPU 信能比較低的話,確定會下降性能,從而不能serve 更多的請求.
ii. 加密後數據量的影響. 因此，纔會出現那麼多的安全認證提示。

 

五 SDP協議

SDP會話描述協議：爲會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。會話目錄用於協助多媒體會議的通告，併爲會話參與者傳送相關設置信息。 SDP 即用於將這種信息傳輸到接收端。 SDP 徹底是一種會話描述格式――它不屬於傳輸協議 ――它只使用不一樣的適當的傳輸協議，包括會話通知協議 （SAP） 、會話初始協議（SIP）、實時流協議 （RTSP）、 MIME 擴展協議的電子郵件以及超文本傳輸協議 （HTTP）。SDP 的設計宗旨是通用性，它能夠應用於大範圍的網絡環境和應用程序，而不只僅侷限於組播會話目錄。

SDP是會話描述協議的縮寫，是描述流媒體初始化參數的格式，由IETF做爲RFC 4566頒佈。流媒體是指在傳輸過程當中看到或聽到的內容，SDP包一般包括如下信息：

（1）會話信息· 會話名和目的

· 會話活動時間

因爲參與會話的資源是受限制的，所以包括如下附加信息是很是有用的

· 會話使用的帶寬信息

· 會話負責人的聯繫信息

（2）媒體信息

· 媒體類型，例如視頻和音頻

· 傳輸協議，例如RTP/UDP/IP和H.320。

· 多播地址和媒體傳輸端口（IP多播會話）

· 用於聯繫地址的媒體和傳輸端口的遠端地址（IP單播會話）

SDP描述由許多文本行組成，文本行的格式爲<類型>=<值>，<類型>是一個字母，<值>是結構化的文本串，其格式依<類型>而定。

SDP格式（帶*爲可選）:

Session description

v=   (protocol version) //該行指示協議的版本

o=   (owner/creator and session identifier)

例如：    o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4   //o行中包含與會話全部者有關的參數（1：第一個參數代表會話發起者的名稱，該參數可不填寫，如填寫和SIP消息中，from消息頭的內容一致:2：第二個參數爲主叫方的會話標識符:3：第三個參數爲主叫方會話的版本，會話數據有改變時，版本號遞增:4：第四個參數定義了網絡類型，IN表示Internet網絡類型，目前僅定義該網絡類型:5：第五個參數爲地址類型，目前支持IPV4和IPV6兩種地址類型:6：第六個參數爲地址：代表會話發起者的IP地址，該地址爲信令面的IP地址，信令PDP激活時爲手機分配。）

s=   (session name) //代表本次會話的標題，或會話的名稱

i=* (session information)

u=* (URI of description)

e=* (email address)

p=* (phone number)

c=* (connection information - not required if included in all media)

b=* (zero or more bandwidth information lines)

One or more time descriptions ("t=" and "r=" lines, see below)

z=* (time zone adjustments)

k=* (encryption key)

a=* (zero or more session attribute lines)

Zero or more media descriptions

Time description

t=   (time the session is active)

r=* (zero or more repeat times)

Media description, if present

m=   (media name and transport address)

    例如： m=audio 3458  RTP/AVP  0   96   97   // m行又稱媒體行，描述了發送方所支持的媒體類型等信息（1： 第一個參數爲媒體名稱：代表支持音頻類型。2： 第二個參數爲端口號，代表UE在本地端口爲3458上發送音頻流。3： 第三個參數爲傳輸協議，通常爲RTP/AVP協議。4：四-七參數爲所支持的四種淨荷類型編號）

m=video 3400 RTP/AVP 98  99 //m行又稱媒體行，描述了發送方所支持的媒體類型等信息

i=* (media title)

c=* (connection information - optional if included at

session-level)

b=* (zero or more bandwidth information lines)

k=* (encryption key)

a=* (zero or more media attribute lines)

 

原文 http://blog.csdn.net/tjy1985/article/details/7996121#comments