前言：
下圖是對各協議進行了一個簡單對比，后面詳細介紹每一個協議。
一．Http漸進式：
首先，從傳輸方式上大致可以分為文件下載、HTTP漸進式下載、HTTP流式傳輸、實時流媒體傳輸四大類。
漸進式下載是通過在下載仍在執行時播放文件的已下載部分來傳遞媒體（邊下載邊播放）。支持Seek,終端播放器可從沒下載完成部分中任意選取一個時間點開始播放，如此來滿足不用等整個文件下載完快速播放的需求，一般MP4和FLV格式文件支持較好，打開一個視頻拖拽到中部，短暫緩沖即可播放，點擊暫停后文件仍將被持續下載就是典型的漸進式下載。
漸進式下載文件是介于下載文件和播放流媒體之間的一種形式。與流媒體相同，在開始播放漸進式下載的文件之前無需將整個文件存儲在計算機上。而與流媒體不同的是，在完成播放內容之后，整個漸進式下載的文件會保存在計算機上。
傳輸方式文件下載http漸進式Http流實時流
傳輸模式先下載，整個文件下載完成才能使用。邊下載，邊使用，沒有對文件分片邊下載邊使用，對文件進行了分片，是漸進式的升級建立一個connection，實時傳輸流信息。
傳輸結果需下載整個文件，且文件保存在本地。與文件下載的區別是可以從seek后下載，文件也保存本地碎片文件多，占用空間大。播完就扔，無需或只需少量緩存空間。
傳輸內容整個文件整個文件或文件的一部分。索引文件和分片文件將文件或直播信號編碼成實時流格式。
傳輸類型短連接短連接短連接長連接
傳輸協議Http/Ftp等Http基于Http的HLS/HDS/DASH等RTMP/RSTP等是實時流控制協議。
點播--索引文件包含所有切片下載地址，依次下載切片文件。建立一個Connection，邊下邊播，實時傳輸
直播--實時更新索引文件，根據索引文件下載切片文件建立一個Connection，邊放邊播，實時更新流。
測試：（某視網Flash直播回看，應該是屬于點播）
測試環境：win10 64位
測試平臺：chorm
測試頻道：cctv1
協議：Http協議漸進式
測試賬號：
測試結果：（主意看右邊信息）
端口號是8000，不論播放狀態還是暫停狀態，Response Size始終在增大，seek之后重新下載。
二．HLS協議：
HTTP Live Streaming（縮寫是HLS）是一個由蘋果公司提出的基于HTTP的流媒體網絡傳輸協議。
相關模塊：
Media encoder：用于將設備輸出的流進行轉碼，并封裝成MPEG-2傳輸流。
Stream segmenter：用于直播，將MPEG-2流分割成多個小片段后輸出（m3u8和ts切片）。
File segmenter：用于點播，將MPEG-2流分割成多個小片段后輸出（m3u8和ts切片）。
?原理：
簡單講就是把整個流分成一個個小段，基于?HTTP?的文件來下載，每次只下載一些，傳輸內容包括兩部分：一是m3u8純文本索引文件，二是TS媒體文件。簡單的傳輸方式就是在一個m3u8中包含ts切片的url列表，依次下載播放。如下圖所示：
還有就是有多級索引，如下圖所示，客戶端先下載一級Index file，它里面記錄了二級索引文件（Alternate-A、Alternate-B、Alternate-C）的地址，然后客戶端再去下載二級索引文件，該文件是按照帶寬不同劃分了不同分辨率的切片文件，然后客戶端就可以根據實際的貸款按順序下載TS視頻文件并連續播放以實現碼率自適應。
一般為了加快速度，.m3u8?放在?web?服務器上，ts?文件放在?cdn?上。.m3u8?文件，其實就是以?UTF-8?編碼的m3u?文件，這個文件本身不能播放，只是存放了播放信息的文本文件：
標簽含義：
? ? ? A： #EXTINF指示出下面TS片的時間長度，單位是秒，可以是整數也可以浮點數，浮點數一般精確到小數點后面3位。在示例中，第一個ts的時長為8秒。
同時，EXTINF也影響了播放器刷新M3U8文件的間隔，正常情況下，播放器會把當前下載的TS片的EXTINF的值作為每次刷新M3U8文件的間隔；如果播放器發現本次取到的M3U8文件內容沒有更新，會在1-2秒內再次刷新。
B：ts切片的時長不能大于#EXT-X-TARGETDURATION的值
C：#EXT-X-ENDLIST這個表示視頻結束，有這個標志同時也說明當前的流是一個非直播流（有結束的意思）。
D：#EXT-X-PLAYLIST-TYPE:VOD的意思是當前的視頻流并不是一個直播流，而是點播流。
直播：
1．http?請求?m3u8?的?url（包含部分播放列表，沒有結束標識）。
2.?服務端返回一個?m3u8?的播放列表，這個播放列表是實時更新的（類似于滑動窗口機制），一般一次給出5段數據的?url。
3.?客戶端解析?m3u8?的播放列表，再按序請求每一段的?url，獲取?ts?數據流。
點播：
1．http?請求?m3u8?的?url。（包含所有播放列表，有結束標識）。
2.解析?m3u8?的播放列表，再按序請求每一段的?url，獲取?ts?數據流。
備注：hls 協議是將直播流分成一段一段的小段視頻去下載播放的，所以假設列表里面的包含5個 ts 文件，每個 TS 文件包含5秒的視頻內容，那么整體的延遲就是25秒。因為當你看到這些視頻時，已經將視頻錄制好上傳上去了，所以時這樣產生的延遲。當然可以縮短列表的長度和單個 ts 文件的大小來降低延遲，極致來說可以縮減列表長度為1，并且 ts 的時長為1s，但是這樣會造成請求次數增加，增大服務器壓力，當網速慢時回造成更多的緩沖，所以蘋果官方推薦的ts時長時10s，所以這樣就會大概有30s的延遲。
? ?弊端：
? 1.采用HLS協議直播的視頻延遲時間無法下到10秒以下，所以說對直播延遲比較敏感的服務請慎用HLS。（偽直播）。
? 2. 對于點播服務來說,?由于?TS?切片通常較小,?海量碎片在文件分發,?一致性緩存,?存儲等方面都有較大挑戰。
測試：（某視網H5）
測試環境：win10 64位
?測試平臺：chorm
?播放器類型：H5
?協議：HLS協議
測試結果：
（測試類型：直播）
M3u8每次更新一個，類似于滑動窗口機制，第一次是列表12345，第二次是23456，第三次事34567，然后按列表地址下載ts切片，直播暫停，m3u8文件繼續更新，ts文件停止下載。直播繼續播放，繼續下載ts切片。下圖為央視網直播時連續更新三次m3U8文件的截圖：
（測試類型：點播）
M3u8一次性包含所有ts文件播放列表，依次進行下載播放，暫停的時候ts切片不下載，播放繼續下載，seek進度條的時候，ts切片會從選擇位置開始下載。下圖為某視網點播seek的ts片段。如下圖：
三．RTMP協議：
Real Time Message Protocol(RTMP)實時信息傳輸協議，它是由Adobe公司提出的一種應用層的協議。與HLS等基于Http的其他協議相比，Http協議是本地播放，而RTMP協議是服務器實時播放。
原理：
RTMP傳輸媒體數據的過程中，服務器端端首先把媒體數據封裝成消息，然后把消息分割成消息塊，最后將分割后的消息塊通過TCP協議發送給客戶端。客戶端在通過TCP協議收到數據后，首先把消息塊重新組合成消息，然后通過對消息進行解封裝處理就可以恢復出媒體數據。
RTMP協議規定，播放一個流媒體有幾個前提步驟：握手，建立連接，建立流，播放。其中，網絡連接代表服務器端應用程序和客戶端之間基礎的連通關系。網絡流代表了發送多媒體數據的通道。服務器和客戶端之間只能建立一個網絡連接，但是基于該連接可以創建很多網絡流。
過程：
1. 握手（HandShake）
一個RTMP連接以握手開始，雙方分別發送大小固定的三個數據塊
a)握手開始于客戶端發送C0、C1塊。服務器收到C0或C1后發送S0和S1。
b)當客戶端收齊S0和S1后，開始發送C2。當服務器收齊C0和C1后，開始發送S2。
c)當客戶端和服務器分別收到S2和C2后，握手完成。
3-1 握手
2.建立網絡連接（NetConnection）
a)客戶端發送命令消息中的“連接”(connect)到服務器，請求與一個服務應用實例建立連接。
b)服務器接收到連接命令消息后，發送確認窗口大小(Window Acknowledgement Size)協議消息到客戶端，同時連接到連接命令中提到的應用程序。
c)服務器發送設置帶寬()協議消息到客戶端。
d)客戶端處理設置帶寬協議消息后，發送確認窗口大小(Window Acknowledgement Size)協議消息到服務器端。
e)服務器發送用戶控制消息中的“流開始”(Stream Begin)消息到客戶端。
f)服務器發送命令消息中的“結果”(_result)，通知客戶端連接的狀態。
3-2 建立連接
3建立網絡流（NetStream）
a)客戶端發送命令消息中的“創建流”（createStream）命令到服務器端。
b)服務器端接收到“創建流”命令后，發送命令消息中的“結果”(_result)，通知客戶端流的狀態。
3-3 建立流
4 播放（Play）
a)客戶端發送命令消息中的“播放”（play）命令到服務器。
b)接收到播放命令后，服務器發送設置塊大小（ChunkSize）協議消息。
c)服務器發送用戶控制消息中的“streambegin”，告知客戶端流ID。
d)播放命令成功的話，服務器發送命令消息中的“響應狀態” NetStream.Play.Start & NetStream.Play.reset，告知客戶端“播放”命令執行成功。
e)在此之后服務器發送客戶端要播放的音頻和視頻數據。
結構：
RTMP協議中基本的數據單元稱為消息（Message）。當RTMP協議在互聯網中傳輸數據的時候，消息會被拆分成更小的單元，稱為消息塊（Chunk）。
1?消息
消息是RTMP協議中基本的數據單元。不同種類的消息包含不同的Message Type ID，代表不同的功能。RTMP協議中一共規定了十多種消息類型，分別發揮著不同的作用。例如，Message Type ID在1-7的消息用于協議控制，這些消息一般是RTMP協議自身管理要使用的消息，用戶一般情況下無需操作其中的數據。Message Type ID為8，9的消息分別用于傳輸音頻和視頻數據。Message Type ID為15-20的消息用于發送AMF編碼的命令，負責用戶與服務器之間的交互，比如播放，暫停等等。消息首部（Message Header）有四部分組成：標志消息類型的Message Type ID，標志消息長度的Payload Length，標識時間戳的Timestamp，標識消息所屬媒體流的Stream ID。消息的報文結構如圖3所示。
3-4-1 消息
2?消息塊
在網絡上傳輸數據時，消息需要被拆分成較小的數據塊，才適合在相應的網絡環境上傳輸。RTMP協議中規定，消息在網絡上傳輸時被拆分成消息塊（Chunk）。消息塊首部（Chunk Header）有三部分組成：用于標識本塊的Chunk Basic Header，用于標識本塊負載所屬消息的Chunk Message Header，以及當時間戳溢出時才出現的Extended Timestamp。消息塊的報文結構如圖4所示。
3-4-2?消息塊
3?消息分塊
在消息被分割成幾個消息塊的過程中，消息負載部分（Message Body）被分割成大小固定的數據塊（默認是128字節，最后一個數據塊可以小于該固定長度），并在其首部加上消息塊首部（Chunk Header），就組成了相應的消息塊。消息分塊過程如圖5所示，一個大小為307字節的消息被分割成128字節的消息塊（除了最后一個）。
3-4-3 消息分塊
RTMP傳輸媒體數據的過程中，發送端首先把媒體數據封裝成消息，然后把消息分割成消息塊，最后將分割后的消息塊通過TCP協議發送出去。接收端在通過TCP協議收到數據后，首先把消息塊重新組合成消息，然后通過對消息進行解封裝處理就可以恢復出媒體數據。
Audio data包：
RTMP Header：
?1.基本頭包括兩個信息，Format + Chunk Stream ID。
2.Timestamp:時間戳，3字節。
3.Extended timestamp：當時間值很大?(>= 0x00FFFFFF)時,?上述的Timestamp字段不能傳遞這樣的數值,?因為Timestamp字段只有3個字節,此時需要使用擴展字段Extended Timestamp,?該字段是4個字節。
4.Body size：消息長度，3字節。
5.Type ID：消息類型id，1字節。
6.Stream ID：消息流id，4字節。
Video包Header和audio
RTMP Body：
1.第一個字節af，a就是10，代表AAC編碼格式。
2.第一個字節中的后四位f代表如下：
前2個bit的含義采樣頻率，這里是二進制11，代表44kHZ?的采樣頻率。
? ? 0 = 5.5 kHz ，1 = 11 kHz?，2 = 22 kHz?，3 = 44 kHz
第3個bit，代表 音頻用16位的樣本大小。
? ? 0 = 8-bit samples ，1 = 16-bit samples
第4個bit代表聲道
? ? 0 = Mono sound（單聲道） ，1 = Stereo sound（立體聲）
3.第2個字節，AACPacketType，這個字段來表示AACAUDIODATA的類型：0 = AAC sequence header，1 = AAC raw。第一個音頻包用0，后面的都用1。
測試：（中國經濟網絡電視Flash）
測試環境：win10 64位
測試平臺：chorm
測試頻道：中經電視（http://cen.ce.cn/）；宣傳生活頻道()
協議：RTMP協議
測試賬號：
測試結果：
網上搜了一堆RTMP協議測試地址，但是用charles抓包并沒有看到明顯的有用信息，于是做了很多嘗試，為了確定該網站用的是RTMP協議，我先打開了網站視頻，用“netstat -aon|findstr “1935””看了一下是否有端口號1935的ip，1935是RTMP協議的端口號，后來我又用WiresShark進行抓包，對RTMP協議請求流程做了驗證，實際播放流程跟理論播放流程有一些出入，結果如下圖：
以下是宣城經濟生活頻道的RTMP協議抓包：
對比兩個節目，請求流程還是有點不同，所以猜測，兩個平臺都對RTMP協議做了一定處理。
四．HDS協議：
? ? ? Http Dynamic Streaming（HDS）是一個由Adobe公司模仿HLS協議提出的另一個基于Http的流媒體傳輸協議。其模式跟HLS類似，但是又要比HLS協議復雜一些，也是索引文件和媒體切片文件結合的下載方式。
原理：
? ? ?在服務器端降一個視頻文件分割成segment節，segment節表示的是這個視頻的幾種不同的分辨率模式，針對某種分辨率的segment節，可以再劃分成fragmen片段，每個片段都是視頻的一小段時間，分段后每個片段會有segment+fragment的索引，客戶端會根據索引請求視頻片段。索引文件可以是.f4m的manifest文件，也可以是.bootstrap文件，在某視網的測試就發現它是采取的后者。
相關模塊：
Live Packager :該工具只針對ＨＤＳ，同時集成在ＦＭＳ（３．８以上）。它可以實時測量RTMP流(live),并將之轉化成新的\.f4f文件，滿足實時性要求。內置的apache服務器使用HTTP ORIGIN MODULE對生成的文件進行解析，然后提供出HTTP流。
File Packager：一個命令行工具,它可以按照需求把多媒體文件形成流碎片并把碎片寫進.f4f文件。
HTTP ORIGIN MODULE:HDS的重要組成部分，其為apache的一個modules，負責對(.f4f/.f4m/.f4x/.bootstrap/.drmmeta)等文件進行解析，然后轉換成HTTP流輸出。
OSMF Player:一個開源的播放器，建立在Open Source Media Framework(OSMF)的框架上，支持HTTP流，要求Flash player 10.1或以上。
文件類型：
?.f4f：分段文件，包含視頻數據，每個文件包含源文件的一個分段（segment）。每個segment可以包含更多的碎片（fragment）。每個片段或碎片都有自己的引導信息，提供緩存管理喝快速搜索。播放器可以根據這些信息去請求每個segment或fragment。
.f4m:媒體描述文件，包含媒體的編解碼信息，多比特率等等。
.f4x:索引文件，包含指定分片在流中的位置。
.bootstrap：引導文件，引導信息可能來自于bootstrap,也可能來自于.f4m文件（寫在bootstrapInfo標簽中），取決于是否指定external-bootsrtap選項（Using the bootstrap information (run tables) contained in the file, the client translates the desired timecode to a segment number/fragment number pair. the client then constructs a URL based on this number pair, which requests a specific fragment from a specific F4F file.）
.drmmeta:用于保存加密信息，也需要使用external-bootstrap引用進來。
請求流程：
１．客戶端向Web服務器發送一個HTTP請求，例如http://www.example.com/media/http_dynamic_Streaming.f4m。
２．服務器將收到的請求傳遞給HTTP Origin Module。
３.HTTP Origin Module將描述文件（F4M）返回到客戶端。
４.客戶端收到描述文件（F4M），根據?bootstrap中的信息中的傳送時間，組成一個segment#/fragment#對。
５.然后客戶端解析F4M的內容向服務器發送一個請求，比如http://www.example.com/media/http_dynamic_StreamingSeg1-Frag1（segment中的fragmen片段）或者http://www.example.com/media/http_dynamic_StreamingSeg1.f4f。（segment）
圖. 碎片化內容（F4F）的結構
６.服務器返回相應的視頻片段。
７.客戶端接收分片，處理之后播放。
標簽含義
.bootstrap：
abst： 表示HDS內容的總體信息 adobe bootstrap Info box table
asrt：表示segment總體信息 adobe segment run table
afrt： 表示fragment總體信息 adobe fragment run table
manifest：
StraemType :流類型
BootstrapInfo：引導信息，可以寫在標簽內，也可以再指定一個url。（上圖就是采用了后者）
Media：媒體文件的url或者url的一部分。碼率不同，url地址不同。
Mediadata：編解碼相關信息。
優勢
1.不需要防火墻開普通web瀏覽器所需端口以外的任何端口
2.允許視頻切片在瀏覽器、網關和CDN的緩存，從而顯著降低源服務器的負載。
3.HDS 的文件格式為?FLV/F4V/MP4，索引文件為?f4m，同時支持直播和時移。
測試：（某視網Flash）
測試環境：win10 64位
測試平臺：chorm
測試頻道：
協議：HDS協議
測試類型：直播
測試結果：
以下是chales抓到的截圖：
? ? ? 測試發現，客戶端先請求服務器返回一個時間，然后根據這個時間請求manifest文件，根據manifest文件下載index.bootstrap文件，根據index。Bootstrap文件中的信息，請求分片文件。媒體分片每下載5次，更新一次index.bootstrape文件，不同于HLS協議的是，直播暫停的時候，分片文件停止下載，index.bootstrap文件也停止更新，在視覺上跟點播一樣，重新播放也還是能接上上次播放位置，但是暫停時間越長，index.bootstrap文件的更新時間就越久（bootstrap中的分片索引表就越長）。以下是暫停前和播放后更新index.bootstrap中數據的截圖：
? ? ? ?雖然看不出數據內容，但可以看出數據長度的變化。這樣不停的暫停，與實際直播內容的延時就越來越大，測試發現，當長度到達一定數量，也就是播放內容和實際直播內容的延時達到一定程度，服務器緩存中不存在請求的url，報404錯誤，客戶端會重新請求manfist文件，然后下載index.bootstrap文件，再下載相應切片，跟一開始流程一致。暫時沒有找到點播的測試案例。
五.MPEG-DASH協議
Dynamic Adaptive Streaming over HTTP（縮寫DASH）,是國際標準組MPEG制定的技術標準。
原理：
DASH協議原理跟HLS協議差不多，都是將文件分成一片片小段進行分發，也是分為MPD索引文件和媒體分片文件。客戶端首先請求服務器下載解析MPD文件，獲取碼率等信息，然后根據實際帶寬情況去請求某種碼率的媒體分片文件以實現自適應切換。MPD?可以以不同的方式，例如SegmentList，SegmentTemplate，SegmentBase和SegmentTimeline，根據使用情況下進行組織。
標簽含義：
Period:一條完整的mpeg dash碼流可能由一個或多個Peroid組成，每個Period代表一個時間段。比如一個碼流是60s，Peroid1是0-10s，Peroid2是11-30，Peroid3是31-60。
Representation：表示不同碼率的碼流，實際播放的時候，視頻會在一個AdaptationSet中的不同Representaiton?之間切換碼率，會依次請求該Representaiton下不同Segment序列。
Segment：每一個具體的片段。（1,2,4,6,10s …）?。MPD中描述segment?URL的形式有多種，如Segment?list，Segment?template，Single?segment。
AdaptationSet：包含了媒體呈現的形式（視頻/音頻/字幕），AdaptationSet由一組可供切換的不同碼率的碼流（Representation）組成。
測試：（TVB）
測試環境：win10 64位
測試平臺：chorm
測試頻道：翡翠臺（https://qa.mytvsuper.com/tc/live/81）
協議：MPEG DASH協議
測試賬號：
測試結果：
? ? ? （測試類型：點播）
下圖是用charles抓取的.mpd數據截圖：
視頻列表
音頻列表
以下是媒體分片的請求列表截圖：
測試發現，點播暫停切片文件都不再下載，播放繼續下載，廣告和視頻都是一個文件。Seek后，跳到相應列表位置下載。
觀察上圖，可以發現規律，比如音頻第一個數字后綴是0，第二個是441353，第三個441353 +440294 = 881647正好是初始化后的第二個音頻切片文件命的數字后綴部分，就是按照上述列表一次累加，視頻的url也是這樣。
（測試類型：直播）
測試發現，客戶端首先發起一個請求，服務器返回一個session，然后用客戶端用這個session請求.mpd文件，根據mpd文件再請求切片文件。
以下是切片的格式：
(字幕)
（音頻）
（視頻）
Mime type類型注釋：
Application：用于傳輸應用程序數據或者二進制數據；
Audio：用于傳輸音頻或者音聲數據；
Video：用于傳輸動態影像數據，可以是與音頻編輯在一起的視頻數據格式。
Text：用于標準化地表示的文本信息，文本消息可以是多種字符集和或者多種格式的；
Multipart：用于連接消息體的多個部分構成一個消息，這些部分可以是不同類型的數據；
Message：用于包裝一個E-mail消息；
Image：用于傳輸靜態圖片數據；
測試中無法確定url數字后綴的第一個值，經多次測試都沒有找到SegmentTemplate的明顯規律，但累加的值還是按照這個列表，猜測初始值中間可能經過了某種算法，根據點播的測試以及列表的更新情況（mpd更新類似于HLS協議m3u8,每次更新一個）分析，它跟HLS協議的模式應該是相同的。
以下是mpd中更新四次的截圖：
