rtsp與http協議

標籤：查詢   erro   開始   分布   支援   排列   決定   app   port   

從RTSP協議（傳輸媒體流）的直播到 HTTP TS（ts分區 編碼器之後的ts分區,html檔案）(APPLE的Live streaming方案)轉換工作。

HTTP Live Streaming（縮寫是HLS）是一個由蘋果公司提出的基於HTTP的流媒體網路傳輸協議。是蘋果公司QuickTime X和iPhone軟體系統的一部分。它的工作原理是把整個流分成一個個小的基於HTTP的檔案來下載，每次只下載一些。當媒體流現正播放時，用戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的資料速率。在開始一個流媒體會話時，用戶端會下載一個包含中繼資料的extended M3U (m3u8)playlist檔案，用於尋找可用的媒體流。
HLS只請求基本的HTTP報文，與即時傳輸協議（RTP)不同，HLS可以穿過任何允許HTTP資料通過的防火牆或者Proxy 伺服器。它也很容易使用內容分髮網絡來傳輸媒體流。
蘋果公司把HLS協議作為一個互連網草案（逐步提交），在第一階段中已作為一個非正式的標準提交到IETF。但是，即使蘋果偶爾地提交一些小的更新，IETF卻沒有關於制定此標準的有關進一步的動作。

一、RTSP
1、簡介
     Real Time Streaming Protocol即時資料流媒體協議，是應用程式層協議，控制即時資料的傳送。它提供了一個可擴充的架構，使得能夠可控按需傳輸即時資料。但RTSP本身並不發送連續媒體流，只充當了多媒體伺服器的網路遠端控制。
2、協議特點
    ? 可擴充性：很容易加入新方法和參數。
    ? 易解析：可由標準HTTP或MIME解析器解析。
    ? 安全：使用網頁安全機制，也可以使用傳輸層或網路層安全機制。
    ? 獨立傳輸：可使用不可靠資料報協議（UDP）、可靠資料報協議（RDP）；如果想要實現應用級可靠，也可使用可靠流協議。
    ? 多伺服器支援
    ? 記錄裝置控制：協議可控制記錄和回放裝置。
    ? 流控與會議開始分離
    ? 適合專業應用：支援幀級精度，允許遠程數字編輯。
    ? 表示描述中立
    ? 代理與防火牆友好：可由應用程式層和傳輸層防火牆處理。
    ? HTTP友好：很多定義文法與HTTP/1.1相似
    ? 傳輸協調
    ? 效能協調
3、訊息格式
     RTSP訊息由用戶端到伺服器的請求和由伺服器到用戶端的回應組成。
        RTSP -message = Request | Response ; RTSP /1.0 messages
     請求（Request）和回應（Response）訊息都使用RFC822中實體傳輸部分規定的訊息格式。兩者的訊息都可能包括一起始行，一個或多個前序域（headers）、一行表示前序域結束的空行（即CRLF前沒有內容的行），和一個訊息主體（message-body）。
        generic-message = start-line
        *message-header
        CRLF
        [ message-body ]
        tart-line = Request-Line | Status-Line
     同時為了健壯性考慮，伺服器應該忽略任何在期望收到請求行時收到的空行。換句話說，如果伺服器正在讀協議流，在一個訊息開始時如果首先收到了CRLF，這個CRLF符應被忽略。
     RTSP前序域包括主前序、請求前序、回應前序及實體前序，都遵照RFC822給出的通用格式定義。每個前序域由後緊跟冒號的名字，單空格（SP），字元及域值組成。網域名稱是大小寫敏感的。
        RTSP-header = field-name ":" [ field-value ] CRLF
        field-name = token
        field-value = *( field-content | LWS )
        field-content = <the OCTETs make up the field-value
        and consisting of either *TEXT or combinations
        of token, tspecials, and quoted-string>
      前序域接收的順序並不重要，但良好的習慣是，先發送主前序，然後是請求前序或回應前序，最後是實體前序。若且唯若前序域的全部域值都用逗號分隔的列表示時（即，#（值）），多個有相同網域名稱的RTSP前序域才可以表示在一個訊息裡。而且必須能在不改變訊息文法的前提下，將並發的域值加到第一個值後面，之間用逗號分隔，最終能將多個前序域結合成“網域名稱：域值”對。
      RTSP訊息的訊息主體用來攜帶請求或回應的主體。僅在使用傳輸編碼(Transfer-Encoding)時訊息主體和實體主體才有所不同。
        message-body = entity-body
      當訊息包含訊息主體時，訊息主體的長度由以下規則來決定（按優先順序高低順序排列）：
? 任何回應訊息都不包含訊息主體（如1××，204和304回應），並且不管訊息中是否存在實體前序域都以訊息前序域後的第一行空行表示結束。
? 如果內容長度前序域存在，它在位元組中的值就是訊息主體的長度。如果內容前序域不存在，則假設值為零。
? 伺服器關閉串連時。（關閉串連沒有用來表明請求主體結束，否則可能導致伺服器不能回應）。
      儘管表示描述長度動態產生，但由於可獲得了表示描述返回長度，使得伺服器總是能決定表示描述長度而不需使用塊傳輸編碼方式。只要有實體主體就必須有內容長度項，這些規則保證了即使沒有給出明確長度也能做出合理的操作。
4、RTSP串連方式
     RTSP請求可以支援幾中不同方式傳送：
        ? 持久傳輸串連，用於多個請求/回應傳輸。
        ? 每個請求/回應傳輸一個串連。
        ? 無串連模式
     傳輸連線類型由RTSP URI來定義。對 \"rtsp\" 方案，需要持續串連；而\"rtspu\"方案，調用RTSP 請求發送，而不用建立串連。
與HTTP不同，RTSP允許媒體伺服器給媒體使用者發送請求。然而，這僅在持久串連時才支援，否則媒體伺服器沒有可靠途徑到達使用者，這也是請求通過防火牆從媒體伺服器傳到使用者的唯一途徑。

二、HTTP
1、簡介
     HTTP超文字傳輸通訊協定 (HTTP)是分布式、協作的、超媒體資訊系統的應用程式層協議。HTTP遵循請求(Request)/應答(Response)模型，並且是一種無串連無狀態的協議，當一個用戶端向伺服器端發出請求，然後Web伺服器返迴響應(response)，串連就被關閉了，在伺服器端不保留串連的有關資訊。
2、協議特點
? 支援客服/伺服器模式
? 簡單快速：客戶向伺服器請求服務時，只需傳送要求方法和路徑。
? 靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以標記。
? 無串連：不需連線的含義是限制每次串連只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即中斷連線。採用這種方式可以節省傳輸時間。
? 無狀態：無狀態是指協議對於交易處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次串連傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。
3、HTTP的URL說明
     HTTP常基於TCP的串連方式，HTTP1.1版本中給出一種持續串連的機制，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。
     HTTP URL的格式如下：
        http://host[":"port][abs_path]
     http表示要通過HTTP協議來定位網路資源；host表示合法的Internet主機網域名稱或者IP地址；port指定一個連接埠號碼，為空白則使用預設連接埠80；abs_path指定請求資源的URI；如果URL中沒有給出abs_path，那麼當它作為請求URI時，必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
        輸入：www.guet.edu.cn
        瀏覽器自動轉換成：http://www.guet.edu.cn/
4、HTTP訊息前序說明
      HTTP訊息由用戶端到伺服器的請求和伺服器到用戶端的回應群組成。請求訊息和響應訊息都是由開始行（對於請求訊息，開始行就是請求行，對於響應訊息，開始行就是狀態行），訊息前序（可選），空行（只有CRLF的行），訊息本文（可選）組成。
      HTTP訊息前序包括普通前序、請求前序、響應前序、實體前序。
      每一個前序域都是由名字+“：”+空格+值 組成，訊息前序域的名字是大小寫無關的。
5、HTTP請求說明
     HTTP請求由三部分組成分別是請求行、訊息前序、請求本文。
     請求行以一個方法符號開頭，以空格分開，後面跟著請求的URI和協議的版本，格式如下：
        Method Request-URI HTTP-Version CRLF
     其中 Method表示要求方法，Request-URI是一個統一資源識別項，HTTP-Version表示請求的HTTP協議版本，CRLF表示斷行符號和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字元）。
     要求方法（所有方法全為大寫）有多種，各個方法的解釋如下：
        GET 請求擷取Request-URI所標識的資源
        POST 在Request-URI所標識的資源後附加新的資料
        HEAD 請求擷取由Request-URI所標識的資源的響應訊息前序
        PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識
        DELETE 請求伺服器刪除Request-URI所標識的資源
        TRACE 請求伺服器回送收到的請求資訊，主要用於測試或診斷
        CONNECT 保留將來使用
        OPTIONS 請求查詢服務器的效能，或者查詢與資源相關的選項和需求
6、HTTP響應說明
     在接收和解釋請求訊息後，伺服器返回一個HTTP響應訊息。也由三部分組成：狀態行、訊息前序、響應本文。
     狀態行格式如下：
        HTTP-Version Status-Code Reason-Phrase CRLF
     其中，HTTP-Version表示伺服器HTTP協議的版本，Status-Code表示伺服器發回的響應狀態碼，Reason-Phrase表示狀態碼的文本描述。
     狀態碼有三位元字組成，第一個數字定義了響應的類別，且有五種可能取值：
        1xx：指示資訊--表示請求已接收，繼續處理
        2xx：成功--表示請求已被成功接收、理解、接受
        3xx：重新導向--要完成請求必須進行更進一步的操作
        4xx：用戶端錯誤--請求有語法錯誤或請求無法實現
        5xx：伺服器端錯誤--伺服器未能實現合法的請求
     其中常見狀態碼、狀態原因、說明：
        200 OK //用戶端請求成功
        400 Bad Request //用戶端請求有語法錯誤，不能被伺服器所理解
        401 Unauthorized //請求未經授權，這個狀態碼必須和WWW-Authenticate前序域一起使用
        403 Forbidden //伺服器收到請求，但是拒絕提供服務
        404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
        500 Internal Server Error //伺服器發生不可預期的錯誤
        503 Server Unavailable //伺服器當前不能處理用戶端的請求，一段時間後可能恢複正常
     響應本文就是伺服器返回的資源內容。

三、RTSP與HTTP區別
1、相同點
? RTSP、HTTP都是在應用應用程式層。
? 理論上RTSP、HTTP都可以做直播和點播，但一般做直播用RTSP，做點播用HTTP。
? RTSP在文法和操作上與HTTP類似。全是基於tcp的連結
2、不同點
? RTSP引入了很多新方法並且有不同的協議標識符。
? RTSP伺服器在大多數預設情況下需要維持一個狀態，但HTTP是無狀態協議。
? RTSP客戶機和伺服器都可以發出請求。
? RTSP的資料由另一個協議傳送（有一特例除外）。
? RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化。
? RTSP使用URI請求時包含絕對URI。而HTTP1隻在請求中包含絕對路徑，把主機名稱放入單獨的前序域中。
2. HTTP本質上是一個非對稱協議，用戶端提出請求而伺服器響應；而RTSP是對稱的，伺服器和用戶端都可發送和響應請求。
rtsp和http的區別和聯絡
    （1）聯絡：兩者都用純文字來發送訊息，且rtsp協議的文法也和HTTP類似。Rtsp一開始這樣設計，也是為了能夠相容使用以前寫的HTTP協議分析代碼 。
    （2）區別：rtsp是有狀態的，不同的是RTSP的命令需要知道現在正處於一個什麼狀態，也就是說rtsp的命令總是按照順序來發送，某個命令總在另外一個命令之前要發送。Rtsp不管處於什麼狀態都不會去斷掉串連。，而http則不儲存狀態，協議在發送一個命令以後，串連就會斷開，且命令之間是沒有依賴性的。rtsp協議使用554連接埠，http使用80連接埠。

rtsp與http協議