下面就先介紹一下都有哪些推送協議，他們在直播領域的現狀和優缺點。
- RTMP
- WebRTC
- 基於 UDP 的私有協議
1. RTMP
RTMP 是 Real Time Messaging Protocol（實時消息傳輸協議）的首字母縮寫。該協議基於 TCP，是一個協議族，包括 RTMP 基本協議及 RTMPT/RTMPS/RTMPE 等多種變種。RTMP 是一種設計用來進行實時數據通信的網絡協議，主要用來在 Flash/AIR 平臺和支持 RTMP 協議的流媒體/交互服務器之間進行音視頻和數據通信。支持該協議的軟件包括 Adobe Media Server/Ultrant Media Server/red5 等。
RTMP 是目前主流的流媒體傳輸協議，廣泛用於直播領域，可以說市面上絕大多數的直播產品都採用了這個協議。
優點
·CDN 支持良好，主流的 CDN 廠商都支持
·協議簡單，在各平臺上實現容易
缺點
·基於 TCP ，傳輸成本高，在弱網環境丟包率高的情況下問題顯著
·不支持瀏覽器推送
·Adobe 私有協議，Adobe 已經不再更新
2. WebRTC
WebRTC，名稱源自網頁即時通信（英語：Web Real-Time Communication）的縮寫，是一個支持網頁瀏覽器進行實時語音對話或視頻對話的 API。它於 2011 年 6 月 1 日開源並在 Google、Mozilla、Opera 支持下被納入萬維網聯盟的 W3C 推薦標準。
目前主要應用於視頻會議和連麥中，協議分層如下：
優點
·W3C 標準，主流瀏覽器支持程度高
·Google 在背後支撐，並在各平臺有參考實現
·底層基於 SRTP 和 UDP，弱網情況優化空間大
·可以實現點對點通信，通信雙方延時低
缺點
·ICE,STUN,TURN 傳統 CDN 沒有類似的服務提供
3. 基於 UDP 的私有協議
有些直播應用會使用 UDP 做爲底層協議開發自己的私有協議，因爲 UDP 在弱網環境下的優勢通過一些定製化的調優可以達到比較好的弱網優化效果，但同樣因爲是私有協議也勢必有現實問題：
優點
·更多空間進行定製化優化
缺點
·開發成本高
·CDN 不友好，需要自建 CDN 或者和 CDN 達成協議
·獨立作戰，無法和社區一起演進
4.關於libjingle_peerconnection庫
爲什麼是peerconnection的庫呢？
第一，peerconnection是webrtc對外的提供的比較全的接口的類
第二，peerconnection在框架的高層，與應用層最近，需要的改動最少
第三，peerconnection最容易編譯和集成
第四，如果你想要兩個人簡單的直播連麥，peerconnection就足夠了
直播
簡單來說就是一個人發佈自己的直播供別人觀看，可以有一點延遲，重點在服務器的穩定和流量帶寬，CDN的分發。而目前直播技術最簡單成熟的就是基於RTMP的推流拉流，在此我推薦SRS（http://www.chnvideo.com/blog-classic-srs.html），原因很簡單，就是簡單高效穩定開源，文章可參考http://www.cnblogs.com/meetrice/p/5428985.html
連麥
連麥是現在直播中比較高大上的一個功能，可以和主播直接互動，市面上的映客，ME直播可以，一般都是兩個人或三個人之間互動，可以說是爲直播錦上添花，拉近了主播和和粉絲的距離，增加了人氣等等等。
而基於WebRTC的P2P的連麥是比較簡單的，最簡單的思路，主播和粉絲P2P通了之後，主播將兩路視頻或者合成一路直接推送到SRS服務器上，供粉絲觀看即可，連麥者獲取主播視頻本地觀看。多人連麥可需要稍微複雜的服務架構設計和實現，有較大的難度，保證實時和穩定以及質量。
另外連麥模型還可以參考:視頻直播中用戶連麥技術模型與特點分析 http://www.cnblogs.com/oldmanlv/p/5625923.html
WebRTC怎麼了
ancientcc
編程的魅力在於不確定
1 人贊同了該回答
這要看你用的客戶端是什麼。如果你是想用瀏覽器，那webrtc不是好方案。但如果你是用app，可以肯定回答：可以，而且強烈建議你基於webrtc。
爲什麼說對App是完全可行呢？瀏覽器在用的Webrtc其實分兩層，底層是個用C++寫的庫（Native Code），然後上層寫個Javascript封裝，以便供HTML5調用。既然是寫app，那完全不用管上層Js封裝，而且Google在開發Webrtc時已考慮用在app，底層C++庫的API已做得很完善了。
對直播使用場景，很多人是用移動設備，移動設備基本都是用app。而webrtc中的Native Code部分跨平臺特性很好，基本不用改，就能寫出完全跨iOS、Android、Windows平臺的代碼，所以有了iOS/Android app，基本不耗成本Windows上的app就出來了。——當然，如果有人在Windows還是堅持要用瀏覽器，那隻能說在Windoes不得不留有瑕疵。
爲什麼有人一想到webrtc，直觀就認爲只有p2p？我猜是和默認的信令服務器是p2p有關。關於這默認的信令服務器是怎麼個交互流程，我有畫過圖。http://www.libsdl.cn/bbs/forum.php?mod=viewthread&tid=83&extra=page%3D2
根據這個圖，你可以模糊中發現，只要換了信令服務器，就有可能變成直播。而事實也的確是這樣。就像有人說直播時圖像單向就夠了（主播傳向觀衆），而Webrtc是雙向，——只要改信令服務器，立刻就單向了。
爲什麼強烈建議你基於webrtc？對直播系統，難的不是服務器，而是客戶端。客戶端難的地方則主要體現在兩個方面，一是網絡傳輸有關，像偵聽事件，同步主線程和讀線程，穿透；二是流數據有關，像編碼、解碼、回聲消除。而這些正是webrtc幫你解決了。也正因爲如此，現在很多直播系統最早的客戶端其實是以webrtc爲根的，只是後面自個不斷優化，慢慢地變成自個系統而已。——誠然，官方webrtc是有地方不盡如意，但它們不斷更新，就像最近一段時間優化了回聲消除。
編輯於 2017-03-03
WebRTC怎麼用
WebRTC實現了三個API，分別是:
* MediaStream：通過MediaStream的API能夠通過設備的攝像頭及話筒獲得視頻、音頻的同步流
* RTCPeerConnection：RTCPeerConnection是WebRTC用於構建點對點之間穩定、高效的流傳輸的組件
* RTCDataChannel：RTCDataChannel使得瀏覽器之間（點對點）建立一個高吞吐量、低延時的信道，用於傳輸任意數據
摘取鏈接:
視頻直播技術詳解——推流和傳輸, 2016-9-13,七牛雲
WebRTC + 直播 + 連麥 = AnyRTC ?2016-9-5
從無到有開發連麥直播技術點整理-AnyRTC
(非常棒的知乎討論合集)可以用WebRTC來做視頻直播嗎？
如何搭建一個完整的視頻直播系統？
Android IOS WebRTC 音視頻開發總結（五八）– 圖文解說視頻直播原理
使用WebRTC搭建前端視頻聊天室——入門篇,2014-3
影響音頻質量和穩定性的因素到底有哪些呢？2016-7-7
CDN的原理,構架,播放延時(網絡延時\網絡抖動\網絡丟包),連麥短板(多路RTMP流實現/主播端與連麥者P2P,2016)
WebRTC的優缺點,2016-6-28
爲何一直推薦WebRTC？