直播過程：采集 → 處理 → 編碼 → 推流 → CDN分發 → 拉流 → 解碼 → 播放
"stream_push": "rtmp://push-stream3-live-ssl.a.88cdn.com/live/1570_253746839?auth_key=1576833218-253746839-0-35787c8a0c044a6d35e20853ac25a4eb",
"stream_pull": "http://pull-stream3-live-ssl.a.88cdn.com/live/1570_253746839.flv?auth_key=1576836305-253746839-0-5e890d2e433c74c5da37b793c33f7907"
"stream_flv_pull_https": "https://pull-stream3-live-ssl.a.88cdn.com/live/1570_253746839.flv?auth_key=1576836305-253746839-0-5e890d2e433c74c5da37b793c33f7907"
"stream_hls_pull_https": "https://pullhls-stream3-live-ssl.a.88cdn.com/live/1570_253746839.m3u8?auth_key=1576836305-253746839-0-78b1ee171eaa9c2ba25ea15bdf36917b",
CDN（CDN即Content Delivery Network （內容分發網絡））
通過用戶使用的DNS服務器來判斷客戶端所在的網絡位置，從而返回對應的服務IP。
BGP中轉架構-最短傳輸路徑（BGP即Border Gateway Protocol （邊界網關協議））
BGP的技術原理往簡單的說就是允許同一IP在不同網絡中廣播不同的路由信息，效果就是同一個IP，當電信用戶來訪問時走電信網內的路由，聯通用戶來訪問時走的聯通的路由（即IP唯一性）。
BGP相當於給跨網的用戶就近搭建了一坐橋梁，不必繞遠路，延時和穩定性都大大提高了
經過BGP的優化之后，我們還需要對網絡的機房選路有一個優化。在國內一般而言相同的接入運營商（電信、聯通、移動）並且地理位置最近的情況網絡延遲最優，小於15ms。跨省同運營商的網絡延遲25~50ms，跨運營商情況更復雜一些，在50~100ms。總結起來，直播當中每個包的延時可以縮短100ms，由於網絡的疊加效果，反射到上層是秒級的延遲縮減。
直播協議
直播技術涉及很多的協議，如RTMP、HLS、HDL（HTTP-FLV）、RTP，我們使用的推流協議是rtmp協議，拉流協議是HDL（HTTP-FLV）。
RTMP協議
1、開源軟件和開源庫的支持穩定完整。開源的librtmp庫，服務端有nginx-rtmp插件。
2、播放端安裝率高。只要瀏覽器支持FlashPlayer就能非常簡易的播放RTMP的直播，RTMP協議初次建立連接的時候握手過程過於復雜（底層基於TCP，這里說的是RTMP協議本身的交互），視不同的網絡狀況會帶來給首開帶來100ms以上的延遲。基於RTMP的直播一般內容延遲在2~5秒。
HTTP-FLV協議
即使用HTTP協議流式的傳輸媒體內容。內容延遲同樣可以做到2~5秒，打開速度更快，因為HTTP本身沒有復雜的狀態交互。所以從延遲角度來看，HTTP-FLV要優於RTMP。
HLS 協議
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文件，但是極易受網絡波動影響造成卡頓。那么我們怎么解決這個問題呢？后面將專門為大家講解優化方案。
RTP協議
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。
流媒體內容緩存與傳輸策略優化
基礎知識：I幀、B幀、P幀
I幀表示關鍵幀。你可以理解為這一幀畫面的完整保留；解碼時只需要本幀數據就可以完成。
P幀表示這一幀跟之前的一個關鍵幀（或P幀）的差別。解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。
B幀是雙向差別幀。B幀記錄的是本幀與前后幀的差別（具體比較復雜，有4種情況）。換言之，要解碼B幀，不僅要取得之前的緩存畫面，還要解碼之后的畫面，通過前后畫面的與本幀數據的疊加取得最終的畫面。
注：B幀壓縮率高，但是編解碼時會比較耗費CPU，而且在直播中可能會增加直播延時，因此在移動端上一般不使用B幀。
關鍵幀緩存策略
如：一個典型的視頻幀序列為IBBPBBPBBP…… 對於直播而言，為了減少直播的延時，通常在編碼時不使用B幀。P幀B幀對於I幀都有直接或者間接的依賴關系，所以播放器要解碼一個視頻幀序列，並進行播放，必須首先解碼出I幀，其后續的B幀和P幀才能進行解碼，這樣服務端如何進行關鍵幀的緩存，則對直播的延時以及其他方面有非常大的影響。 比較好的策略是服務端自動判斷關鍵幀的間隔，按業務需求緩存幀序列，保證在緩存中存儲至少兩個或者以上的關鍵幀，以應對低延時、防卡頓、智能丟包等需求。
客戶端解析優化
移動端代碼一般不會hardcode 推流、播放的服務器IP地址，集成星域CDN的SDK，獲取遠端域名，走SDK替換成新的HTTP地址，省帶寬和拉流速度更快。
軟硬編解選擇
推流編碼： 使用硬編；
播放解碼：使用軟解碼方案。
軟編碼硬編碼優缺點對比：
了解更多：
https://cloud.tencent.com/developer/article/1037761?from=10680
https://www.kancloud.cn/alex_wsc/live/448158