從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數據通過的防火墻或者代理服務器。它也很容易使用內容分發網絡來傳輸媒體流。
蘋果公司把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遵循請求(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协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。