本篇作為學習Android流媒體的先導，先介紹以下四種協議：RTSP，HTTP，HTTPS和SDP。
1.RTSP協議
1）簡介
RTSP（Real Time Streaming Protocol），RFC2326，實時流傳輸協議，是TCP/IP協議體系中的一個應用層協議，該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或UDP完成數據傳輸。HTTP與RTSP相比，HTTP請求由客戶機發出，服務器作出響應；使用RTSP時，客戶機和服務器都可以發出請求，即RTSP可以是雙向的。RTSP是用來控制聲音或影像的多媒體串流協議，並允許同時多個串流需求控制，傳輸時所用的網絡通訊協定並不在其定義的范圍內，服務器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但並不特別強調時間同步，所以比較能容忍網絡延遲。實現RTSP的控制，還要有專門的媒體播放器和媒體服務器。媒體服務器和媒體播放器的關系是服務器同客戶的關系S/C。RTSP是使媒體播放器能夠控制多媒體流的傳送。RTSP又叫帶外協議，多媒體流使用RTP在帶內傳送。
2)RTSP的報文結構
RTSP有兩類報文：請求報文和響應報文。請求報文是從客戶端向服務器發送請求報文，響應報文是從服務器到客戶的應答。
RTSP在報文中的每一個字段都是一些ASCII碼串，每段的長度都不確定。
RTSP報文由三個部分組成，開始行、首部行和實體主體。RTSP請求報文的結構如下所示。
方法如下：
1.OPTION
目的是得到服務器提供的可用方法:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 1 //每個消息都有序號來標記，第一個包通常是option請求消息 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器的回應信息包括提供的一些方法,例如:
RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 1 //每個回應消息的cseq數值和請求消息的cseq相對應 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE, GET_PARAMETER //服務器提供的可用的方法
2.DESCRIBE
C向S發起DESCRIBE請求,為了得到會話描述信息(SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 2 token: Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器回應一些對此會話的描述信息(sdp):
RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 2 x-prev-url: rtsp://192.168.20.136:5000 x-next-url: rtsp://192.168.20.136:5000 x-Accept-Retransmit: our-retransmit x-Accept-Dynamic-Rate: 1 Cache-Control: must-revalidate Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT Date: Fri, 10 Nov 2006 12:34:38 GMT Expires: Fri, 10 Nov 2006 12:34:38 GMT Content-Base: rtsp://192.168.20.136:5000/xxx666/ Content-Length: 344 Content-Type: application/sdp v=0 //以下都是sdp信息 o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136 s=/xxx666 u=http:/// e=admin@ c=IN IP4 0.0.0.0 t=0 0 a=isma-compliance:1,1.0,1 a=range:npt=0- m=video 0 RTP/AVP 96 //m表示媒體描述，下面是對會話中視頻通道的媒體描述 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245; config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307 a=control:trackID=0//trackID＝0表示視頻流用的是通道0
3.SETUP
客戶端提醒服務器建立會話,並確定傳輸模式:
SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0 CSeq: 3 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) //uri中帶有trackID＝0，表示對該通道進行設置。
Transport參數設置了傳輸模式，包的結構。接下來的數據包頭部第二個字節位置就是interleaved，它的值是每個通道都不同的，trackID＝0的interleaved值有兩個0或1，0表示rtp包，1表示rtcp包，接受端根據interleaved的值來區別是哪種數據包。
服務器回應信息:
RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 3 Session: 6310936469860791894 //服務器回應的會話標識符 Cache-Control: no-cache Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567
4.PLAY
客戶端發送播放請求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 4 Session: 6310936469860791894 Range: npt=0.000- //設置播放時間的范圍 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器回應信息:
RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 4 Session: 6310936469860791894 Range: npt=0.000000- RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309 //seq和rtptime都是rtp包中的信息
5.TEARDOWN
客戶端發起關閉請求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 5 Session: 6310936469860791894 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
服務器回應:
RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 5 Session: 6310936469860791894 Connection: Close
以上方法都是交互過程中最為常用的,其它還有一些重要的方法如：get/set_parameter,pause,redirect等等。
RTSP請求報文的常用方法及作用
| 方法 | 作用 |
| OPTIONS | 獲得服務器提供的可用方法 |
| DESCRIBE | 得到會話描述信息 |
| SETUP | 客戶端提醒服務器建立會話，並確定傳輸模式 |
| TEARDOWN | 客戶端發起關閉請求 |
| PLAY | 客戶端發送播放請求 |
響應報文的結構如下圖。
3)RTSP交互過程
C是客戶端，S是服務端
① C->S: OPTION request //詢問S有哪些方法可用 S->C: OPTION response //S回應信息中包括提供的所有可用方法 ② C->S: DESCRIBE request //要求得到S提供的媒體初始化描述信息 S->C: DESCRIBE response //S回應媒體初始化描述信息，主要是sdp ③ C->S: SETUP request //設置會話屬性，以及傳輸模式，提醒S建立會話 S->C: SETUP response //S建立會話，返回會話標識符及會話相關信息 ④ C->S: PLAY request //C請求播放 S->C: PLAY response //S回應請求信息 S->C: 發送流媒體數據 ⑤ C->S: TEARDOWN request //C請求關閉會話 S->C: TEARDOWN response //S回應請求
上述的過程是標准的RTSP流程，其中第3步和第4步是必需的。
4）RTSP命令的狀態轉換表
RTSP中很多方法與狀態無關，但下列方法在定義服務器流資源的分配與應用上起着重要的作用：
(1) SETUP：讓服務器給流分配資源，啟動RTSP連接。
(2) PLAY與RECORD：啟動SETUP分配流的數據傳輸。
(3) PAUSE：臨時停止流，而不釋放服務器資源。
(4) TEARDOWN：釋放流的資源，RTSP連接停止。
5)點播視頻文件的例子
1. OPTIONS client-->server ======================================================================================================== OPTIONS rtsp://115.182.51.79/zuoyou001.mp4 RTSP/1.0 CSeq: 2 User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25) server-->client ======================================================================================================== RTSP/1.0 200 OK Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; ) Cseq: 2 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD 2. DESCRIBE client-->server ======================================================================================================== DESCRIBE rtsp://115.182.51.79/zuoyou001.mp4 RTSP/1.0 CSeq: 3 User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25) Accept: application/sdp server-->client ======================================================================================================== RTSP/1.0 200 OK Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; ) Cseq: 3 Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT Cache-Control: must-revalidate Content-length: 876 Date: Wed, 04 Jan 2012 06:14:53 GMT Expires: Wed, 04 Jan 2012 06:14:53 GMT Content-Type: application/sdp x-Accept-Retransmit: our-retransmit x-Accept-Dynamic-Rate: 1 Content-Base: rtsp://115.182.51.79/zuoyou001.mp4/ v=0 o=StreamingServer 3534646499 1011266430000 IN IP4 115.182.51.79 s=/zuoyou001.mp4 u=http:/// e=admin@ c=IN IP4 0.0.0.0 b=AS:632 t=0 0 a=control:* a=x-copyright: MP4/3GP File hinted with GPAC 0.4.6-DEV (build 1 - May 19 2009) - compiled by Kurtnoise (C)2000-2005 - http://gpac.sourceforge.net a=range:npt=0-6640.12667 m=video 0 RTP/AVP 96 b=AS:600 a=3GPP-Adaptation-Support:1 a=rtpmap:96 H264/90000 a=control:trackID=65536 a=fmtp:96 profile-level-id=4D401E; packetization-mode=1; sprop-parameter-sets=Z01AHpp0BaGdgIgAAAMACAAAAwGUeLF1,aO48gA== a=framesize:96 720-400 m=audio 0 RTP/AVP 97 b=AS:32 a=3GPP-Adaptation-Support:1 a=rtpmap:97 mpeg4-generic/24000/2 a=control:trackID=65537 a=fmtp:97 profile-level-id=40; config=131056e59d4800; streamType=5; mode=AAC-hbr; objectType=64; constantDuration=2048; sizeLength=13; indexLength=3; indexDeltaLength=3 3. SETUP client-->server ======================================================================================================== SETUP rtsp://115.182.51.79/zuoyou001.mp4/trackID=65536 RTSP/1.0 CSeq: 4 User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 server-->client ======================================================================================================== RTSP/1.0 200 OK Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; ) Cseq: 4 Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT Cache-Control: must-revalidate Session: 1837199341906602386 Date: Wed, 04 Jan 2012 06:14:53 GMT Expires: Wed, 04 Jan 2012 06:14:53 GMT Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=0E4646D1 4. SETUP client-->server ======================================================================================================== SETUP rtsp://115.182.51.79/zuoyou001.mp4/trackID=65537 RTSP/1.0 CSeq: 5 User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25) Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 1837199341906602386 server-->client ======================================================================================================== RTSP/1.0 200 OK Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; ) Cseq: 5 Session: 1837199341906602386 Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT Cache-Control: must-revalidate Date: Wed, 04 Jan 2012 06:14:53 GMT Expires: Wed, 04 Jan 2012 06:14:53 GMT Transport: RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=5B56A405 5. PLAY client-->server ======================================================================================================== PLAY rtsp://115.182.51.79/zuoyou001.mp4/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25) Session: 1837199341906602386 Range: npt=0.000- server-->client ======================================================================================================== RTSP/1.0 200 OK Server: DSS/6.0.3 (Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development; ) Cseq: 6 Session: 1837199341906602386 Range: npt=0.00000-6640.12667 RTP-Info: url=rtsp://115.182.51.79/zuoyou001.mp4/trackID=65536;seq=55088;rtptime=37707334,url=rtsp://115.182.51.79/zuoyou001.mp4/trackID=65537;seq=19114;rtptime=550154668 6. TEARDOWN client-->server ======================================================================================================== TEARDOWN rtsp://115.182.51.79/zuoyou001.mp4/ RTSP/1.0 CSeq: 7 User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25) Session: 1837199341906602386 server-->client ======================================================================================================== ******
2 HTTP協議
1）HTTP協議簡介
HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。它的發展是萬維網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終發布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。HTTP是一個應用層協議，由請求和響應構成，是一個標准的客戶端服務器模型。HTTP是一個無狀態的協議。HTTP協議通常承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。默認HTTP的端口號為80，HTTPS的端口號為443。如下圖所示：
2）HTTP的請求響應模型
HTTP協議永遠都是客戶端發起請求，服務器回送響應。HTTP協議是一個無狀態的協議，同一個客戶端的這次請求和上次請求是沒有對應關系。見下圖：
3）工作流程
一次HTTP操作稱為一個事務，其工作過程可分為四步：
1）首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作開始。
2） 建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3）服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。
4）客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客戶機與服務器斷開連接。
如果在以上過程中的某一步出現錯誤，那么產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的。
當我們在瀏覽器的地址欄輸入 www.XXX.com ，然后回車，回車這一瞬間到看到頁面到底發生了什么呢？
域名解析 --> 發起TCP的3次握手 --> 建立TCP連接后發起http請求 --> 服務器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶。
1.域名解析
首先Chrome瀏覽器會解析 www.XXX.com 這個域名（准確的叫法應該是主機名）對應的IP地址。怎么解析到對應的IP地址？
① Chrome瀏覽器 會首先搜索瀏覽器自身的DNS緩存（緩存時間比較短，大概只有1分鍾，且只能容納1000條緩存），看自身的緩存中是否有www.XXX.com 對應的條目，而且沒有過期，如果有且沒有過期則解析到此結束。
注：我們怎么查看Chrome自身的緩存？可以使用 chrome://net-internals/#dns 來進行查看
② 如果瀏覽器自身的緩存里面沒有找到對應的條目，那么Chrome會搜索操作系統自身的DNS緩存,如果找到且沒有過期則停止搜索解析到此結束.
注：怎么查看操作系統自身的DNS緩存，以Windows系統為例，可以在命令行下使用ipconfig /displaydns 來進行查看
③ 如果在Windows系統的DNS緩存也沒有找到，那么嘗試讀取hosts文件（位於C:\Windows\System32\drivers\etc），看看這里面有沒有該域名對應的IP地址，如果有則解析成功。
④ 如果在hosts文件中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統調用，就會向本地配置的首選DNS服務器（一般是電信運營商提供的，也可以使用像Google提供的DNS服務器）發起域名解析請求（通過的是UDP協議向DNS的53端口發起請求，這個請求是遞歸的請求，也就是運營商的DNS服務器必須得提供給我們該域名的IP地址），運營商的DNS服務器首先查找自身的緩存，找到對應的條目，且沒有過期，則解析成功。如果沒有找到對應的條目，則有運營商的DNS代我們的瀏覽器發起迭代DNS解析請求，它首先是會找根域的DNS的IP地址（這個DNS服務器都內置13台根域的DNS的IP地址），找打根域的DNS地址，就會向其發起請求（請問www.XXX.com這個域名的IP地址是多少啊？），根域發現這是一個頂級域com域的一個域名，於是就告訴運營商的DNS我不知道這個域名的IP地址，但是我知道com域的IP地址，你去找它去，於是運營商的DNS就得到了com域的IP地址，又向com域的IP地址發起了請求（請問www.XXX.com這個域名的IP地址是多少?）,com域這台服務器告訴運營商的DNS我不知道www.XXX.com這個域名的IP地址，但是我知道XXX.com這個域的DNS地址，你去找它去，於是運營商的DNS又向XXX.com這個域名的DNS地址（這個一般就是由域名注冊商提供的，像萬網，新網等）發起請求（請問www.XXX.com這個域名的IP地址是多少？），這個時候XXX.com域的DNS服務器一查，果真在我這里，於是就把找到的結果發送給運營商的DNS服務器，這個時候運營商的DNS服務器就拿到了www.XXX.com這個域名對應的IP地址，並返回給Windows系統內核，內核又把結果返回給瀏覽器，終於瀏覽器拿到了www.XXX.com 對應的IP地址，該進行一步的動作了。
注：一般情況下是不會進行以下步驟的 如果經過以上的4個步驟，還沒有解析成功，那么會進行如下步驟（以下是針對Windows操作系統）：
⑤ 操作系統就會查找NetBIOS name Cache（NetBIOS名稱緩存，就存在客戶端電腦中的），那這個緩存有什么東西呢？凡是最近一段時間內和我成功通訊的計算機的計算機名和Ip地址，就都會存在這個緩存里面。什么情況下該步能解析成功呢？就是該名稱正好是幾分鍾前和我成功通信過，那么這一步就可以成功解析。
⑥ 如果第⑤步也沒有成功，那會查詢WINS 服務器（是NETBIOS名稱和IP地址對應的服務器）
⑦ 如果第⑥步也沒有查詢成功，那么客戶端就要進行廣播查找
⑧ 如果第⑦步也沒有成功，那么客戶端就讀取LMHOSTS文件（和HOSTS文件同一個目錄下，寫法也一樣）
如果第八步還沒有解析成功，那么就宣告這次解析失敗，那就無法跟目標計算機進行通信。只要這八步中有一步可以解析成功，那就可以成功和目標計算機進行通信。
2.發起TCP的3次握手
拿到域名對應的IP地址之后，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務器的WEB程序（常用的有httpd,nginx等）80端口發起TCP的連接請求。這個連接請求（原始的http請求經過TCP/IP4層模型的層層封包）到達服務器端后（這中間通過各種路由設備，局域網內除外），進入到網卡，然后是進入到內核的TCP/IP協議棧（用於識別該連接請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於內核的模塊）的過濾，最終到達WEB程序（本文就以Nginx為例），最終建立了TCP/IP的連接。
1） Client首先發送一個連接試探，ACK=0 表示確認號無效，SYN = 1 表示這是一個連接請求或連接接受報文，同時表示這個數據報不能攜帶數據，seq = x 表示Client自己的初始序號（seq = 0 就代表這是第0號包），這時候Client進入syn_sent狀態，表示客戶端等待服務器的回復 。
2） Server監聽到連接請求報文后，如同意建立連接，則向Client發送確認。TCP報文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到對方下一個報文段的第一個數據字節序號是x+1，同時表明x為止的所有數據都已正確收到（ack=1其實是ack=0+1,也就是期望客戶端的第1個包），seq = y 表示Server 自己的初始序號（seq=0就代表這是服務器這邊發出的第0號包）。這時服務器進入syn_rcvd，表示服務器已經收到Client的連接請求，等待client的確認。
3） Client收到確認后還需再次發送確認，同時攜帶要發送給Server的數據。ACK 置1 表示確認號ack= y + 1 有效（代表期望收到服務器的第1個包），Client自己的序號seq= x + 1（表示這就是我的第1個包，相對於第0個包來說的），一旦收到Client的確認之后，這個TCP連接就進入Established狀態，就可以發起http請求了。
2個計算機通信是靠協議（目前流行的TCP/IP協議）來實現，如果2個計算機使用的協議不一樣，那是不能進行通信的，所以這個3次握手就相當於試探一下對方是否遵循TCP/IP協議，協商完成后就可以進行通信了，當然這樣理解不是那么准確。
3.建立TCP連接后發起http請求
進過TCP3次握手之后，瀏覽器發起了http的請求（看第包），使用的http的方法 GET 方法，請求的URL是 / ,協議是HTTP/1.0。
4.服務器端響應http請求，瀏覽器得到html代碼
服務器端WEB程序接收到http請求以后，就開始處理該請求，處理之后就返回給瀏覽器html文件。
5. 瀏覽器解析html代碼，並請求html代碼中的資源
瀏覽器拿到index.html文件后，就開始解析其中的html代碼，遇到js/css/image等靜態資源時，就向服務器端去請求下載（會使用多線程下載，每個瀏覽器的線程數不一樣），這個時候就用上keep-alive特性了，建立一次HTTP連接，可以請求多個資源，下載資源的順序就是按照代碼里的順序，但是由於每個資源大小不一樣，而瀏覽器又多線程請求請求資源，所以從下圖看出，這里顯示的順序並不一定是代碼里面的順序。
6.瀏覽器對頁面進行渲染呈現給用戶
最后，瀏覽器利用自己內部的工作機制，把請求到的靜態資源和html代碼進行渲染，渲染之后呈現給用戶。
4）協議格式
通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個指示頭域結束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。
（1）通用頭域
通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般將會作為實體頭域處理。
（2）請求消息
1.Host頭域
Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。
2.Referer頭域
Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鏈表，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由於維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發送。如果指定的是部分uri地址，則此地址應該是一個相對地址。
3.Range頭域
Range頭域可以請求實體的一個或者多個子范圍。例如，
表示頭500個字節：bytes=0-499
表示第二個500字節：bytes=500-999
表示最后500個字節：bytes=-500
表示500字節以后的范圍：bytes=500-
第一個和最后一個字節：bytes=0-0,-1
同時指定幾個范圍：bytes=500-600,601-999
但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200（OK）。
4.User-Agent頭域
User-Agent頭域的內容包含發出請求的用戶信息。
（3）響應消息
1.Location響應頭
Location響應頭用於重定向接收者到一個新URI地址。
2.Server響應頭
Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和注釋，產品標識一般按照重要性排序。
（4）實體信息
請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關於實體的原信息，實體頭包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。
1.Content-Type實體頭
Content-Type實體頭用於向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型 。
2.Content-Range實體頭
Content-Range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度。一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍，Content-Length表示實際傳送的字節數。
3.Last-modified實體頭
Last-modified實體頭指定服務器上保存內容的最后修訂時間。
例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍，Content-Length表示實際傳送的字節數。
3 HTTPS
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容請看SSL。
1）實現原理
有兩種基本的加解密算法類型：
（1）對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
（2）非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。 下面看一下https的通信過程：
2）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 個往返。 任何應用中,過多的round trip 肯定影響性能。
b) 接下來才是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容做加密/解密。
i. 盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 芯片。 如果CPU 信能比較低的話,肯定會降低性能,從而不能serve 更多的請求。
ii. 加密后數據量的影響。 所以，才會出現那么多的安全認證提示。
3）HTTPS和HTTP的區別
1.http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
2.https協議需要到ca申請證書，一般免費證書很少，需要交費。
3.http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議 。
4.http的連接很簡單,是無狀態的，而HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全 。
4 RTSP協議與HTTP協議的聯系與區別
RTSP協議負責在服務器和客戶端之間建立並控制一個或多個時間上同步的連續流媒體，其目標是像HTTP協議為用戶提供文字和圖形服務那樣為用戶提供連續媒體服務。因此，RTSP協議的設計在語法和操作上與HTTP協議很相似，這樣，對於HTTP的大部分擴展也適用於RTSP。
但是RTSP協議和HTTP協議在很多方面有着區別：
1. HTTP是一個無狀態協議，而RTSP協議是有狀態的。
2.HTTP本質上是一個非對稱協議，客戶端提出請求而服務器響應；而RTSP是對稱的，服務器和客戶端都可發送和響應請求。
5 SDP協議
SDP會話描述協議：為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。會話目錄用於協助多媒體會議的通告，並為會話參與者傳送相關設置信息。 SDP 即用於將這種信息傳輸到接收端。 SDP 完全是一種會話描述格式――它不屬於傳輸協議 ――它只使用不同的適當的傳輸協議，包括會話通知協議 （SAP） 、會話初始協議（SIP）、實時流協議 （RTSP）、 MIME 擴展協議的電子郵件以及超文本傳輸協議 （HTTP）。SDP 的設計宗旨是通用性，它可以應用於大范圍的網絡環境和應用程序，而不僅僅局限於組播會話目錄。
SDP是會話描述協議的縮寫，是描述流媒體初始化參數的格式，由IETF作為RFC 4566頒布。