目前主流的直播架構(gòu)中主要有兩種方案，即流媒體轉(zhuǎn)發(fā)、P2P。流媒體轉(zhuǎn)發(fā)，是一種在視頻直播中以流的方式將連續(xù)的音、視頻數(shù)據(jù)經(jīng)編碼壓縮后傳輸?shù)搅髅襟w服務(wù)器，用戶實(shí)時(shí)從服務(wù)器獲取流媒體資源，而不必要等待整個(gè)文件下載文件完畢的C/S架構(gòu)視頻直播方案；P2P直播，是一種建立在P2P技術(shù)基礎(chǔ)上的視頻直播方案，它規(guī)定客戶端之間使用一定協(xié)議來(lái)交換和共享直播數(shù)據(jù)，通過(guò)減少對(duì)服務(wù)器的數(shù)據(jù)請(qǐng)求，以降低服務(wù)端的I/O帶寬等方面壓力，從而削減服務(wù)器帶寬成本，降低客戶端卡播率。
1. 流媒體轉(zhuǎn)發(fā)

(1) YUV/RGB顏色格式
    類似于RGB，YUV也是一種顏色格式，通常我們手機(jī)攝像頭采集的每一幀圖像就是YUV格式的，它分別由Y、U、V分量組成，其中“Y”表示明亮度（Luminance或Luma），也就是灰階值；而“U”和“V”表示的則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用于指定像素的顏色。 因此，YUV是一種亮度信號(hào)Y和色度信號(hào)U、V是分離的色彩空間，它主要用于優(yōu)化彩色視頻信號(hào)的傳輸，使其向后相容老式黑白電視，且與RGB要求三個(gè)獨(dú)立的視頻信號(hào)同時(shí)傳輸相比，它最大的優(yōu)點(diǎn)在于只需占用極少的頻寬，非常適用于流媒體傳輸。
     YUV格式分為兩種類型，即Packet(包)和Plannar(平面)。Packet類型是將Y、U、V分量存儲(chǔ)在同一個(gè)數(shù)組中，每個(gè)像素點(diǎn)的Y、U、V是連續(xù)交錯(cuò)存儲(chǔ)的，常見(jiàn)的采樣格式有NV21、NV12；Plannar類型是將Y、U、V分量分別存儲(chǔ)在三個(gè)獨(dú)立的數(shù)組中，且先連續(xù)存儲(chǔ)所有像素點(diǎn)的Y分量，緊接著存儲(chǔ)所有像素點(diǎn)的U分量，最后存儲(chǔ)所有像素點(diǎn)的V分量，常見(jiàn)的采樣格式有YV12、I420。關(guān)于YUV顏色格式深度分析，參見(jiàn)我這篇博文： 視頻直播YUV顏色格式完全解析 。

(2) H.264視頻編碼技術(shù)
     H.264是MPEG-4的第十部分，是由VCEG和MPEG聯(lián)合提出的高度壓縮數(shù)字視頻編碼器標(biāo)準(zhǔn)，它的出現(xiàn)就是為了更大程度地對(duì)原始YUV圖像進(jìn)行壓縮編碼，同時(shí)能夠保證視頻傳輸性能和畫面質(zhì)量。H.264具有低碼率、高壓縮、高質(zhì)量的圖像、容錯(cuò)能力強(qiáng)、網(wǎng)絡(luò)適應(yīng)性強(qiáng)等特點(diǎn)，它最大的優(yōu)勢(shì)擁有很高的數(shù)據(jù)壓縮比率，在同等圖像質(zhì)量的條件下，H.264的壓縮比是MPEG-2的兩倍以上。
     H.264編碼框架分為兩層：VCL、NAL。VCL(Video Coding Layer，視頻編碼層)，負(fù)責(zé)高效的視頻內(nèi)容表示；NAL(Network Abstraction Layer，網(wǎng)絡(luò)抽象層)，負(fù)責(zé)以網(wǎng)絡(luò)所要求的恰當(dāng)?shù)姆绞綄?duì)數(shù)據(jù)進(jìn)行打包和傳送。在H.264協(xié)議里定義了三種幀，完整編碼的幀叫I幀(關(guān)鍵幀)，參考之前的I幀生成的只包含差異部分編碼的幀叫P幀，還有一種參考前后的幀編碼的幀叫B幀。H.264編碼采用的核心算法是幀內(nèi)壓縮和幀間壓縮。其中，幀內(nèi)壓縮是生成I幀的算法，它的原理是當(dāng)壓縮一幀圖像時(shí)，僅考慮本幀的數(shù)據(jù)而不用考慮相鄰幀之間的冗余信息，由于幀內(nèi)壓縮是編碼一個(gè)完整的圖像，所以可以獨(dú)立的解碼顯示；幀間壓縮是生成P、B幀的算法，它的原理是通過(guò)對(duì)比相鄰兩幀之間的數(shù)據(jù)進(jìn)行壓縮，進(jìn)一步提高壓縮量，減少壓縮比。關(guān)于H.264深度分析，參見(jiàn)我這篇博文： 深度解析H.264編碼原理

  (3) H.265視頻編碼技術(shù)
      H.265，又稱HEVC(High Efficiency Video Coding，高效視頻編碼)，是繼H.264之后所制定的新的視頻編碼標(biāo)準(zhǔn)，它是對(duì)H.264編碼標(biāo)準(zhǔn)的改進(jìn)，包括提高壓縮效率、提高魯棒性和錯(cuò)誤恢復(fù)能力、減少實(shí)時(shí)的時(shí)延、降低復(fù)雜度等，其目的是旨在在有限帶寬下傳輸更高質(zhì)量的網(wǎng)絡(luò)視頻，僅需原先的一半帶寬即可播放相同質(zhì)量的視頻。比如H.263在傳輸碼率為2~4Mbps時(shí)只能傳輸標(biāo)清視頻，H.264可以以低于2Mbps的傳輸碼率傳輸標(biāo)清視頻，而H.264在低于1.5Mbps的傳輸碼率情況下就能傳輸1080P全高清視頻，并且同等分辨率情況下，碼率減少51-74%時(shí)H.265編碼視頻的質(zhì)量還能與H.264編碼視頻近似，甚至效果更好。不同編碼方式復(fù)雜度和所需傳輸碼率對(duì)比如下圖：

  (4) AAC音頻編碼技術(shù)
    高級(jí)音頻編碼(AdvancedAudio Coding，AAC)一種基于MPEG-4的音頻編碼技術(shù)，它由杜比實(shí)驗(yàn)室、AT&T等公司共同研發(fā)，目的是替換MP3編碼方式。作為一種高壓縮比的音頻壓縮算法，AAC的數(shù)據(jù)壓縮比約為18:1，壓縮后的音質(zhì)可以同未壓縮的CD音質(zhì)相媲美。因此，相對(duì)于MP3、WMA等音頻編碼標(biāo)準(zhǔn)來(lái)說(shuō)，在相同質(zhì)量下碼率更低，有效地節(jié)約了傳輸帶寬，被廣泛得應(yīng)用于互聯(lián)網(wǎng)流媒體、IPTV等領(lǐng)域(低碼率，高音質(zhì))。
     音頻數(shù)據(jù)在壓縮編碼之前，要先進(jìn)行采樣與量化，以樣值的形式存在。音頻壓縮編碼的輸出碼流，以音頻幀的形式存在。每個(gè)音頻幀包含若干個(gè)音頻采樣的壓縮數(shù)據(jù)，AAC的一個(gè)音頻幀包含960或1024個(gè)樣值，這些壓縮編碼后的音頻幀稱為原始數(shù)據(jù)塊(RawData Block)，由于原始數(shù)據(jù)塊以幀的形式存在，即簡(jiǎn)稱為原始幀。原始幀是可變的，如果對(duì)原始幀進(jìn)行ADTS的封裝，得到的原始幀為ADTS幀。 ADTS封裝格式的碼流以幀為單位，一個(gè)ADTS幀由幀頭、幀凈荷組成。其中，幀頭定義了音頻采樣率、音頻聲道數(shù)、幀長(zhǎng)度等關(guān)鍵信息，它由兩部分組成，共占7個(gè)字節(jié)：固定頭信息adts_fixed_header、可變頭信息adts_variable_header。固定頭信息中的數(shù)據(jù)每一幀都相同，而可變頭信息則在幀與幀之間可變；幀凈荷主要由1~4個(gè)原始幀組成，它包含的數(shù)據(jù)用于解析與解碼。關(guān)于AAC格式解析，參見(jiàn)我這篇博文： AAC編碼格式分析與MP4文件封裝

(5) 重要參數(shù)
a) 幀率
     幀率是指在每秒內(nèi)傳輸?shù)膱D像幀數(shù)量，單位為fps，它的大小影響畫面流暢度，且畫面流暢程度成正比。通常，幀率越大畫面越流暢，幀率越小畫面越有跳動(dòng)感(卡頓)。
b) 分辨率
     就是屏幕圖像的精密度，顯示器所能顯示的像素的多少?？梢园颜麄€(gè)圖像想象成是一個(gè)大型的棋盤，而分辨率的表示方式就是所有經(jīng)線和緯線交叉點(diǎn)的數(shù)目。以分辨率為1024×768的屏幕來(lái)說(shuō)，（即每一條水平線上包含有1024個(gè)像素點(diǎn)，共有768條線，總像素1024x768個(gè)），即掃描列數(shù)為1024列，行數(shù)為768行。分辨率影響圖像大小，與圖像大小成正比：分辨率越高，圖像越大；分辨率越低，圖像越小。
c) 碼率(視頻)/比特率(音頻)
     視頻中比特率又被稱為碼率，是指碼率就是數(shù)據(jù)傳輸時(shí)單位時(shí)間傳送的數(shù)據(jù)位數(shù)，單位是Kbps即千位每秒(=1000*1bps)。它表示經(jīng)過(guò)編碼(壓縮)后的音、視頻數(shù)據(jù)每秒鐘需要用多少個(gè)比特來(lái)表示。比特率越高，傳輸數(shù)據(jù)就越大，音、視頻的質(zhì)量就越好，但編碼后的文件就越大。
d) 采樣率
     采樣率定義了每秒從連續(xù)信號(hào)中提取并組成離散信號(hào)的采樣個(gè)數(shù)，它用赫茲（Hz）來(lái)表示。針對(duì)于音頻而言，采樣率則為計(jì)算機(jī)每秒鐘采集聲音樣本的數(shù)量，數(shù)量越大聲音質(zhì)量就越好，體積隨之也會(huì)增大。常見(jiàn)的有8000HZ、22050HZ、44100HZ、16000HZ、96000Hz等。
e) 采樣精度
     每一個(gè)采樣點(diǎn)都需要用一個(gè)數(shù)值來(lái)表示大小，這個(gè)數(shù)值的數(shù)據(jù)類型大小可以是4bit、8bit、16bit、32bit等，位數(shù)越多，表示得就越精細(xì)，聲音質(zhì)量自然就越好。由于受人的器官的機(jī)能限制，16bit(位)的聲音已經(jīng)是普通人類的極限了，更高位數(shù)就只能靠?jī)x器才能分辨出來(lái)。

其他參數(shù)可參考我這篇博文：淺析Camera視頻實(shí)時(shí)采集中涉及的參數(shù)配置

2. P2P視頻直播

3. 兩者優(yōu)缺點(diǎn)對(duì)比
(1) P2P點(diǎn)對(duì)點(diǎn)
      P2P視頻直播是客戶端之間使用一定協(xié)議，交換和共享直播數(shù)據(jù)，通過(guò)減少對(duì)服務(wù)器的數(shù)據(jù)請(qǐng)求，來(lái)降低服務(wù)端的I/O帶寬等方面壓力，從而削減服務(wù)器帶寬成本，降低客戶端卡播率。在整個(gè)網(wǎng)絡(luò)網(wǎng)框架中，每個(gè)客戶端(節(jié)點(diǎn))是對(duì)等的，即同時(shí)具有Client和Server的特點(diǎn)。常見(jiàn)開(kāi)源框架：WebRTC
優(yōu)點(diǎn)：服務(wù)器壓力小，節(jié)省帶寬成本，延時(shí)低，響應(yīng)快，秒傳，適合非實(shí)時(shí)的數(shù)據(jù)傳輸；
缺點(diǎn)：最多4~8個(gè)人同時(shí)在線觀看，對(duì)節(jié)點(diǎn)帶寬要求較高，服務(wù)器視頻錄制不好處理。IPv4網(wǎng)絡(luò)環(huán)境制約，UDP打洞穿透效率問(wèn)題，打洞不通要服務(wù)器relay；
應(yīng)用場(chǎng)景：安防
(2) 流媒體轉(zhuǎn)發(fā)
     常見(jiàn)流媒體直播協(xié)議都屬于C/S型，即所有客戶端通過(guò)指定協(xié)議，從服務(wù)端獲取直播數(shù)據(jù)。當(dāng)客戶端數(shù)量達(dá)到一定規(guī)模后，服務(wù)端將承受巨大的I/O和帶寬壓力。若服務(wù)器無(wú)法及時(shí)處理客戶請(qǐng)求，客戶端卡播率急劇上升，從而影響用戶觀看體驗(yàn)。常見(jiàn)開(kāi)源框架：ffmpeg
優(yōu)點(diǎn)：穩(wěn)定可靠，支持量大，可以實(shí)現(xiàn)一個(gè)人播，百萬(wàn)人同時(shí)在線觀看，且服務(wù)器可以進(jìn)行視頻錄制存儲(chǔ)，用戶體驗(yàn)好；
缺點(diǎn)：用戶數(shù)量增加后，對(duì)服務(wù)器的資源和帶寬等壓力大幅增加，服務(wù)器成本高，1~3秒延時(shí)；
應(yīng)用場(chǎng)景：視頻會(huì)議

二、流媒體協(xié)議架構(gòu)解析

1. RTP協(xié)議
      RTP(Real-time Transport Protocol，實(shí)時(shí)傳輸協(xié)議)是一種基于UDP的網(wǎng)絡(luò)傳輸協(xié)議，它介于應(yīng)用層和傳輸層之間，負(fù)責(zé)對(duì)流媒體數(shù)據(jù)進(jìn)行封包并實(shí)現(xiàn)媒體流的實(shí)時(shí)傳輸。RTP數(shù)據(jù)協(xié)議本身并不能按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些控制服務(wù)。對(duì)于那些丟失的數(shù)據(jù)包，不存在由于超時(shí)檢測(cè)而帶來(lái)的延時(shí)，而丟失的包也可以由上層根據(jù)其重要性來(lái)選擇性重傳。比如對(duì)于I幀、P幀、B幀數(shù)據(jù)，當(dāng)丟失的是P幀或B幀時(shí)，可以不用選擇重傳，這樣畫面只會(huì)短暫的不清晰，但是卻保障了傳輸?shù)膶?shí)時(shí)性。
(1) RTP工作機(jī)制
     當(dāng)應(yīng)用程序與流媒體服務(wù)器建立一個(gè)RTP會(huì)話后，應(yīng)用程序會(huì)確定一對(duì)目的傳輸?shù)刂?，它由一個(gè)網(wǎng)絡(luò)地址和一對(duì)端口組成。其中，這一對(duì)端口將分別分配給RTP包和RTCP包，通常RTP數(shù)據(jù)包發(fā)向偶數(shù)的UDP端口，而對(duì)應(yīng)的控制信號(hào)RTCP數(shù)據(jù)發(fā)向相鄰的奇數(shù)端口。RTP包發(fā)送過(guò)程：
      首先，RTP協(xié)議從上層獲取編碼好的流媒體信息碼流，如H.264、AAC，封裝成RTP數(shù)據(jù)包；RTCP協(xié)議從上層接收控制信息，封裝成RTCP控制包；
      然后，RTP將RTP 數(shù)據(jù)包發(fā)往UDP端口對(duì)中偶數(shù)端口；RTCP將RTCP控制包發(fā)往UDP端口對(duì)中的接收端口；
(2) RTP分組首部格式

  2. RTCP協(xié)議

      RTCP(Real-Time Transport Control Potocol，實(shí)時(shí)傳輸控制協(xié)議)是RTP協(xié)議的姐妹協(xié)議，它本身并不傳輸數(shù)據(jù)，而是與RTP各占一個(gè)端口，一起協(xié)作將流媒體數(shù)據(jù)進(jìn)行打包發(fā)送，為RTP流媒體流提供信道外控制。由于RTP本身無(wú)法按序傳輸數(shù)據(jù)包提供可靠保證，也不提供流量控制和擁塞控制，這些都由RTCP來(lái)負(fù)責(zé)完成。通常RTCP會(huì)采用與RTP相同的分發(fā)機(jī)制，向會(huì)話中的 所有成員周期性地發(fā)送控制信息，應(yīng)用程序通過(guò)接收這些數(shù)據(jù)，從中獲取會(huì)話參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進(jìn) 行控制或者對(duì)網(wǎng)絡(luò)狀況進(jìn)行診斷。因此，各參與者可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開(kāi)銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)?？傊?，RTSP發(fā)起/終結(jié)流媒體、RTP傳輸流媒體數(shù)據(jù) 、RTCP對(duì)RTP進(jìn)行控制，同步。
RTCP也是用UDP來(lái)傳送的，但RTCP封裝的僅僅是一些控制信息，因而分組很短，所以可以將多個(gè)RTCP分組封裝在一個(gè)UDP包中。RTCP有如下五種分組類型。
類型縮寫表示用途200SR（Sender Report）發(fā)送端報(bào)告201RR（Receiver Report）接收端報(bào)告202SDES（Source Description Items）源點(diǎn)描述203BYE結(jié)束傳輸204APP特定應(yīng)用
3. RTSP協(xié)議
     RTSP(Real Time Stream Protocol，實(shí)時(shí)流協(xié)議)是一種基于文本的應(yīng)用層協(xié)議，主要用于C/S模型建立實(shí)時(shí)流會(huì)話。RTSP協(xié)議是一個(gè)多媒體播放控制協(xié)議，用于控制具有實(shí)時(shí)特性的數(shù)據(jù)發(fā)送，但它本身并不傳輸數(shù)據(jù)，而是對(duì)流媒體提供諸如播放、暫停、快進(jìn)等操作。RTSP協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過(guò)IP網(wǎng)絡(luò)傳送流媒體信息數(shù)據(jù)，它在TCP/IP體系中位于RTP和RTCP協(xié)議之上，主要通過(guò)TCP或RTP/RTCP完成數(shù)據(jù)傳輸，具有易解析、安全、獨(dú)立于傳輸、多服務(wù)器支持等特點(diǎn)。
(1) RTSP URL語(yǔ)法結(jié)構(gòu)
     玩過(guò)VCL的朋友應(yīng)該知道，當(dāng)在PC或移動(dòng)端點(diǎn)播實(shí)時(shí)流媒體時(shí)，我們需要在VCL或點(diǎn)播APP中輸入U(xiǎn)RL地址才能觀看實(shí)時(shí)視頻。VCL中配置RTSP URL如下：

格式：(“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name
       rtsp  ： 表示協(xié)議類型，類似于http
       host： 表示流媒體服務(wù)器IP地址或有效的域名，如192.192.191.104;
       port： 表示端口號(hào)，rtsp協(xié)議的缺省端口號(hào)為554;
       abs_path  ： 表示流媒體服務(wù)器中媒體流資源標(biāo)識(shí)，如123456；
(2) RTSP報(bào)文結(jié)構(gòu)
      與Http協(xié)議類似，RTSP也是一種基于文本的協(xié)議，它的報(bào)文類型同樣包括請(qǐng)求報(bào)文和響應(yīng)報(bào)文。RTSP報(bào)文由三部分組成，即開(kāi)始行、首部行和實(shí)體主體，請(qǐng)求報(bào)文是指從客戶向服務(wù)器發(fā)送請(qǐng)求報(bào)文，響應(yīng)報(bào)文是指從服務(wù)器到客戶的回答。 
     RTSP請(qǐng)求報(bào)文結(jié)構(gòu)如下，RTSP請(qǐng)求報(bào)文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。

響應(yīng)報(bào)文的開(kāi)始行是狀態(tài)行，RTSP響應(yīng)報(bào)文的結(jié)構(gòu)如下：

(3)  RTSP會(huì)話基本過(guò)程
    首先，客戶端向服務(wù)器發(fā)送一個(gè)RTSP描述命令(DESCRIBE)，流媒體服務(wù)器確認(rèn)收到后將向客戶端返回一個(gè)SDP描述來(lái)進(jìn)行反饋，反饋的信息包括流量數(shù)、媒體類型等；
    其次，客戶端接收到SDP后對(duì)其進(jìn)行分析，并未會(huì)話中的每一個(gè)流發(fā)送一個(gè)RTSP建立命令，RTSP建立命令告訴服務(wù)器端用于接收流媒體數(shù)據(jù)的端口，至此RTSP會(huì)話建立完成；
    第三，客戶端向流媒體服務(wù)器發(fā)送一個(gè)播放命令(PLAY)，服務(wù)器就開(kāi)始在UDP上傳送媒體流(RTP包)到客戶端。在播放過(guò)程中，客戶端可以向服務(wù)器發(fā)送命令來(lái)控制快進(jìn)、快退、暫停等操作；
    第四，客戶端向服務(wù)器發(fā)送終止命令(TERADOWN)結(jié)束流媒體會(huì)話。
Wireshark抓包情況如下：

4. RTMP協(xié)議
     RTMP(Real Time Messaging Protocol，實(shí)時(shí)消息傳輸協(xié)議)屬于五層TCP/IP體系中的應(yīng)用層，它是基于TCP傳輸?shù)牧髅襟w協(xié)議，默認(rèn)端口為1935，是一個(gè)協(xié)議族，包括RTMP基本協(xié)議及RTMPT、RTMPS、REMPE等多種變種。RTMP協(xié)議是Adobe System公司為Flash播放器和FMS服務(wù)器之間音視頻和數(shù)據(jù)傳輸開(kāi)發(fā)的私有協(xié)議，用來(lái)解決多媒體數(shù)據(jù)傳輸流的多路復(fù)用（Multiplexing）和分包（packetizing）的問(wèn)題，基于此協(xié)議，abobe提供完善的音視頻解決方案，比如點(diǎn)播、直播、互動(dòng)。
(1) RTMP協(xié)議傳輸原理
     RTMP傳輸媒體數(shù)據(jù)的過(guò)程中，會(huì)先后經(jīng)歷"握手-建立連接-建立流-播放"步驟。發(fā)送端首先把媒體數(shù)據(jù)封裝成消息，然后把消息分割成消息塊，最后將分割后的消息塊通過(guò)TCP協(xié)議發(fā)送出去。接收端在通過(guò)TCP協(xié)議收到數(shù)據(jù)后，首先把消息塊重新組合成消息，然后通過(guò)對(duì)消息進(jìn)行解封裝處理就可以恢復(fù)出媒體數(shù)據(jù)。
消息(Message)
      消息是RTMP協(xié)議中基本的數(shù)據(jù)單元。不同種類的消息包含不同的Message Type ID，代表不同的功能。RTMP協(xié)議中一共規(guī)定了十多種消息類型，分別發(fā)揮著不同的作用。例如，Message Type ID在1-7的消息用于協(xié)議控制，這些消息一般是RTMP協(xié)議自身管理要使用的消息，用戶一般情況下無(wú)需操作其中的數(shù)據(jù)。Message Type ID為8，9的消息分別用于傳輸音頻和視頻數(shù)據(jù)。Message Type ID為15-20的消息用于發(fā)送AMF編碼的命令，負(fù)責(zé)用戶與服務(wù)器之間的交互，比如播放，暫停等等。消息首部（Message Header）有四部分組成：標(biāo)志消息類型的Message Type ID，標(biāo)志消息長(zhǎng)度的Payload Length，標(biāo)識(shí)時(shí)間戳的Timestamp，標(biāo)識(shí)消息所屬媒體流的Stream ID。消息的報(bào)文結(jié)構(gòu)如下圖所示：

消息塊(Message Chunk)
     在網(wǎng)絡(luò)上傳輸數(shù)據(jù)時(shí)，消息需要被拆分成較小的數(shù)據(jù)塊，才適合在相應(yīng)的網(wǎng)絡(luò)環(huán)境上傳輸。RTMP協(xié)議中規(guī)定，消息在網(wǎng)絡(luò)上傳輸時(shí)被拆分成消息塊（Chunk），默認(rèn)大小為128字節(jié)。消息塊首部（Chunk Header）有三部分組成：用于標(biāo)識(shí)本塊的Chunk Basic Header，用于標(biāo)識(shí)本塊負(fù)載所屬消息的Chunk Message Header，以及當(dāng)時(shí)間戳溢出時(shí)才出現(xiàn)的Extended Timestamp。消息塊的報(bào)文結(jié)構(gòu)如下圖所示：

(2) RTMP協(xié)議"握手"流程分析
      一個(gè)RTMP連接以"握手"開(kāi)始，雙方會(huì)分辨發(fā)送帶下固定的三個(gè)消息塊(數(shù)據(jù)塊)，比如客戶端會(huì)向服務(wù)器發(fā)送C0、C1、C2消息塊，服務(wù)器收到客戶端發(fā)來(lái)的消息塊后，會(huì)向客戶端發(fā)送S1、S2、S3消息塊，具體流程如下：
    首先，客戶端向服務(wù)器發(fā)送C0、C1消息塊，服務(wù)器收到C0或C1后，會(huì)向客戶端發(fā)送S0和S1；
    其次，當(dāng)客戶端收齊S0、S1消息塊后，再向服務(wù)器發(fā)送C2消息塊。當(dāng)服務(wù)器收齊C0和C1后，再向客戶端發(fā)送S2消息塊；
    最后，當(dāng)客戶端和服務(wù)器分別收到S2和C2后，握手完成。

5. RTMP協(xié)議、RTSP協(xié)議、HTTP協(xié)議區(qū)別
     這三個(gè)協(xié)議都屬于TCP/IP五層體系中應(yīng)用層協(xié)議，通常RTMP、RTSP協(xié)議用于直播，HTTP用于點(diǎn)播。它們的主要區(qū)別如下：
(1) RTMP協(xié)議
    a) 是流媒體協(xié)議；
    b) RTMP協(xié)議是Adobe的私有協(xié)議，未完全公開(kāi)；
    c) RTMP協(xié)議一般傳輸flv、f4v格式的流式文件；
    d) RTMP使用TCP傳輸，只需要1個(gè)通道上傳命令和數(shù)據(jù)；
(2) RTSP協(xié)議
    a) 是流媒體協(xié)議，RTSP為每個(gè)會(huì)話保持狀態(tài)；
    b) RTSP協(xié)議是共有協(xié)議，有專門機(jī)構(gòu)做維護(hù)；
    c) RTSP協(xié)議一般傳輸ts、mp4格式的數(shù)據(jù)，但mp4不是流式文件，必須有索引才能任意seek；
    d) RTSP使用UDP傳輸，需要2-3個(gè)通道來(lái)傳輸命令和數(shù)據(jù)，即數(shù)據(jù)和命令通道分離；
(3) HTTP協(xié)議
    a) 不是流媒體協(xié)議，HTTP是無(wú)狀態(tài)協(xié)議；
    b) HTTP協(xié)議是共有協(xié)議，有專門機(jī)構(gòu)做維護(hù)；
    c) HTTP協(xié)議沒(méi)有特定的傳輸流；
    d) HTTP一般在TCP一個(gè)通道上傳輸命令和數(shù)據(jù)；

參考資料
(1) 詳解P2P技術(shù)與前景展望
(2) H.265百度百科
(3) H.265深度解析
(4) 視頻直播系統(tǒng)的P2P方式
(5) RTMP、RTSP、HTTP協(xié)議區(qū)別
(6) 流媒體傳輸控制協(xié)議(RTSP RTP SDP)詳解之RTP
(7) 流媒體傳輸控制協(xié)議(RTSP RTP SDP)詳解之RTSP
(8) 帶你吃透RTMP
(9) RTMP協(xié)議學(xué)習(xí)總結(jié)
(10) rtmp 協(xié)議分析及交互過(guò)程