前言:
網絡視訊直播存在已有很長一段時間，随着移動上下行帶寬提升及資費的下調，
視訊直播被賦予了更多娛樂和社交的屬性，人們享受随時随地進行直播和觀看，
直播的打開時間和延遲變成了影響産品功能發展重要名額。
注：本文是以原文為主體，加上我自己的一些總結和補充寫的
那麼，問題來了：
如何實作低延遲、秒開的直播？
先來看看視訊直播的5個關鍵的流程：
錄制->編碼->網絡傳輸->解碼->播放，
每個環節對于直播的延遲都會産生不同程度的影響。
這裡重點分析移動裝置的情況。
受限于技術的成熟度、硬體環境等，我們針對移動場景簡單總結出直播延遲優化的4個點：
網絡、協定、編解碼、移動終端，
并将分四大塊來一一解密UCloud直播雲實作低延遲、秒開的技術細節。
一、UCloud直播雲實作接入網絡優化的技術細節：
1）全局負載均衡-就近接入
實作就近接入的技術比較廣為人知，就是CDN即Content Delivery Network （内容分發網絡）。
CDN包含兩大核心技術：
負載均衡和分發網絡。
随着10多年的演進，對負載均衡和分發的實作方式已多種多樣，
分發網絡的建構政策通常是經過日積月累的總結出一套最合适的分發路由，
并且也不是一成不變，需時刻關注調整，動态營運。
這裡重點介紹下CDN的負載均衡技術。
負載均衡是如何實作讓使用者就近通路的呢？
比較普遍的實作方式：通過使用者使用的DNS伺服器來判斷用戶端所在的網絡位置，
進而傳回對應的服務IP。
如下圖示例:
Fig-2
廣東電信使用者IP:1.1.1.1 需要看一個直播http://www.ucloud.cn/helloworld.flv ，
實作就近通路的過程是：
S1. 使用者向配置的DNS伺服器1.1.1.0
(通常是營運商指定，也稱local DNS，後面簡稱Ldns)發起www.ucloud.cn 的查詢；
S2. Ldns 上沒有該域名的記錄，則往頂級即Root NS上發起查詢；
S3. Root NS傳回告知Ldns該域名的權威解析記錄在UCloud NS上；
S4. Ldns 向UCloud NS發起查詢；
S5. UCloud NS 向UCloud GSLB服務發起查詢，GSLB發現 Ldns1.1.1.0是屬于廣東電信；
S6. 傳回廣東電信的就近節節點IP1.1.1.2；
S7. 傳回1.1.1.2給Ldns；
S8. 傳回給使用者1.1.1.2，使用者到1.1.1.2上去擷取直播内容。
鍊路很長，
但是每個Ldns上都會對查詢過的域名做合理的緩存，
下一個廣東電信的使用者再來查詢的時候就可以直接傳回1.1.1.2。
架構并不複雜，關鍵點是如何知道Ldns是位于廣東電信，這就涉及一個IP位址庫。
有開源位址庫，也有商業位址庫，可以按需求采購即可，一般一年1萬左右。
例如，淘寶的IP位址庫
淘寶官方ip位址庫 http://ip.taobao.com/
接口說明
1. 請求接口（GET）：
http://ip.taobao.com/service/getIpInfo.php?ip=[ip位址字串]
2. 響應資訊：
（json格式的）國家 、省（自治區或直轄市）、市（縣）、營運商
3. 傳回資料格式：
{"code":0,"data":{"ip":"210.75.225.254","country":"\u4e2d\u56fd","area":"\u534e\u5317",
"region":"\u5317\u4eac\u5e02","city":"\u5317\u4eac\u5e02","county":"","isp":"\u7535\u4fe1",
"country_id":"86","area_id":"100000","region_id":"110000","city_id":"110000",
"county_id":"-1","isp_id":"100017"}}
其中code的值的含義為，0：成功，1：失敗。
這裡不難看出來，排程的準确度是完全依賴使用者配置的Ldns，
而這些Ldns大多數是省級别的，即GLSB隻知道使用者是廣東電信，
但是常常分不出來是廣東廣州電信，還是廣東深圳電信。
HTTPDNS就是實作更精準的排程一種方式：
Fig-3
S1. 使用者1.1.1.1通過HTTP協定直接向UCloud NS請求直播域名www.ucloud.cn；
S2. UCloud NS發現使用者IP1.1.1.1屬于廣東深圳電信；
S3. 傳回廣東深圳電信節點1.1.1.11給UCloud NS；
S4. 傳回給使用者。
HTTPDNS的好處顯而易見：
一可精準獲得使用者端的IP，有效避免使用者配錯Ldns（有時是網絡中心配錯DNS）的情況，
可更精準定位使用者所在網絡位置。
二可避免DNS解析劫持。
2）BGP中轉架構-最短傳輸路徑
BGP即Border Gateway Protocol （邊界網關協定），業内簡稱BGP。
為什麼BGP中轉架構對直播加速和分發如此重要？
不得不提國内複雜的網絡狀況，較廣為人知的是“南電信北聯通”的寬帶使用者分布。
那一個簡單的問題，電信主播發起了直播，聯通的使用者想看怎麼辦呢？
從結構上講，肯定是有有限個電信聯通兩個營運商的交彙點，相當于資訊橋梁。
這就會帶來兩個問題：
1、路程要繞遠，網絡延遲高且不穩定；
2、高峰期擁堵，導緻直播流卡頓。
BGP的技術原理往簡單的說就是允許同一IP在不同網絡中廣播不同的路由資訊，
效果就是同一個IP，當電信使用者來通路時走電信網内的路由，
聯通使用者來通路時走的聯通的路由。
是以BGP技術對跨營運商的通路帶來了巨大的便利，特别是直播場景。
不同于傳統的檔案緩存場景，一個圖檔哪怕第一次是跨了遙遠的距離從源站擷取後，
本地網絡進行緩存，後面的通路都走本地網絡。
直播加速是流式的，并且當要做到低延遲的時候，中間的緩存要盡可能少。
BGP相當于給跨網的使用者就近搭建了一坐橋梁，不必繞遠路，延時和穩定性都大大提高了。
Fig-4
技術原理部分介紹完了，那麼它對直播延遲影響有多少改善呢？
首先這裡的就近，不一定是實體距離近，不考慮瞬時負載情況下，
更多是指測速延時最優的機房。
在國内一般而言相同的接入營運商（電信、聯通、移動）
并且地理位置最近的情況網絡延遲最優，小于15ms。
跨省同營運商的網絡延遲25~50ms，
跨營運商情況更複雜一些，在50~100ms。
總結起來，直播當中每個包的延時可以縮短100ms，
由于網絡的疊加效果，反射到上層是秒級的延遲縮減。
【總結】
是以，網絡部分的優化是兩點:
1. 使用自己的HTTPDNS， 換句話說，就是要搭建自己的快速高并發的排程系統；
2. 使用BGP機房；
二、直播應用層協定及傳輸層協定的選擇以及對直播體驗影響的分析
直播協定的選擇
國内常見公開的直播協定有幾個：RTMP、HLS、HDL（HTTP-FLV）、RTP，
我們來逐一介紹。
RTMP協定：
是Adobe的專利協定，現在大部分國外的CDN已不支援。
在國内流行度很高。原因有幾個方面：
1、 開源軟體和開源庫的支援穩定完整。
如鬥魚主播常用的OBS軟體，開源的librtmp庫，服務端有nginx-rtmp插件。
2、 播放端安裝率高。
隻要浏覽器支援FlashPlayer就能非常簡易的播放RTMP的直播，
協定詳解可以Google了解。
相對其他協定而言，RTMP協定初次建立連接配接的時候握手過程過于複雜
（底層基于TCP，這裡說的是RTMP協定本身的互動），
視不同的網絡狀況會帶來給首開帶來100ms以上的延遲。
基于RTMP的直播一般内容延遲在2~5秒。
Fig-5
HTTP-FLV協定：
即使用HTTP協定流式的傳輸媒體内容。
相對于RTMP，HTTP更簡單和廣為人知，而且不擔心被Adobe的專利綁架。
内容延遲同樣可以做到2~5秒，打開速度更快，因為HTTP本身沒有複雜的狀态互動。
是以從延遲角度來看，HTTP-FLV要優于RTMP。
HLS 協定：
即Http Live Streaming，是由蘋果提出基于HTTP的流媒體傳輸協定。
HLS有一個非常大的優點：HTML5可以直接打開播放；
這個意味着可以把一個直播連結通過微信等轉發分享，
不需要安裝任何獨立的APP，有浏覽器即可，是以流行度很高。
社交直播APP，HLS可以說是剛需，下來我們分析下其原理 。
基于HLS的直播流URL是一個m3u8的檔案，
裡面包含了最近若幹個小視訊TS（一種視訊封裝格式，這裡就不擴充介紹）檔案，
如 http://www.ucloud.cn/helloworld.m3u8 是一個直播留連結，
其内容如下：
假設清單裡面的包含5個TS檔案，每個TS檔案包含5秒的視訊内容，
那麼整體的延遲就是25秒。
當然可以縮短清單的長度和單個TS檔案的大小來降低延遲，
極緻來說可以縮減清單長度為1，1秒内容的m3u8檔案，
但是極易受網絡波動影響造成卡頓。
通過公網的驗證，目前按同城網絡可以做到比較好的效果是5~7秒的延遲，
也是綜合流暢度和内容延遲的結果。
那麼HTML5是否可以有更低延遲直接打開的直播流技術呢？ 我們在最後會探讨這個問題。
RTP協定：
即Real-time Transport Protocol，用于Internet上針對多媒體資料流的一種傳輸層協定。
實際應用場景下經常需要RTCP（RTP Control Protocol）配合來使用，
可以簡單了解為RTCP傳輸互動控制的信令，RTP傳輸實際的媒體資料。
RTP在視訊監控、視訊會議、IP電話上有廣泛的應用，
因為視訊會議、IP電話的一個重要的使用體驗：内容實時性強。
對比與上述3種或實際是2種協定，
RTP和它們有一個重要的差別就是預設是使用UDP協定來傳輸資料，
而RTMP和HTTP是基于TCP協定傳輸。
為什麼UDP 能做到如此實時的效果呢？
關于TCP和UDP差别的分析文章一搜一大把，這裡不在贅述，簡單概括：
UDP：單個資料報，不用建立連接配接，簡單，不可靠，會丢包，會亂序；
TCP：流式，需要建立連接配接，複雜，可靠 ，有序。
實時音視訊流的場景不需要可靠保障，是以也不需要有重傳的機制，
實時的看到圖像聲音，網絡抖動時丢了一些内容，畫面模糊和花屏，完全不重要。
TCP為了重傳會造成延遲與不同步，如某一截内容因為重傳，導緻1秒以後才到，
那麼整個對話就延遲了1秒，随着網絡抖動，延遲還會增加成2秒、3秒，
如果用戶端播放是不加以處理将嚴重影響直播的體驗。
總結一下：
在直播協定的選擇中，如果選擇是RTMP或HTTP-FLV則意味着有2~5秒的内容延遲，
但是就打開延遲來看，HTTP-FLV 要優于RTMP。
HLS則有5~7秒的内容延遲。
選擇RTP進行直播則可以做到1秒内的直播延遲。
但就目前所了解，各大CDN廠商沒有支援基于RTP直播的，
是以目前國内主流還是RTMP或HTTP-FLV。
是否有除了HLS外更低延遲的方案？
HLS的優點點是顯而易見的：移動端無需安裝APP使用相容HTML5的浏覽器打開即可觀看，
所有主流的移動端浏覽器基本都支援HTML5，在直播的傳播和體驗上有巨大的優勢。
而看起來唯一的缺點：
内容延遲高
（這裡也有很多HLS限制沒有提到，比如必須是H264 AAC編碼，也可認為是“缺點”之一）。
如果能得到解決，那将會是直播技術非常大的一個進步。
或者換個說法，有沒有更低延遲可直接用連結傳播的直播方案？
不局限于HLS本身。
對于浏覽器直接的視訊互動，Google一直在推WebRTC，目前已有不少成型的産品出現，
可以浏覽器打開即實時對話、直播。但來看看如下的浏覽器覆寫圖：
非常遺憾的說，在直至iOS 9.3上的Safari仍然不能支援WebRTC。
繼續我們的探索，那Websocket支援度如何呢？
除了老而不化的Opera Mini外，所有的浏覽器都支援WebSocket。
這似乎是個好消息。
如果采用HTML5 WebSocket來做直播，
那我們先來梳理一下HTML5 WebSocket直播需要解決的問題：
1、後端相容
2、傳輸
3、解碼播放
對于
#1似乎不是特别大問題，對于做過RTMP轉HLS、RTP來說是基本功。
#2對于浏覽器來說使用HTTP來傳輸是比較好的選項。
對于#3 這裡推薦一個開源的JS解碼項目jsmpeg: https://github.com/phoboslab/jsmpeg，
裡面已有一個用于直播的stream-server.js的NodeJS伺服器。
從測試結果看，該項目的代碼相對較薄，還沒達到工業級的成熟度，
需要大規模應用估計需要自填不少坑，有興趣的同學可以學習研究。
以上就是直播雲：直播應用層協定及傳輸層協定的選擇以及對直播體驗影響的分析 。
關于接入網絡優化、内容緩存與傳輸政策優化、終端優化，請參閱接下來釋出的其他部分。
【我的總結】
1. 以延時從低到高來看，協定上方案選擇為:
RTP/UDP: 可以做到秒内延時，目前國内的CDN都不支援，
但有些公司開發了私有協定實作了基于它們的直播，而且它們的延時都小于1秒，
甚至小于500ms, 像YY， 映客直播采用的第三方技術等；
webRTC: 可以做到秒内延時，實際上它也是使用的RTP，
單列出來是因為它是Google開源出來的，目前社群也開始活躍，做的人也多了；
依據它出服務的公司國内有聲網，中國電信研究院等；
HTTP-FLV: 内容延遲可以做到2~5秒，打開快；
RTMP: 内容延遲可以做2~5秒，當網絡不好造成重傳時，延時會大量增加；
HTML5 WebSocket: 方案還不成熟，延時可能也會在2~5秒；
HLS: 有5~7秒的内容延遲
三、在傳輸直播流媒體過程中的内容緩存與傳輸政策優化細節原理
基礎知識：I幀、B幀、P幀
I幀表示關鍵幀。
你可以了解為這一幀畫面的完整保留；解碼時隻需要本幀資料就可以完成。
（因為包含完整畫面）
P幀表示這一幀跟之前的一個關鍵幀（或P幀）的差别。
解碼時需要用之前緩存的畫面疊加上本幀定義的差别，生成最終畫面。
（也就是差别幀，P幀沒有完整畫面資料，隻有與前一幀的畫面差别的資料）
B幀是雙向差别幀。
B幀記錄的是本幀與前後幀的差别（具體比較複雜，有4種情況）。
換言之，要解碼B幀，不僅要取得之前的緩存畫面，還要解碼之後的畫面，
通過前後畫面的與本幀資料的疊加取得最終的畫面。
B幀壓縮率高，但是編解碼時會比較耗費CPU，而且在直播中可能會增加直播延時，
是以在移動端上一般不使用B幀。
Fig-6
關鍵幀緩存政策
一個典型的視訊幀序列為IBBPBBPBBP……
對于直播而言，為了減少直播的延時，通常在編碼時不使用B幀。
P幀B幀對于I幀都有直接或者間接的依賴關系，
是以播放器要解碼一個視訊幀序列，并進行播放，必須首先解碼出I幀，
其後續的B幀和P幀才能進行解碼，
這樣服務端如何進行關鍵幀的緩存，則對直播的延時以及其他方面有非常大的影響。
比較好的政策是服務端自動判斷關鍵幀的間隔，
按業務需求緩存幀序列，保證在緩存中存儲至少兩個或者以上的關鍵幀，
以應對低延時、防卡頓、智能丢包等需求。
延遲與卡頓的折中
直播的延時與卡頓是分析直播業務品質時，非常關注的兩項名額。
互動直播的場景對延時非常敏感，新聞體育類直播則更加關注播放的流暢度。
然而，這兩項名額從理論上來說，是一對沖突的關系
---需要更低的延時，則表明伺服器端和播放端的緩沖區都必須更短，
來自網絡的異常抖動容易引起卡頓；
---業務可以接受較高的延時時，服務端和播放端都可以有較長的緩沖區，
以應對來自網絡的抖動，提供更流暢的直播體驗。
當然，對于網絡條件非常好的使用者，這兩項是可以同時保證的，
這裡主要是針對網絡條件不是那麼好的使用者，如何解決延時與卡頓的問題。
這裡通常有兩種技術來平衡和優化這兩個名額。
一是服務端提供靈活的配置政策，
. 對于延時要求更敏感的，
則在服務端在保證關鍵幀的情況下，對每個連接配接維持一個較小的緩沖隊列；
. 對于卡頓要求更高的直播，
則适當增加緩沖隊列的長度，保證播放的流暢。
二是服務端對所有連接配接的網絡情況進行智能檢測，
當網絡狀況良好時，服務端會縮小該連接配接的緩沖隊列的大小，降低延遲；
而當網絡狀況較差時，特别是檢測到抖動較為明顯時，
服務端對該連接配接增加緩沖隊列長度，優先保證播放的流暢性。
丢包政策
什麼時候需要丢包呢？
對于一個網絡連接配接很好，延時也比較小的連接配接，丢包政策永遠沒有用武之地的。
而網絡連接配接比較差的使用者，因為下載下傳速度比較慢或者抖動比較大，
這個使用者的延時就會越來越高。
另外一種情況是，如果直播流關鍵幀間隔比較長，
那麼在保證首包是關鍵幀的情況下，觀看這個節目的觀衆，
延遲有可能會達到一個關鍵幀序列的長度。
上述兩種情況，都需要啟用丢包政策，來調整播放的延時。
關于丢包，需要解決兩個問題：
一是正确判斷何時需要進行丢包；
二是如何丢包以使得對觀衆的播放體驗影響最小。
較好的做法是後端周期監控所有連接配接的緩沖隊列的長度，
這樣隊列長度與時間形成一個離散的函數關系，後端通過自研算法來分析這個離散函數，判斷是否需要丢包。
一般的丢幀政策，就是直接丢棄一個完整的視訊幀序列，這種政策看似簡單，但對使用者播放的影響體驗非常大。
而應該是背景采用逐漸丢幀的政策，每個視訊幀序列，丢最後的一到兩幀，使得使用者的感覺最小，
平滑的逐漸縮小延時的效果。
四、用戶端的優化
解析優化
參見之前介紹的DNS過程，如下圖：
Fig-7
基于可控和容災的需要，
移動端代碼一般不會hardcode 推流、播放的伺服器IP位址，而選用域名代替。
在IP出現當機或網絡中斷的情況下，還可以通過變更DNS來實作問題IP的剔除。
而域名的解析時間需要幾十毫秒至幾秒不等，對于新生成熱度不高的域名，
一般的平均解析延遲在300ms，按上圖的各個環節隻要有一個通路網絡産生波動或者是裝置高負載，會增加至秒級。
幾十毫秒的情況是ISP NS這一層在熱度足夠高的情況下會對域名的解析進行緩存。如下圖：
Fig-8
按我們上面分析的情況，本省延遲大概是15ms左右，
那麼域名解析最低也可以做到15ms左右。
但由于直播場景的特殊性，推流和播放使用的域名使用的熱度較難達到ISP NS緩存的标準，
是以經常需要走回Root NS進行查詢的路徑。
那用戶端解析優化的原理就出來了：
本機緩存域名的解析結果，對域名進行預解析，
每次需要直播推流和播放的時候不再需要再進行DNS過程。
此處節省幾十到幾百毫秒的打開延遲。
播放優化
直播播放器的相關技術點有：直播延時、首屏時間（指從開始播放到第一次看到畫面的時間）、
音視訊同步、軟解碼、硬解碼。參考如下播放流程：
Fig-9
播放步驟描述：
S1. 根據協定類型（如RTMP、RTP、RTSP、HTTP等），與伺服器建立連接配接并接收資料；
S2. 解析二進制資料，從中找到相關流資訊；
S3. 根據不同的封裝格式（如FLV、TS）解複用（demux）；
S4. 分别得到已編碼的H.264視訊資料和AAC音頻資料；
S5. 使用硬解碼（對應系統的API）或軟解碼（FFMpeg）來解壓音視訊資料；
S6. 經過解碼後得到原始的視訊資料（YUV）和音頻資料（AAC）；
因為音頻和視訊解碼是分開的，是以我們得把它們同步起來，
否則會出現音視訊不同步的現象，比如别人說話會跟口型對不上；
S7. 最後把同步的音頻資料送到耳機或外放，視訊資料送到螢幕上顯示。
了解了播放器的播放流程後，我們可以優化以下幾點：
首屏時間優化
從步驟2入手，通過預設解碼器類型，省去探測檔案類型時間；
從步驟5入手，縮小視訊資料探測範圍，同時也意味着減少了需要下載下傳的資料量，
特别是在網絡不好的時候，減少下載下傳的資料量能為啟動播放節省大量的時間，
當檢測到I幀資料後就立馬傳回并進入解碼環節。
延時優化
視訊緩沖區或叫視訊緩存政策，
該政策原理是當網絡卡頓時增加使用者等待時間來緩存一定量的視訊資料，
達到後續平滑觀看的效果，該技術能有效減少卡頓次數，
但是會帶來直播上的内容延時，是以該技術主要運用于點播，直播方面已去掉該政策，
以此盡可能去掉或縮小内容從網絡到螢幕展示過程中的時間；（有利于減少延時）。
下載下傳資料探測池技術，當使用者下載下傳速度不足發生了卡頓，然後網絡突然又順暢了，
伺服器上之前滞留的資料會加速發下來，這時為了減少之前卡頓造成的延時，
播放器會加速播放探測池的視訊資料并丢棄目前加速部分的音頻資料，
以此來保證目前觀看内容延時穩定。
推流優化
Fig-10
推流步驟說明：很容易看出推流跟播放其實是逆向的，具體流程就不多說了。
優化一：适當的Qos（Quality of Service，服務品質）政策。
推流端會根據目前上行網絡情況控制音視訊資料發包和編碼，
在網絡較差的情況下，音視訊資料發送不出去，造成資料滞留在本地，
這時，會停掉編碼器防止發送資料進一步滞留，
同時會根據網絡情況選擇合适的政策控制音視訊發送。
比如網絡很差的情況下，推流端會優先發送音頻資料，保證使用者能聽到聲音，
并在一定間隔内發關鍵幀資料，保證使用者在一定時間間隔之後能看到一些畫面的變化。
優化二：合理的關鍵幀配置。
合理控制關鍵幀發送間隔（建議2秒或1秒一個），這樣可以減少後端處理過程，
為後端的緩沖區設定更小創造條件。
軟硬編解選擇
網上有不少關于選擇軟解還是硬解的分析文章，這裡也介紹一些經驗，
但根本問題是，沒有一個通用方案能最優适配所有作業系統和機型。
推流編碼： 推薦Andorid4.3（API18）或以上使用硬編，以下版本使用軟編；iOS使用全硬編方案；
播放解碼：Andorid、iOS播放器都使用軟解碼方案，經過我們和大量客戶的測試以及總結，
雖然犧牲了功耗，但是在部分細節方面表現會較優，且可控性強，相容性也強，出錯情況少，推薦使用。
附軟硬編解碼優缺點對比：
Fig-11
雲端機型及網絡适配
上面分析了很多針對視訊編解碼的參數，
但實際情況最好的編解碼效果是需要根據機型的适配的，
由于iOS的裝置類型較少，可以做到每個機型針對性的測試和調優，
但是對于Android就非常難做到逐款機型針對性調優，并且每年都會出産不少的新機器，
如果代碼中寫死了配置或判斷邏輯将非常不利于維護和疊代。
Fig-12
是以我們就誕生了一個想法，這些判斷邏輯或配置是否可以放在雲上呢?
這樣就産生了雲端機型與網絡适配的技術。
終端在推流、播放前會擷取通過協定上報目前的機型配置、網絡情況、IP資訊。
雲端會傳回一個已最适合的編解碼政策配置：
走軟編還是硬編、各項參數的配置，就近推流服務的IP，就近播放服務的IP。
終端擷取一次即可，不需要每次推流、播放前都去擷取一次。
這樣，在我們不斷的疊代和完善機型編解碼适配庫的同時，
所有使用該技術的直播APP都将收益。
總結
分析很多直播後端、終端的關于低延遲、秒開的優化技術，
在UCloud直播雲上都已有了相關的實踐，都是一些較“靜态”的技術。
實際提供穩定、低延遲、流暢的直播服務，
是日常中非常大量細緻的監控、算法和動态營運的結果，并不是實作了某些的技術點，
就能坐享一套穩定的直播服務，隻能說是完成了萬裡長城的第一道磚。
五、CDN分發政策對直播體驗影響的分析
在整個直播鍊條中，除了上面的内容外，實際上還有兩項重要的核心技術文章回避了沒有講，
一個是CDN分發政策，一個是P2P技術；
CDN分發政策指的是對于一個源(檔案或直播流)，如何快速分發到成百上千的邊緣節點；
對于直播來說，一種政策是全連通結構，一種是樹狀結構
實際上，對于實際大型應用或商用的CDN網絡，它們在做内容分發時，
并不是使用上面所講的傳輸協定，
例如，對于RTMP接入流，就用RTMP協定；而對于HTTP-FLV接入流,就用HTTP協定，将資料從源分發到邊緣節點；
實際的做法是将所有接入流資料進行私有協定的轉封裝，然後再用自已開發私有的(如基于UDP)傳輸協定進行分發；
隻有這樣，才能做到多業務相容和擴充，以及減少開發和營運成本；
5.1 全連通結構
全連通結構如圖所示:
Fig-13
上圖中，中控的作用有:
. 管理節點配置
. 評估節點間網絡品質
. 構造全連通圖
全連通結構的特點是:
1. 結構扁平化，所有的伺服器位置平等，全連通；
2. 被動觸發，
意思是系統先配置設定一個離使用者最近/網絡最好/負載最小的邊緣節點給使用者，
如果這個節點有資料，則從這個節點取資料；
如果這個節點沒有資料，則從離他最近/網絡最好/負載最低的有資料的節點(或源節點)取資料，再轉給使用者；
當節點間資料傳輸的連結建立後，就一直保持，直到整個分發完成或直播結束；
3. 資料傳輸速度快，
因為他的網絡結構扁平，級數少，可以做到分級緩存，分層管理；
可以利用記憶體來處理資料，便于小檔案效率高
4. 适合于小規模(如秀場等，并發量在10W 以下)直播
因為它的結構扁平，經過優化，延時可以做到2秒以内；
5.2 樹狀結構
樹狀結構如圖所示:
Fig-14
樹狀結構的特點是:
1. 樹狀結構能避免環路和孤島；
2. 使用TCP長連接配接，可以以幀為最小機關傳輸；
3. 在政策上，可以将網絡品質差的節點自動挂載到樹的下層；
4. 樹的根節點、主幹和支節點都不提供對外服務，隻在葉節點提供對外服務；
這樣做是最大可能的保證了骨幹網絡的傳輸快速和健壯；
5. 樹要預先建立，并将内容提前分發，這樣的話樹的建立需要一定的時間
6. 适合于大規模(如大型節目，NBA等，并發在10W以上)的直播；
因為它的分發結構是樹狀多層，每層都會帶來延時，經過測試，它的延時通常在2秒以上；
六、P2P技術對直播體驗影響的分析
應當說，隻有大型直播采用P2P才有價值，
因為P2P的特點是觀看同一場直播的使用者越多，能分享的Peer也就越多，也就越流暢；
它的引入，對于直播來說通常有超過5秒以上的延時；
因為要實作P2P，就需要将流緩沖，以切成檔案，再做分享；