一、引言
在線(xian)教(jiao)育平臺利用一(yi)(yi)切線(xian)上工具進(jin)行教(jiao)育活動，采(cai)用網絡(luo)先進(jin)技術改(gai)變師生(sheng)的(de)(de)交流方式，進(jin)一(yi)(yi)步提高(gao)學(xue)生(sheng)掌握(wo)知識的(de)(de)效率。隨著在線(xian)教(jiao)育直播平臺的(de)(de)如火(huo)如荼，我們(men)有(you)必要對直播平臺相關(guan)的(de)(de)基礎知識點有(you)一(yi)(yi)個系統性的(de)(de)了解(jie)。如圖一(yi)(yi)所示(shi)。
二、流媒體協議
可用于視頻直播(bo)的流(liu)媒體(ti)協議包括(kuo)：NDI、SRT、RIST、CMAF、HLS、DASH、HTTP-FLV、RTSP、RTMP、WebRTC。下(xia)面將一一介(jie)紹。
2.1 NDI
NDI(Network Device Interface,網(wang)(wang)(wang)(wang)絡設(she)備接(jie)(jie)口協議)是NewTek公司于(yu)2015年推出(chu)的(de)(de)，是一種基于(yu)局域(yu)網(wang)(wang)(wang)(wang)絡的(de)(de)信號(hao)傳(chuan)輸(shu)協議。使(shi)用NDI傳(chuan)輸(shu)技術，在(zai)局域(yu)網(wang)(wang)(wang)(wang)內的(de)(de)一個(ge)設(she)備可(ke)以通過(guo)(guo)一條網(wang)(wang)(wang)(wang)線輸(shu)出(chu)或(huo)者接(jie)(jie)收(shou)多(duo)(duo)個(ge)NDI信號(hao)，可(ke)完(wan)全取代傳(chuan)統SDI/HDMI視頻(pin)線傳(chuan)輸(shu)，它讓視頻(pin)在(zai)IP空(kong)間進行(xing)簡捷高(gao)效的(de)(de)傳(chuan)輸(shu)成(cheng)為現(xian)實。音視頻(pin)信號(hao)在(zai)進行(xing)NDI編碼(ma)后，能(neng)實時(shi)通過(guo)(guo)IP網(wang)(wang)(wang)(wang)絡對多(duo)(duo)重廣播級(ji)質量信號(hao)進行(xing)傳(chuan)輸(shu)和接(jie)(jie)收(shou)，同時(shi)具有低延遲、數據流相互(hu)識別(bie)與通信等特(te)性。
2.2 SRT
SRT（Secure Reliable Transport，安(an)全可(ke)靠的(de)(de)傳(chuan)(chuan)(chuan)輸(shu)）是新一代(dai)低(di)延遲視(shi)頻傳(chuan)(chuan)(chuan)輸(shu)協(xie)議(yi)，是一套開(kai)源的(de)(de)應(ying)用靈(ling)活的(de)(de)規(gui)范。它的(de)(de)性能(neng)與專用的(de)(de)協(xie)議(yi)一樣優(you)秀，同時(shi)能(neng)夠在不(bu)同制造商生(sheng)產的(de)(de)產品(pin)之間(jian)工(gong)作(zuo)。SRT是一種能(neng)夠在復雜網(wang)絡(luo)環境(jing)下實時(shi)、準確(que)地傳(chuan)(chuan)(chuan)輸(shu)數據(ju)流的(de)(de)網(wang)絡(luo)傳(chuan)(chuan)(chuan)輸(shu)技(ji)術(shu)，SRT協(xie)議(yi)建立在開(kai)源的(de)(de)UDT（UDP-based Data Transfer Protocol，基于(yu)UDP的(de)(de)數據(ju)傳(chuan)(chuan)(chuan)輸(shu)協(xie)議(yi)）之上，具備UDP速度(du)快、開(kai)銷低(di)的(de)(de)傳(chuan)(chuan)(chuan)輸(shu)特性，支持點對(dui)點傳(chuan)(chuan)(chuan)輸(shu)，無需中(zhong)間(jian)進行服務器中(zhong)轉(zhuan)，互聯網(wang)點對(dui)點傳(chuan)(chuan)(chuan)輸(shu)可(ke)小(xiao)于(yu)1s。
SRT可廣泛(fan)應用于(yu)節目遠(yuan)程制作(zuo)、活動直播、互聯網遠(yuan)程教學(xue)、集團公司對(dui)異地施工現場(chang)視頻監管等領域，以及(ji)其他(ta)需要在互聯網遠(yuan)程視頻傳(chuan)輸(shu)的場(chang)合。需要注意的是，SRT傳(chuan)輸(shu)應用需要發送端(duan)(duan)或接收端(duan)(duan)任意一端(duan)(duan)具備固定公網IP地址。
2.3 RIST
RIST（Reliable Internet Stream Transport，可靠(kao)的(de)互聯網流傳(chuan)輸協(xie)議），是由(you)Video Services Forum (VSF) 于(yu)2017年初成立(li)的(de)小組，為協(xie)議創建公開的(de)通用規范。
RIST的(de)(de)首選流(liu)傳輸協(xie)議(yi)(yi)是RTP配合RTCP。RIST需要兩個端口(kou)：第(di)一個端口(kou)用于(yu)傳輸媒體流(liu)；第(di)二個端口(kou)使(shi)用RTCP創建(jian)控制界(jie)面(mian)。RTCP協(xie)議(yi)(yi)是雙向(xiang)的(de)(de)。相較于(yu)SRT（基于(yu)UDT非(fei)實時流(liu)媒體的(de)(de)技術棧構建(jian)），RIST一開始(shi)便使(shi)用較為成熟的(de)(de)RTP+RTCP 技術，而且(qie)它只定(ding)義了標準化的(de)(de)語法，允(yun)許廠家在此基礎上(shang)進行擴展，又不會互相影響。
2.4 CMAF
CMAF（Common Media Application Format，通用(yong)媒體應用(yong)格式），由(you)微軟、蘋果聯合MLBAM、思科(ke)、Akamai和(he)Comcast在2016年(nian)2月向動態圖像(xiang)專家組（MPEG）提出，并已被批準(zhun)成為國際標(biao)準(zhun)。CMAF是一種可擴展的編碼標(biao)準(zhun)，通過指(zhi)定一致的媒體包裝和(he)加密來實現(xian)內容和(he)設備之間的互操作性。
CMAF目(mu)標是將(jiang)HLS和(he)DASH格式(shi)(shi)結合(he)在一(yi)起(qi)，以簡化在線視頻傳(chuan)輸。與普遍看法相反，CMAF本身不(bu)會(hui)減少(shao)延遲(chi)，而是提(ti)供了一(yi)種(zhong)低延遲(chi)模式(shi)(shi)，可以將(jiang)媒體(ti)段劃分為(wei)更小的塊。與DASH和(he)HLS不(bu)同，CMAF不(bu)是一(yi)種(zhong)演示格式(shi)(shi)（presentation format），它是一(yi)種(zhong)容器(qi)格式(shi)(shi)，可以包(bao)含一(yi)組(zu)音頻/視頻文件。
2.5 HLS
HLS（HTTP Live Streaming，基于HTTP的網絡(luo)傳輸(shu)協(xie)議(yi)），由蘋果公司提(ti)出(chu)。它(ta)和DASH 協(xie)議(yi)的原理非常(chang)類(lei)似(si)，通過(guo)將(jiang)整(zheng)個流切割成(cheng)一(yi)個個小的可以(yi)通過(guo) HTTP 下載的媒體(ti)文件(jian)(jian), 然后提(ti)供一(yi)個配套的媒體(ti)列(lie)表文件(jian)(jian), 提(ti)供給(gei)客戶(hu)端。讓客戶(hu)端順序地(di)拉取這些媒體(ti)文件(jian)(jian)播放(fang)(fang), 來實現看上去是在(zai)播放(fang)(fang)一(yi)個文件(jian)(jian)的效果。HLS目前(qian)廣泛地(di)應用(yong)于點播和直播領域。
2.6 DASH
DASH(Dynamic Adaptive Streaming over HTTP，自(zi)適應流媒體協議(yi))是在2011年底(di)由MPEG和ISO共同制定(ding)的標準，通過(guo)HTTP共同影音(yin)檔案通訊協定(ding)，可使高品(pin)質影音(yin)內容(rong)通過(guo)網(wang)路傳送到網(wang)絡電視、機頂(ding)盒及移動(dong)終端設備(bei)。
DASH采用服務(wu)端(duan)/客(ke)戶端(duan)的(de)流媒(mei)體解決方案。服務(wu)端(duan)將視頻內容分割為一(yi)個(ge)個(ge)分片，每個(ge)分片可(ke)以(yi)存在不(bu)同的(de)編碼形式（不(bu)同的(de)codec、profile、分辨率、碼率等）；播放器(qi)端(duan)可(ke)以(yi)自(zi)由選擇需要播放的(de)媒(mei)體分片；不(bu)同畫質內容無(wu)縫切換，提供(gong)更好的(de)播放體驗。
2.7 HTTP-FLV
Http-FLV（RTMP over HTTP，基于HTTP之上的RTMP），將流媒體數據(ju)封裝成 FLV 格(ge)式，然后通過HTTP協(xie)議傳(chuan)輸給客(ke)戶端。
HTTP-FLV依(yi)靠MIME的(de)特性(xing)，根據協(xie)(xie)議(yi)(yi)中的(de)Content-Type來選擇相應的(de)程序去處理相應的(de)內容，使得流媒體(ti)可以通過HTTP傳輸(shu)。優點：相較于 RTMP 協(xie)(xie)議(yi)(yi)，HTTP-FLV能夠(gou)很好(hao)的(de)穿(chuan)透防火墻，它(ta)是基于 HTTP/80 傳輸(shu)，有(you)效避免被防火墻攔截。除此之(zhi)外(wai)，也可以通過HTTP 302跳轉靈活調(diao)度/負載均衡(heng)，支持使用HTTPS加密(mi)傳輸(shu)。缺點：流媒體(ti)資源(yuan)緩存(cun)在本地(di)客戶端，在保密(mi)性(xing)方(fang)面不夠(gou)好(hao)。另外(wai)網(wang)絡流量較大，也不適合做(zuo)拉流協(xie)(xie)議(yi)(yi)。
備注：FLV (Flash Video) 是 Adobe 公司推出的另一種視(shi)頻格(ge)式(shi)，是一種在網絡上傳輸的流媒體(ti)數據存儲容器格(ge)式(shi)。其格(ge)式(shi)相(xiang)對簡(jian)單(dan)輕(qing)量，不需要很大(da)的媒體(ti)頭部信息。
2.8 RTSP
RTSP(Real-Time Stream Protocol，實時流(liu)(liu)傳輸協議)是(shi)由Real Network和Netscape共同(tong)提出的(de)如(ru)何有效地在IP網絡上(shang)傳輸流(liu)(liu)媒體(ti)數據的(de)應用層協議。
RTSP對(dui)流媒(mei)體(ti)(ti)提(ti)(ti)(ti)供(gong)了諸如(ru)暫停，快進等控制，提(ti)(ti)(ti)供(gong)了一個可(ke)供(gong)擴展的框架(jia)，使得流媒(mei)體(ti)(ti)的受控和點播(bo)變得可(ke)能，它主要用來(lai)控制具有實時(shi)特性的數據發(fa)送，但其本身并不用于傳(chuan)送流媒(mei)體(ti)(ti)數據，而(er)必須依賴下層傳(chuan)輸協議(yi)(例(li)如(ru)：RTP/RTCP)所(suo)提(ti)(ti)(ti)供(gong)的服務來(lai)完成流媒(mei)體(ti)(ti)數據的傳(chuan)送。RTSP負責(ze)定義具體(ti)(ti)的控制信(xin)息(xi)、操(cao)(cao)作方法、狀(zhuang)態碼，以及描(miao)述(shu)與RTP之間(jian)的交互(hu)操(cao)(cao)作。如(ru)圖二所(suo)示(shi)。
;
2.9 RTMP
RTMP（Real Time Messaging Protocol，實時消息傳(chuan)輸(shu)協議(yi)）是Adobe Systems公司為Flash播放(fang)器和服務器之間音頻、視頻和數據傳(chuan)輸(shu)開發的(de)(de)協議(yi)。這是一個標準的(de)(de)，未加密的(de)(de)實時消息傳(chuan)遞協議(yi)，默認端口是1935。
RTMP基(ji)于(yu)TCP協(xie)議，而TCP協(xie)議實(shi)時性不(bu)如UDP，也非(fei)常占用帶(dai)寬。目前(qian)基(ji)于(yu)UDP的(de)RTMFP協(xie)議能很(hen)好的(de)解決(jue)這個問題。備注(zhu)：這個協(xie)議的(de)播(bo)放依賴于(yu)Flash Player。如果沒有這個播(bo)放媒介(jie)，這個協(xie)議就沒有用武之地(di)了。
使用(yong)場景如圖三所示。
2.10 WebRTC
WebRTC（Web Real-Time Communication，網頁實(shi)時通信）是一個由Google發起的實(shi)時通訊解決方案，其中包(bao)含視頻(pin)音(yin)(yin)頻(pin)采集，編解碼，數據(ju)傳輸(shu)，音(yin)(yin)視頻(pin)展示等功能。它于2011年6月(yue)1日開源(yuan)并(bing)在Google、Mozilla、Opera支持下被(bei)納入萬維網聯盟的W3C推薦標準。
WebRTC使用安全實時傳輸協議（Secure Real-time Transport Protocol，SRTP）對RTP數據進(jin)行加(jia)密，消息認證和完(wan)整性檢查以及重播攻擊保護。它(ta)是一個安全框架(jia)，通(tong)過加(jia)密RTP負載和支持原始認證來提供機密性。WebRTC不光(guang)支持Web之間的音視(shi)頻通(tong)訊，還(huan)支持Android以及IOS端，此外(wai)由于該項(xiang)目是開源(yuan)的，我們(men)也可以通(tong)過編譯C++代(dai)碼，從而達到全平臺的互通(tong)。
內部協(xie)議棧如圖四所示。
2.10.1 信令(ling)，STUN，TURN和ICE
1） 信令
信令服務器(qi)負責端(duan)到端(duan)的連接，如SDP，Candidate等。元數據(ju)是通(tong)過信令服務器(qi)中(zhong)轉來發給另(ling)一個(ge)客戶(hu)端(duan)，但是對(dui)于(yu)流媒體(ti)數據(ju)，一旦會(hui)話(hua)建立，首(shou)先嘗(chang)試(shi)使用點對(dui)點連接。如圖(tu)五所示。
信令（Signaling）是協調通訊(xun)的過(guo)程(cheng)，信令處理過(guo)程(cheng)需要客(ke)戶端能夠來回傳(chuan)遞消(xiao)息，這個(ge)過(guo)程(cheng)在WebRTC里面是沒(mei)有實現的，需要自(zi)己創(chuang)建。一旦信令服務(wu)(wu)建立好了，兩個(ge)客(ke)戶端之間建立了連接，理論上他們就可(ke)以(yi)進行點對點通訊(xun)了，這樣可(ke)以(yi)減輕信令服務(wu)(wu)的壓(ya)力和消(xiao)息傳(chuan)遞的延遲。
為了建(jian)立(li)一個(ge)WebRTC的通訊(xun)過程，客戶端需(xu)要交換如下(xia)信(xin)息：
會話控(kong)制信息：用來(lai)開始和結(jie)束(shu)通話，即開始視頻、結(jie)束(shu)視頻這些操作指令。
處理錯誤的消息。
元(yuan)數據：例如(ru)各自(zi)的音視(shi)頻(pin)解碼方式、帶(dai)寬。
網絡數據(ju)：對(dui)方的公網IP及端口(kou)，內(nei)網IP及端口(kou)。
2） STUN，TRUN和ICE
每個(ge)(ge)(ge)(ge)客戶(hu)(hu)端都有一(yi)個(ge)(ge)(ge)(ge)唯一(yi)的(de)公網IP地(di)址，它(ta)能用來和(he)其他客戶(hu)(hu)端進行通(tong)訊(xun)和(he)數據(ju)交換。然(ran)而(er)現實生活中(zhong)客戶(hu)(hu)端通(tong)常位于一(yi)個(ge)(ge)(ge)(ge)或(huo)多個(ge)(ge)(ge)(ge)NAT（Network Address Translator）之后；或(huo)者一(yi)些殺毒軟件(jian)還阻止(zhi)了某些端口和(he)協議，又(you)或(huo)者在(zai)公司(si)還有防火墻或(huo)代理(li)等；防火墻和(he)NAT或(huo)許是同一(yi)個(ge)(ge)(ge)(ge)設備，例如(ru)我們家里用的(de)路由器。基于以上原因，由于獲取不到公網的(de)IP，導(dao)致兩端用戶(hu)(hu)不能直接找到對方。如(ru)何有效地(di)穿透各種NAT（Network Address Translator）/FW(Fire Wall)成為(wei)一(yi)個(ge)(ge)(ge)(ge)問題。目前NAT類型(xing)(xing)主(zhu)要分為(wei)完全錐(zhui)型(xing)(xing)，地(di)址限制錐(zhui)型(xing)(xing)，端口限制錐(zhui)型(xing)(xing)，對稱(cheng)型(xing)(xing)，每種類型(xing)(xing)數據(ju)交互模式也不同，需(xu)要記住(zhu)對稱(cheng)型(xing)(xing)NAT會存在(zai)打洞失敗的(de)問題。這個(ge)(ge)(ge)(ge)時候就會用到STRN、TURN和(he)ICE技術。
STUN相當(dang)于(yu)打(da)洞服(fu)務器，是用(yong)來獲取(qu)外(wai)網地址的。
TURN相當于轉發(fa)服(fu)務器，是(shi)在打(da)洞失敗(bai)時進行轉發(fa)的。
ICE（Interactive Connectivity Establishment，交互(hu)式(shi)連接建(jian)立(li)），是一(yi)組基于Offer/Answer模(mo)式(shi)解決NAT穿越的協(xie)(xie)議(yi)集合(he)(he)。ICE主(zhu)要包含STUN+TURN協(xie)(xie)議(yi)，TURN協(xie)(xie)議(yi)的主(zhu)要作用就是用于NAT打洞失敗后，利用Relay進行(xing)轉(zhuan)發。ICE通過綜(zong)合(he)(he)利用現有協(xie)(xie)議(yi)，以一(yi)種更有效的方式(shi)來組織(zhi)會話建(jian)立(li)過程，使(shi)之(zhi)在不增加任何延(yan)遲同時比STUN等單一(yi)協(xie)(xie)議(yi)更具有健壯性(xing)(xing)和靈(ling)活性(xing)(xing)。
如圖六所示。
2.10.2 DTLS、SRTP和SCTP
2.10.2.1 基礎概(gai)念(nian)
SRTP（Secure Realtime Transport Protocol，安(an)全(quan)實(shi)時傳(chuan)輸協(xie)議），主要用來傳(chuan)輸對(dui)實(shi)時性要求比較(jiao)高的數據(ju)。例如音視頻數據(ju)。
SRTCP（Secure RTP Trasport Control Protocol，安全RTP傳(chuan)輸控制協議），跟RTP在同一份RFC中定義，主要用來(lai)監控數據(ju)傳(chuan)輸的質(zhi)量，并給予數據(ju)發送方(fang)反饋。
SCTP（Stream Control Transmission Protocol，流(liu)控(kong)制傳輸協議），之前介紹(shao)過，(S)RTP/(S)RTCP主(zhu)要用(yong)來(lai)傳輸音視頻數據(ju)，是為了流(liu)媒體設(she)計的。而對于自(zi)定(ding)義應(ying)用(yong)數據(ju)的傳輸，WebRTC使用(yong)了SCTP協議。
DTLS（Datagram Transport Level Security，數據(ju)(ju)(ju)報安全(quan)協議），提供了(le)UDP 傳輸場景下的安全(quan)解決方(fang)(fang)案，能防止消息被竊聽(ting)、篡(cuan)改、身份冒充等問題。DTLS的主要用途就是(shi)讓通(tong)信雙方(fang)(fang)協商密(mi)(mi)(mi)鑰，用來對數據(ju)(ju)(ju)進(jin)行加解密(mi)(mi)(mi)。在(zai)(zai)WeRTC中(zhong)使(shi)用DTLS的地方(fang)(fang)包括兩部分：一是(shi)DataChannel 數據(ju)(ju)(ju)通(tong)道，一個是(shi)RTCPeerConnection音視頻媒體(ti)通(tong)道。在(zai)(zai)數據(ju)(ju)(ju)通(tong)道中(zhong)，WebRTC完全(quan)使(shi)用DTLS來進(jin)行協商和(he)加解密(mi)(mi)(mi)；在(zai)(zai)音視頻通(tong)道中(zhong)WebRTC使(shi)用SRTP來進(jin)行數據(ju)(ju)(ju)的加解密(mi)(mi)(mi)，DTLS的作(zuo)用僅僅是(shi)用來做密(mi)(mi)(mi)鑰交換，RTP/RTCP的數據(ju)(ju)(ju)加解密(mi)(mi)(mi)就交給了(le)SRTP。
SDP（Session Description Protocol，會話(hua)(hua)描(miao)(miao)述協(xie)(xie)議），是一個用(yong)(yong)來描(miao)(miao)述多(duo)媒(mei)(mei)(mei)(mei)體(ti)會話(hua)(hua)的(de)應(ying)用(yong)(yong)層控制協(xie)(xie)議，為會話(hua)(hua)通(tong)知、會話(hua)(hua)邀請和其它形式的(de)多(duo)媒(mei)(mei)(mei)(mei)體(ti)會話(hua)(hua)初(chu)始化等(deng)目的(de)提(ti)供了多(duo)媒(mei)(mei)(mei)(mei)體(ti)會話(hua)(hua)描(miao)(miao)述；它是一個基于(yu)文本(ben)的(de)協(xie)(xie)議，這(zhe)樣(yang)就能保證協(xie)(xie)議的(de)可擴(kuo)展性比較強，這(zhe)樣(yang)就使(shi)(shi)其具(ju)有廣泛的(de)應(ying)用(yong)(yong)范圍(wei)；SDP完全是一種(zhong)會話(hua)(hua)描(miao)(miao)述格式，它不(bu)(bu)屬于(yu)傳(chuan)輸(shu)(shu)協(xie)(xie)議，它只(zhi)使(shi)(shi)用(yong)(yong)不(bu)(bu)同適當的(de)傳(chuan)輸(shu)(shu)協(xie)(xie)議，包(bao)括(kuo)會話(hua)(hua)通(tong)知協(xie)(xie)議（SAP）、會話(hua)(hua)初(chu)始協(xie)(xie)議（SIP）、實時(shi)流協(xie)(xie)議（RTSP）、MIME 擴(kuo)展協(xie)(xie)議的(de)電子(zi)郵件以及超(chao)文本(ben)傳(chuan)輸(shu)(shu)協(xie)(xie)議（HTTP）。SDP不(bu)(bu)支持會話(hua)(hua)內容(rong)或(huo)媒(mei)(mei)(mei)(mei)體(ti)編碼的(de)協(xie)(xie)商，所(suo)以在流媒(mei)(mei)(mei)(mei)體(ti)中只(zhi)用(yong)(yong)來描(miao)(miao)述媒(mei)(mei)(mei)(mei)體(ti)信(xin)息。媒(mei)(mei)(mei)(mei)體(ti)協(xie)(xie)商這(zhe)一塊要用(yong)(yong)RTSP來實現(xian)。SDP文本(ben)信(xin)息包(bao)括(kuo)：會話(hua)(hua)名稱和意(yi)圖；會話(hua)(hua)持續時(shi)間(jian)；構成會話(hua)(hua)的(de)媒(mei)(mei)(mei)(mei)體(ti)；有關接收(shou)媒(mei)(mei)(mei)(mei)體(ti)的(de)信(xin)息（地(di)址等(deng)）。
WebRTC傳輸(shu)音視頻數(shu)據(ju)相關(guan)協議：UDP、DTLS、RTP/SRTCP。
WebRTC傳輸(shu)自定義(yi)應用數(shu)據(ju)相關協議：UDP、DTLS、SCTP。
對WebRTC應用來說，不管是音視頻數據(ju)，還是自(zi)定義(yi)應用數據(ju)，都(dou)要求基于加密(mi)的(de)信道(dao)進行傳(chuan)輸(shu)。DTLS有點(dian)類似TLS，在UDP的(de)基礎上，實現信道(dao)的(de)加密(mi)。
2.10.2.2 加(jia)密信道建立過程（DTLS）
通(tong)信雙方(fang)：通(tong)過DTLS握(wo)手，協商生成(cheng)一對密鑰；
發送方：對數據進行(xing)加密；
發(fa)送(song)方(fang)：通過UDP傳輸加密數據；
接收方：對加密(mi)數據(ju)進行(xing)解密(mi)；
2.10.2.3 音視頻數據傳輸(shu)過(guo)過(guo)程（RTP/SRTP、RTCP/SRTCP）
通信雙(shuang)方：通過(guo)DTLS握手，協商(shang)生成一(yi)對密(mi)鑰；
數(shu)據(ju)發送(song)方：將音視頻數(shu)據(ju)封(feng)裝成(cheng)RTP包，將控制數(shu)據(ju)封(feng)裝成(cheng)RTCP包；
數(shu)據發(fa)送(song)方：利用加密(mi)密(mi)鑰，對(dui)RTP包、RTCP包進行(xing)加密(mi)，生成(cheng)SRTP包、SRTCP包；
數(shu)據發送方：通過UDP傳輸SRTP包、SRTCP包；
2.10.2.4 自定(ding)義應用數(shu)據傳輸過(guo)程（SCTP）
通信雙方(fang)：通過DTLS握手，協(xie)商生成一對(dui)密鑰；
數據(ju)發(fa)送方：將自定義應用數據(ju)，通(tong)過密(mi)鑰進行加(jia)密(mi)，生成(cheng)SCTP包；
數據發送方(fang)：通過(guo)UDP傳(chuan)輸SCTP包(bao)；
2.10.3 RTCPeerConnection和DataChannel
RTCPeerConnection音視頻媒體通(tong)道(dao)，是一個(ge)(ge)用(yong)于使(shi)WebRTC調(diao)用(yong)視頻和音頻流并交換數據的(de)API接(jie)口(kou)集，代表一個(ge)(ge)由本地(di)計算(suan)機(ji)到遠端的(de)WebRTC連接(jie)。該接(jie)口(kou)提供了創(chuang)建、保持、監(jian)控、關閉連接(jie)的(de)方法(fa)實現(xian)。一個(ge)(ge)RTCPeerConnection對象允許用(yong)戶在兩個(ge)(ge)瀏覽(lan)器之間(jian)直接(jie)通(tong)訊。
DataChannel數(shu)據(ju)(ju)通(tong)道，表示一個(ge)(ge)在兩(liang)個(ge)(ge)節點之(zhi)間的(de)(de)雙向的(de)(de)數(shu)據(ju)(ju)通(tong)道。RTCDataChannel數(shu)據(ju)(ju)通(tong)道是瀏(liu)覽器之(zhi)間建立的(de)(de)非(fei)媒體的(de)(de)交互(hu)連接，即不傳遞媒體消(xiao)息，繞過服務器直接傳遞數(shu)據(ju)(ju)。相比WebSocket、Http消(xiao)息，數(shu)據(ju)(ju)通(tong)道支(zhi)持的(de)(de)流(liu)量大、延遲低。
2.11 幾款主流(liu)媒體協(xie)議(yi)對比(bi)
如表一所示。
三、編解碼格式
可用(yong)于(yu)視頻直播的編解碼包括：音頻編解碼和視頻編解碼。
3.1 音頻(pin)編解碼(ma)格式
3.1.1 Opus
Opus 是一(yi)個完全開源，通用性(xing)高的(de)(de)音頻解(jie)碼(ma)(ma)器。Opus 在(zai)網絡上有著無與倫比的(de)(de)交互式語音和(he)音樂傳播(bo)功(gong)能，但也(ye)可以用來(lai)存儲，在(zai)流媒體上使用。Opus 遵從 Internet Engineering Task Force (IETF) RFC 6716 標準，整合了 Skype's SILK 解(jie)碼(ma)(ma)和(he) Xiph.Org's CELT 解(jie)碼(ma)(ma)的(de)(de)技術。
新的(de)WebRTC中(zhong)默認是(shi)采(cai)用Opus編(bian)碼(ma)，Opus編(bian)碼(ma)是(shi)由silk編(bian)碼(ma)和(he)celt編(bian)碼(ma)合并在(zai)一(yi)起，silk編(bian)碼(ma)是(shi)由skype公司開源的(de)一(yi)種語音編(bian)碼(ma)，特別適合人聲，適合于Voip語音通(tong)信。celt和(he)mp3,aac類似，適合于傳輸(shu)音樂。
3.1.2 其(qi)它格式(shi)
如表二所示。
3.2 視頻(pin)編(bian)解碼(ma)格式
3.2.1 AV1
AV1是一個開(kai)放(fang)、免(mian)專利(li)的影片編碼(ma)格(ge)式(shi)，專為(wei)通(tong)過網絡進行流傳(chuan)輸而設計(ji)。它由(you)開(kai)放(fang)媒體聯(lian)盟(meng)（AOMedia）開(kai)發，該聯(lian)盟(meng)由(you)半導體企業、視頻(pin)點(dian)播供應(ying)商和網頁(ye)瀏覽器開(kai)發商于 2015 年成立。互聯(lian)網工(gong)程任務組(zu)（IETF）也將這項工(gong)作(zuo)標(biao)(biao)準化為(wei)互聯(lian)網視頻(pin)編解碼(ma)器（NetVC）。AV1 的目(mu)標(biao)(biao)是取(qu)代(dai)其(qi)前身，即由(you) Google 開(kai)發的 VP9 視頻(pin)壓(ya)縮(suo)格(ge)式(shi)，并與(yu)動態圖(tu)像專家組(zu)（MPEG）領導開(kai)發的高效率視頻(pin)編碼(ma)（HEVC）競爭。
AV1可(ke)以與Opus音(yin)頻格式一(yi)起封(feng)裝(zhuang)在WebM容器格式中，并可(ke)用于 HTML5 網絡(luo)視(shi)頻和網頁即(ji)時(shi)通信。
AV1是(shi)一種使用傳統的(de)(de)基于(yu)區塊編碼(ma)(ma)但也加入了(le)新技(ji)術(shu)的(de)(de)頻(pin)率變換格式(shi)，AV1 所(suo)使用的(de)(de)編碼(ma)(ma)技(ji)術(shu)主要來源(yuan)于(yu)谷歌VP9的(de)(de)下一代(dai)視頻(pin)壓縮格式(shi) VP10，但同時也包含了(le)由Xiph.Org基金會的(de)(de)主要贊助者Mozilla開發的(de)(de)Daala視頻(pin)壓縮格式(shi)和(he)由Cisco開發的(de)(de)Thor視頻(pin)壓縮格式(shi)中所(suo)使用的(de)(de)視頻(pin)編碼(ma)(ma)技(ji)術(shu)。
3.2.2 其它格式
如表三所示。
3.3 音視頻容器
視頻(pin)(pin)格式(shi)：mp4、rmvb、avi、mkv、mov...，其(qi)實(shi)是包裹了音(yin)視頻(pin)(pin)編碼(ma)數(shu)據的容器。用(yong)來把以特定編碼(ma)標準(zhun)編碼(ma)的視頻(pin)(pin)流和音(yin)頻(pin)(pin)流混在一起，成為(wei)一個文(wen)件(jian)。例如(ru)：mp4支(zhi)持(chi)H264、H265等視頻(pin)(pin)編碼(ma)/AAC、MP3等音(yin)頻(pin)(pin)編碼(ma)。
四、直播平臺架構
4.1 傳統直播平臺架構
RTMP+CDN模式(shi)，如圖七所示。
4.2 WebRTC架(jia)構
WebRTC雖然(ran)是一項主要使(shi)用(yong)P2P的(de)實時通訊技術，本應該(gai)是無中心化節點的(de)，但是在很(hen)(hen)多大型(xing)多人(ren)通訊場(chang)景，如果都使(shi)用(yong)端(duan)對端(duan)直(zhi)連，端(duan)上(shang)很(hen)(hen)容易會遇(yu)到帶(dai)寬和性能的(de)問題。所(suo)以就有了下圖的(de)三種服務端(duan)架構，如圖八所(suo)示。
建議：如(ru)果規模不大(5人(ren)以(yi)下) Mesh框架就夠用了，畢竟(jing)實現簡單；如(ru)果50人(ren)以(yi)下，且(qie)帶寬(kuan)有限(xian)，選擇(ze)MCU比較適合(he)；如(ru)果規模更大，且(qie)帶寬(kuan)良好，SFU相(xiang)對更適合(he)。
4.2.1 MESH服(fu)務端(duan)架構
Mesh每個(ge)端都與(yu)其(qi)它端互連。以上(shang)圖(tu)最左側為例：5個(ge)瀏(liu)覽器，二(er)二(er)建立P2P連接(jie)(jie)，每個(ge)瀏(liu)覽器與(yu)其(qi)它4個(ge)建立連接(jie)(jie)，總共需要(yao)10個(ge)連接(jie)(jie)。如果每條(tiao)連接(jie)(jie)占用1M帶寬(kuan)，則每個(ge)端上(shang)行需要(yao)4M，下(xia)行帶寬(kuan)也要(yao)4M，總共帶寬(kuan)消耗(hao)20M。而且除了帶寬(kuan)問題，每個(ge)瀏(liu)覽器上(shang)還要(yao)有音視頻(pin)“編(bian)碼(ma)/解(jie)碼(ma)”、CPU使用率等(deng)也是問題。一般這種架構只能支(zhi)持(chi)4-6人左右，不過(guo)優點(dian)(dian)也很(hen)明顯，沒有中心節點(dian)(dian)，實現簡(jian)單(dan)。
4.2.2 MCU服(fu)務端架構(gou)
MCU（MultiPoint Control Unit，多(duo)點控制單元(yuan)）是(shi)一(yi)種(zhong)傳統的(de)(de)中心(xin)化架構(上(shang)(shang)圖中間部分)：每個(ge)瀏覽器(qi)僅與中心(xin)的(de)(de)MCU服務器(qi)連(lian)(lian)接，MCU服務器(qi)負責所有的(de)(de)視(shi)頻編(bian)碼(ma)、轉碼(ma)、解碼(ma)、混合(he)等(deng)復雜(za)邏輯。每個(ge)瀏覽器(qi)只要1個(ge)連(lian)(lian)接，整(zheng)個(ge)應用僅消耗5個(ge)連(lian)(lian)接，帶(dai)寬占用(包括上(shang)(shang)行(xing)、下行(xing)）共10M，瀏覽器(qi)端的(de)(de)壓力要小很多(duo)，可以支持更多(duo)的(de)(de)人同時音視(shi)頻通訊，比較(jiao)(jiao)適合(he)多(duo)人視(shi)頻會議。但是(shi)MCU服務器(qi)的(de)(de)壓力較(jiao)(jiao)大，需要較(jiao)(jiao)高的(de)(de)配(pei)置。
4.2.3 SFU服務(wu)端架構(gou)
SFU(Selective Forwarding Unit，可選擇轉(zhuan)發(fa)單元)，見上圖右(you)側部(bu)分：有(you)中(zhong)心(xin)節點服務(wu)(wu)器，但(dan)(dan)是中(zhong)心(xin)節點只負(fu)責轉(zhuan)發(fa)，不(bu)做復雜的(de)邏輯處理，所(suo)以服務(wu)(wu)器的(de)壓力(li)會(hui)低很多，配置也不(bu)象MCU要(yao)求(qiu)那么高。但(dan)(dan)是每個端(duan)需要(yao)建立一個連接用于上傳(chuan)自己的(de)視頻，同(tong)時還要(yao)有(you)N-1個連接用于下載其它參與方的(de)視頻信息(xi)。所(suo)以總(zong)連接數為5*5，消耗的(de)帶寬也是最大的(de)，如果每個連接1M帶寬，總(zong)共需要(yao)25M帶寬，它的(de)典型場(chang)景是1對N的(de)視頻互動(dong)。
4.2.4 WebRTC內(nei)部(bu)架構
WebRTC的內(nei)部架構，如(ru)圖九所示。
最上層的帶(dai)箭頭的淺紫(zi)色(se)部分是指(zhi)開(kai)發者基于WebRTC技術規范所開(kai)發的應用程序。嚴格(ge)來說(shuo)這并不屬于WebRTC的架(jia)構內容。
中(zhong)間的(de)深紫色的(de)Web API部分表示(shi)的(de)是(shi)WebRTC開放給應(ying)用層(ceng)(ceng)開發人員(yuan)調(diao)(diao)用的(de)API(主要是(shi)JavaScript API供(gong)Web端使用),在這層(ceng)(ceng)中(zhong)開發者無需(xu)關心復雜的(de)底層(ceng)(ceng)技(ji)術，只需(xu)了解WebRTC的(de)大致流程(cheng)原(yuan)理，調(diao)(diao)其API即可利用WebRTC實(shi)現點對點的(de)通訊功能。
下(xia)方的(de)綠色(se)部分是WebRTC的(de)核(he)心功能(neng)層(ceng)(ceng)(ceng)，這一層(ceng)(ceng)(ceng)又被分為了四個(ge)子(zi)功能(neng)層(ceng)(ceng)(ceng)。分別是C++API層(ceng)(ceng)(ceng)、會話管理層(ceng)(ceng)(ceng)、引擎(qing)層(ceng)(ceng)(ceng)和驅動(dong)層(ceng)(ceng)(ceng)。
客戶端提供了Android和iOS的(de)SDK，并支(zhi)持Windows、MAC、Linux的(de)瀏覽器。
五、開源項目
5.1 RTMP開源項目(mu)
Nginx-RTMP
C++開源(yuan)。基(ji)于Nginx的擴展，提供RTMP，HTTP-FLV ，HLS。
SRS
C++開源。功能提(ti)供RTMP，HTTP-FLV，HLS等。商(shang)業級服務端，支持多臺服務器(qi)擴展。
EasyRTMP
C開源。結合了多種(zhong)音視頻緩存(cun)及網絡技術的(de)一個(ge)RTMP直播推(tui)流(liu)端，包括：圓形(xing)緩沖(chong)區(Circular Buffer)、智能(neng)丟(diu)幀、自(zi)動(dong)重連、RTMP協議等多種(zhong)技術。
OBS
C++/QT開(kai)源。OBS(Open Broadcaster Software)是一款開(kai)源可(ke)以(yi)直(zhi)接視(shi)(shi)頻(pin)直(zhi)播的軟件。常(chang)常(chang)用在游戲直(zhi)播中(zhong)，軟件支持串(chuan)流(liu)、音頻(pin)、視(shi)(shi)頻(pin)等設置，能夠讓用戶可(ke)以(yi)自由(you)選(xuan)擇(ze)自己(ji)的直(zhi)播模式。基于(yu)著名的開(kai)源項目FFmpeg(跨平臺視(shi)(shi)頻(pin)/音頻(pin)流(liu)方案)。
5.2 RTSP開源項目
live555
C++開源。live555是重量級(ji)的(de)一(yi)個流媒(mei)體(ti)開源項目，其中不僅包括了傳(chuan)輸協議（SIP、RTP）、音視(shi)頻編碼(ma)器（H.264、MPEG4）等，還包括流媒(mei)體(ti)服務器的(de)例子(zi)，是流媒(mei)體(ti)項目的(de)首選。
VLC
C++/QT開源。跨平臺(tai)媒體播放(fang)器，并(bing)集合先進的(de)(de)流媒體功能(neng)可以通過IPv4或IPv6的(de)(de)高帶(dai)寬網絡進行流媒體傳(chuan)輸。它(ta)還支持多種視頻(pin)格式(shi)和流協議。基于著名的(de)(de)開源項目FFmpeg(跨平臺(tai)視頻(pin)/音頻(pin)流方案)。
5.3 WebRTC開源項目
如表四所示。
————————————————
版權(quan)聲明(ming)(ming)：本文(wen)(wen)為CSDN博主(zhu)「Johnny-Xu」的原創文(wen)(wen)章(zhang)，遵(zun)循CC 4.0 BY-SA版權(quan)協議，轉(zhuan)載請(qing)附上原文(wen)(wen)出處鏈接及本聲明(ming)(ming)。
原文鏈接：//blog.csdn.net/jz_x/article/details/113756871
