流媒體在Android中有nuplayer來實(shí)現(xiàn)的，在開始講解android流媒體前，我們先來講講流媒體傳輸協(xié)議，了解了基本協(xié)議，我們?cè)诳创a的過程中，就會(huì)有事半功倍的效果。我們將主要講解RTSP，HTTP,HTTPS, SDP四種協(xié)議。下面就詳情來看看！

一：RTSP協(xié)議簡(jiǎn)介

實(shí)時(shí)流協(xié)議RTSP是一個(gè)應(yīng)用層協(xié)議，用于控制具有實(shí)時(shí)特性的數(shù)據(jù)（例如多媒體流）的傳送。

RTSP協(xié)議一般與RTP/RTCP和RSVP等底層協(xié)議一起協(xié)同工作，提供基于Internet的整套的流服務(wù)。它可以選擇發(fā)送通道（例如：UDP、組播UDP和TCP）和基于RTP的發(fā)送機(jī)制。它可以應(yīng)用于組播和點(diǎn)播。RTP, RTCP,RSVP 定義如下：

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

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

3. 實(shí)時(shí)流協(xié)議RTSP(Real Time Streaming protocol)

4. 資源預(yù)留協(xié)議RSVP(Resource Reserve Protocol)

RTSP協(xié)議機(jī)理：

客戶機(jī)在向視頻服務(wù)器請(qǐng)求視頻服務(wù)之前，首先通過HTTP協(xié)議從Web服務(wù)器獲取所請(qǐng)求視頻服務(wù)的演示描述（Presentation description ）文件，在RTSP中，每個(gè)演示（Presentation）及其所對(duì)應(yīng)的媒體流都由一個(gè)RTSP URL標(biāo)識(shí)。整個(gè)演示及媒體特性都在一個(gè)演示描述（Presentation description ）文件中定義，該文件可能包括媒體編碼方式、語言、RTSP URLs、目標(biāo)地址、端口及其它參數(shù)。用戶在向服務(wù)器請(qǐng)求某個(gè)連續(xù)媒體流的服務(wù)之前，必須首先從服務(wù)器獲得該媒體流的演示描述（Presentation description ）文件以得到必需的參數(shù)，演示描述文件的獲取可采用HTTP、email或其他方法。利用該文件提供的信息定位視頻服務(wù)地址（包括視頻服務(wù)器地址和端口號(hào)）及視頻服務(wù)的編碼方式等信息。然后客戶機(jī)根據(jù)上述信息向視頻服務(wù)器請(qǐng)求視頻服務(wù)。視頻服務(wù)初始化完畢，視頻服務(wù)器為該客戶建立一個(gè)新的視頻服務(wù)流，客戶端與服務(wù)器運(yùn)行實(shí)時(shí)流控制協(xié)議RTSP，以對(duì)該流進(jìn)行各種VCR控制信號(hào)的交換，如播放（PLAY）、停止（PAUSE）、快進(jìn)、快退等。當(dāng)服務(wù)完畢，客戶端提出拆線（TEARDOWN）請(qǐng)求。服務(wù)器使用RTP/UDP協(xié)議將媒體數(shù)據(jù)傳輸給客戶端，一旦數(shù)據(jù)抵達(dá)客戶端，客戶端應(yīng)用程序即可播放輸出。在流式傳輸中，使用RTP/RTCP/UDP和RTSP/TCP兩種不同的通信協(xié)議在客戶端和服務(wù)器間建立聯(lián)系。如下圖：

RTSP中的所有的操作都是通過服務(wù)器和客戶方的消息應(yīng)答來完成的，其消息包括請(qǐng)求（Request）和響應(yīng)（Response）兩種，RTSP正是通過服務(wù)器和客戶端的消息應(yīng)答來完成媒體流的創(chuàng)建、初始化（SETUP）、VCR控制（PLAY、PAUSE）以及拆線（TEARDOWN）等操作的。如下圖：

RSTP 一些基本方法及用途：

OPTIONS 獲得有效方法

SETUP 建立傳輸

ANNOUNCE 改變媒體文件的類型

DESCRIBE 獲得媒體文件的類型

PLAY 播放

RECORD 刻錄

REDIRECT 轉(zhuǎn)換客戶端到新的服務(wù)器

PAUSE 暫停

SET PARAMETER 設(shè)置設(shè)備，編碼等參數(shù)

TEARDOWN 移除狀態(tài)

完整的播放過程：

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

關(guān)于RTSP的一些時(shí)間概念：

normal play time (NPT): seconds, microseconds

MPTE timestamps (seconds, frames)

absolute time (for live events)

二　HTTP協(xié)議簡(jiǎn)介

HTTP是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡(jiǎn)捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進(jìn)行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經(jīng)提出。

1：HTTP協(xié)議的主要特點(diǎn)可概括如下：

1.支持客戶/服務(wù)器模式。

2.簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。

由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。

3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。

4.無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。

5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

2：HTTP協(xié)議的幾個(gè)重要概念

1.連接(Connection)：一個(gè)傳輸層的實(shí)際環(huán)流，它是建立在兩個(gè)相互通訊的應(yīng)用程序之間。

2.消息(Message)：HTTP通訊的基本單位，包括一個(gè)結(jié)構(gòu)化的八元組序列并通過連接傳輸。

3.請(qǐng)求(Request)：一個(gè)從客戶端到服務(wù)器的請(qǐng)求信息包括應(yīng)用于資源的方法、資源的標(biāo)識(shí)符和協(xié)議的版本號(hào)

4.響應(yīng)(Response)：一個(gè)從服務(wù)器返回的信息包括HTTP協(xié)議的版本號(hào)、請(qǐng)求的狀態(tài)(例如“成功”或“沒找到”)和文檔的MIME類型。

5.資源(Resource)：由URI標(biāo)識(shí)的網(wǎng)絡(luò)數(shù)據(jù)對(duì)象或服務(wù)。

6.實(shí)體(Entity)：數(shù)據(jù)資源或來自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個(gè)請(qǐng)求或響應(yīng)信息中。一個(gè)實(shí)體包括實(shí)體頭信息和實(shí)體的本身內(nèi)容。

7.客戶機(jī)(Client)：一個(gè)為發(fā)送請(qǐng)求目的而建立連接的應(yīng)用程序。

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

9.服務(wù)器(Server)：一個(gè)接受連接并對(duì)請(qǐng)求返回信息的應(yīng)用程序。

10.源服務(wù)器(Origin server)：是一個(gè)給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。

11.代理(Proxy)：一個(gè)中間程序，它可以充當(dāng)一個(gè)服務(wù)器，也可以充當(dāng)一個(gè)客戶機(jī)，為其它客戶機(jī)建立請(qǐng)求。請(qǐng)求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務(wù)器中。一個(gè)代理在發(fā)送請(qǐng)求信息之前，必須解釋并且如果可能重寫它。

代理經(jīng)常作為通過防火墻的客戶機(jī)端的門戶，代理還可以作為一個(gè)幫助應(yīng)用來通過協(xié)議處理沒有被用戶代理完成的請(qǐng)求。

12.網(wǎng)關(guān)(Gateway)：一個(gè)作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請(qǐng)求就好象對(duì)被請(qǐng)求的資源來說它就是源服務(wù)器；發(fā)出請(qǐng)求的客戶機(jī)并沒有意識(shí)到它在同網(wǎng)關(guān)打交道。

網(wǎng)關(guān)經(jīng)常作為通過防火墻的服務(wù)器端的門戶，網(wǎng)關(guān)還可以作為一個(gè)協(xié)議翻譯器以便存取那些存儲(chǔ)在非HTTP系統(tǒng)中的資源。

13.通道(Tunnel)：是作為兩個(gè)連接中繼的中介程序。一旦激活，通道便被認(rèn)為不屬于HTTP通訊，盡管通道可能是被一個(gè)HTTP請(qǐng)求初始化的。當(dāng)被中繼的連接兩端關(guān)閉時(shí)，通道便消失。當(dāng)一個(gè)門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時(shí)通道被經(jīng)常使用。

14.緩存(Cache)：反應(yīng)信息的局域存儲(chǔ)。

3：建立連接的方式

HTTP支持2中建立連接的方式：非持久連接和持久連接(HTTP1.1默認(rèn)的連接方式為持久連接)。

1)非持久連接

讓我們查看一下非持久連接情況下從服務(wù)器到客戶傳送一個(gè)Web頁面的步驟。假設(shè)該貝面由1個(gè)基本HTML文件和10個(gè)JPEG圖像構(gòu)成，而且所有這些對(duì)象都存放在同一臺(tái)服務(wù)器主機(jī)中。再假設(shè)該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。

下面是具體步騾:

1.HTTP客戶初始化一個(gè)與服務(wù)器主機(jī)gpcuster.cnblogs.com中的HTTP服務(wù)器的TCP連接。HTTP服務(wù)器使用默認(rèn)端口號(hào)80監(jiān)聽來自HTTP客戶的連接建立請(qǐng)求。

2.HTTP客戶經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字發(fā)出—個(gè)HTTP請(qǐng)求消息。這個(gè)消息中包含路徑名/somepath/index.html。

3.HTTP服務(wù)器經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字接收這個(gè)請(qǐng)求消息，再從服務(wù)器主機(jī)的內(nèi)存或硬盤中取出對(duì)象/somepath/index.html，經(jīng)由同一個(gè)套接字發(fā)出包含該對(duì)象的響應(yīng)消息。

4.HTTP服務(wù)器告知TCP關(guān)閉這個(gè)TCP連接(不過TCP要到客戶收到剛才這個(gè)響應(yīng)消息之后才會(huì)真正終止這個(gè)連接)。

5.HTTP客戶經(jīng)由同一個(gè)套接字接收這個(gè)響應(yīng)消息。TCP連接隨后終止。該消息標(biāo)明所封裝的對(duì)象是一個(gè)HTML文件?？蛻魪闹腥〕鲞@個(gè)文件，加以分析后發(fā)現(xiàn)其中有10個(gè)JPEG對(duì)象的引用。

6.給每一個(gè)引用到的JPEG對(duì)象重復(fù)步騾1-4。

上述步驟之所以稱為使用非持久連接，原因是每次服務(wù)器發(fā)出一個(gè)對(duì)象后，相應(yīng)的TCP連接就被關(guān)閉，也就是說每個(gè)連接都沒有持續(xù)到可用于傳送其他對(duì)象。每個(gè)TCP連接只用于傳輸一個(gè)請(qǐng)求消息和一個(gè)響應(yīng)消息。就上述例子而言，用戶每請(qǐng)求一次那個(gè)web頁面，就產(chǎn)生11個(gè)TCP連接。

2)持久連接

非持久連接有些缺點(diǎn)。首先，客戶得為每個(gè)待請(qǐng)求的對(duì)象建立并維護(hù)一個(gè)新的連接。對(duì)于每個(gè)這樣的連接，TCP得在客戶端和服務(wù)器端分配TCP緩沖區(qū)，并維持TCP變量。對(duì)于有可能同時(shí)為來自數(shù)百個(gè)不同客戶的請(qǐng)求提供服務(wù)的web服務(wù)器來說，這會(huì)嚴(yán)重增加其負(fù)擔(dān)。其次，如前所述，每個(gè)對(duì)象都有2個(gè)RTT的響應(yīng)延長(zhǎng)——一個(gè)RTT用于建立TCP連接，另—個(gè)RTT用于請(qǐng)求和接收對(duì)象。最后，每個(gè)對(duì)象都遭受TCP緩啟動(dòng)，因?yàn)槊總€(gè)TCP連接都起始于緩啟動(dòng)階段。不過并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動(dòng)延遲的影響。

在持久連接情況下，服務(wù)器在發(fā)出響應(yīng)后讓TCP連接繼續(xù)打開著。同一對(duì)客戶/服務(wù)器之間的后續(xù)請(qǐng)求和響應(yīng)可以通過這個(gè)連接發(fā)送。整個(gè)Web頁面(上例中為包含一個(gè)基本HTMLL文件和10個(gè)圖像的頁面)自不用說可以通過單個(gè)持久TCP連接發(fā)送:甚至存放在同一個(gè)服務(wù)器中的多個(gè)web頁面也可以通過單個(gè)持久TCP連接發(fā)送。通常，HTTP服務(wù)器在某個(gè)連接閑置一段特定時(shí)間后關(guān)閉它，而這段時(shí)間通常是可以配置的。持久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個(gè)版本。如果是不帶流水線的版本，那么客戶只在收到前一個(gè)請(qǐng)求的響應(yīng)后才發(fā)出新的請(qǐng)求。這種情況下，web頁面所引用的每個(gè)對(duì)象(上例中的10個(gè)圖像)都經(jīng)歷1個(gè)RTT的延遲，用于請(qǐng)求和接收該對(duì)象。與非持久連接2個(gè)RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進(jìn)一步降低響應(yīng)延遲。不帶流水線版本的另一個(gè)缺點(diǎn)是，服務(wù)器送出一個(gè)對(duì)象后開始等待下一個(gè)請(qǐng)求，而這個(gè)新請(qǐng)求卻不能馬上到達(dá)。這段時(shí)間服務(wù)器資源便閑置了。

HTTP/1.1的默認(rèn)模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個(gè)引用就立即發(fā)出一個(gè)請(qǐng)求，因而HTTP客戶可以一個(gè)接一個(gè)緊挨著發(fā)出各個(gè)引用對(duì)象的請(qǐng)求。服務(wù)器收到這些請(qǐng)求后，也可以一個(gè)接一個(gè)緊挨著發(fā)出各個(gè)對(duì)象。如果所有的請(qǐng)求和響應(yīng)都是緊挨著發(fā)送的，那么所有引用到的對(duì)象一共只經(jīng)歷1個(gè)RTT的延遲(而不是像不帶流水線的版本那樣，每個(gè)引用到的對(duì)象都各有1個(gè)RTT的延遲)。另外，帶流水線的持久連接中服務(wù)器空等請(qǐng)求的時(shí)間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個(gè)RTT的響應(yīng)延遲外，緩啟動(dòng)延遲也比較小。其原因在于既然各個(gè)對(duì)象使用同一個(gè)TCP連接，服務(wù)器發(fā)出第一個(gè)對(duì)象后就不必再以一開始的緩慢速率發(fā)送后續(xù)對(duì)象。相反，服務(wù)器可以按照第一個(gè)對(duì)象發(fā)送完畢時(shí)的速率開始發(fā)送下一個(gè)對(duì)象。

4：緩存的機(jī)制

HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請(qǐng)求，同時(shí)在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路的數(shù)量；HTTP利用一個(gè)“過期（expiration）”機(jī)制來為此目的。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬；HTTP用“驗(yàn)證（validation）”機(jī)制來為此目的。 

三 RTSP協(xié)議與HTTP協(xié)議的聯(lián)系與區(qū)別

RTSP協(xié)議負(fù)責(zé)在服務(wù)器和客戶端之間建立并控制一個(gè)或多個(gè)時(shí)間上同步的連續(xù)流媒體，其目標(biāo)是象HTTP協(xié)議為用戶提供文字和圖形服務(wù)那樣為用戶提供連續(xù)媒體服務(wù)。因此，RTSP協(xié)議的設(shè)計(jì)在語法和操作上與HTTP協(xié)議很相似，這樣，對(duì)于HTTP的大部分?jǐn)U展也適用于RTSP。

但是RTSP協(xié)議和HTTP協(xié)議在很多方面有著區(qū)別：

1. HTTP是一個(gè)無狀態(tài)協(xié)議，而RTSP協(xié)議是有狀態(tài)的。

2. HTTP本質(zhì)上是一個(gè)非對(duì)稱協(xié)議，客戶端提出請(qǐng)求而服務(wù)器響應(yīng)；而RTSP是對(duì)稱的，服務(wù)器和客戶端都可發(fā)送和響應(yīng)請(qǐng)求。

四 HTTPS傳輸協(xié)議

HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協(xié)議，它是一個(gè)安全通信通道，它基于HTTP開發(fā)，用于在客戶計(jì)算機(jī)和服務(wù)器之間交換信息。它使用安全套接字層(SSL)進(jìn)行信息交換，簡(jiǎn)單來說它是HTTP的安全版。
它是由Netscape開發(fā)并內(nèi)置于其瀏覽器中，用于對(duì)數(shù)據(jù)進(jìn)行壓縮和解壓操作，并返回網(wǎng)絡(luò)上傳送回的結(jié)果。HTTPS實(shí)際上應(yīng)用了Netscape的安全全套接字層（SSL）作為HTTP應(yīng)用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進(jìn)行通信。）SSL使用40 位關(guān)鍵字作為RC4流加密算法，這對(duì)于商業(yè)信息的加密是合適的。HTTPS和SSL支持使用X.509數(shù)字認(rèn)證，如果需要的話用戶可以確認(rèn)發(fā)送者是誰。

HTTPS和HTTP的區(qū)別：

1：http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
2：https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。
3：http是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議
4：http的連接很簡(jiǎn)單,是無狀態(tài)的，而HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全

HTTPS解決的問題：
1 . 信任主機(jī)的問題. 采用https 的server 必須從CA 申請(qǐng)一個(gè)用于證明服務(wù)器用途類型的證書. 改證書只有用于對(duì)應(yīng)的server 的時(shí)候,客戶度才信任次主機(jī). 所以目前所有的銀行系統(tǒng)網(wǎng)站,關(guān)鍵部分應(yīng)用都是https 的. 客戶通過信任該證書,從而信任了該主機(jī). 其實(shí)這樣做效率很低,但是銀行更側(cè)重安全. 這一點(diǎn)對(duì)我們沒有任何意義,我們的server ,采用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.
2 . 通訊過程中的數(shù)據(jù)的泄密和被竄改
1. 一般意義上的https, 就是 server 有一個(gè)證書.
a) 主要目的是保證server 就是他聲稱的server. 這個(gè)跟第一點(diǎn)一樣.
b) 服務(wù)端和客戶端之間的所有通訊,都是加密的.
i. 具體講,是客戶端產(chǎn)生一個(gè)對(duì)稱的密鑰,通過server 的證書來交換密鑰. 一般意義上的握手過程.
ii. 加下來所有的信息往來就都是加密的. 第三方即使截獲,也沒有任何意義.因?yàn)樗麤]有密鑰. 當(dāng)然竄改也就沒有什么意義了.
2. 少許對(duì)客戶端有要求的情況下,會(huì)要求客戶端也必須有一個(gè)證書.
a) 這里客戶端證書,其實(shí)就類似表示個(gè)人信息的時(shí)候,除了用戶名/密碼, 還有一個(gè)CA 認(rèn)證過的身份. 應(yīng)為個(gè)人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認(rèn)自己的身份.
b) 目前少數(shù)個(gè)人銀行的專業(yè)版是這種做法,具體證書可能是拿U盤作為一個(gè)備份的載體.
HTTPS 一定是繁瑣的.
a) 本來簡(jiǎn)單的http協(xié)議,一個(gè)get一個(gè)response. 由于https 要還密鑰和確認(rèn)加密算法的需要.單握手就需要6/7 個(gè)往返.
i. 任何應(yīng)用中,過多的round trip 肯定影響性能.
b) 接下來才是具體的http協(xié)議,每一次響應(yīng)或者請(qǐng)求, 都要求客戶端和服務(wù)端對(duì)會(huì)話的內(nèi)容做加密/解密.
i. 盡管對(duì)稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 芯片. 如果CPU 信能比較低的話,肯定會(huì)降低性能,從而不能serve 更多的請(qǐng)求.
ii. 加密后數(shù)據(jù)量的影響. 所以，才會(huì)出現(xiàn)那么多的安全認(rèn)證提示。

五 SDP協(xié)議

SDP會(huì)話描述協(xié)議：為會(huì)話通知、會(huì)話邀請(qǐng)和其它形式的多媒體會(huì)話初始化等目的提供了多媒體會(huì)話描述。會(huì)話目錄用于協(xié)助多媒體會(huì)議的通告，并為會(huì)話參與者傳送相關(guān)設(shè)置信息。 SDP 即用于將這種信息傳輸?shù)浇邮斩恕?SDP 完全是一種會(huì)話描述格式――它不屬于傳輸協(xié)議 ――它只使用不同的適當(dāng)?shù)膫鬏攨f(xié)議，包括會(huì)話通知協(xié)議 （SAP） 、會(huì)話初始協(xié)議（SIP）、實(shí)時(shí)流協(xié)議 （RTSP）、 MIME 擴(kuò)展協(xié)議的電子郵件以及超文本傳輸協(xié)議 （HTTP）。SDP 的設(shè)計(jì)宗旨是通用性，它可以應(yīng)用于大范圍的網(wǎng)絡(luò)環(huán)境和應(yīng)用程序，而不僅僅局限于組播會(huì)話目錄。

SDP是會(huì)話描述協(xié)議的縮寫，是描述流媒體初始化參數(shù)的格式，由IETF作為RFC 4566頒布。流媒體是指在傳輸過程中看到或聽到的內(nèi)容，SDP包通常包括以下信息：

（1）會(huì)話信息· 會(huì)話名和目的

　　 · 會(huì)話活動(dòng)時(shí)間

　　 由于參與會(huì)話的資源是受限制的，因此包括以下附加信息是非常有用的

　　 · 會(huì)話使用的帶寬信息

　　 · 會(huì)話負(fù)責(zé)人的聯(lián)系信息

（2）媒體信息

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

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

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

　　 · 用于聯(lián)系地址的媒體和傳輸端口的遠(yuǎn)端地址（IP單播會(huì)話）

SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個(gè)字母，<值>是結(jié)構(gòu)化的文本串，其格式依<類型>而定。

SDP格式（帶*為可選）:

Session description

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

o= (owner/creator and session identifier)

例如： o=mhandley28908445262890842807INIP4126.16.64.4 //o行中包含與會(huì)話所有者有關(guān)的參數(shù)（1：第一個(gè)參數(shù)表明會(huì)話發(fā)起者的名稱，該參數(shù)可不填寫，如填寫和SIP消息中，from消息頭的內(nèi)容一致:2：第二個(gè)參數(shù)為主叫方的會(huì)話標(biāo)識(shí)符:3：第三個(gè)參數(shù)為主叫方會(huì)話的版本，會(huì)話數(shù)據(jù)有改變時(shí)，版本號(hào)遞增:4：第四個(gè)參數(shù)定義了網(wǎng)絡(luò)類型，IN表示Internet網(wǎng)絡(luò)類型，目前僅定義該網(wǎng)絡(luò)類型:5：第五個(gè)參數(shù)為地址類型，目前支持IPV4和IPV6兩種地址類型:6：第六個(gè)參數(shù)為地址：表明會(huì)話發(fā)起者的IP地址，該地址為信令面的IP地址，信令PDP激活時(shí)為手機(jī)分配。）

s= (session name) //表明本次會(huì)話的標(biāo)題，或會(huì)話的名稱

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行又稱媒體行，描述了發(fā)送方所支持的媒體類型等信息（1：第一個(gè)參數(shù)為媒體名稱：表明支持音頻類型。2：第二個(gè)參數(shù)為端口號(hào)，表明UE在本地端口為3458上發(fā)送音頻流。3：第三個(gè)參數(shù)為傳輸協(xié)議，一般為RTP/AVP協(xié)議。4：四-七參數(shù)為所支持的四種凈荷類型編號(hào)）

m=video3400RTP/AVP9899 //m行又稱媒體行，描述了發(fā)送方所支持的媒體類型等信息

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)

最新評(píng)論