流媒體在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）”機制來為此目的。 

三 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=mhandley28908445262890842807INIP4126.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=audio3458RTP/AVP09697//m行又稱媒體行，描述了發送方所支持的媒體類型等信息（1：第一個參數為媒體名稱：表明支持音頻類型。2：第二個參數為端口號，表明UE在本地端口為3458上發送音頻流。3：第三個參數為傳輸協議，一般為RTP/AVP協議。4：四-七參數為所支持的四種凈荷類型編號）

m=video3400RTP/AVP9899 //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)