提醒：本文最後更新於 1349 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

連續寫了兩篇有關視訊直播的文章之後，有同學問我為什麼沒有 WebRTC 相關內容。實際上一開始我就說過，我的需求是在移動 WEB 端上直播視訊，而移動端瀏覽器現階段對「WebRTC 的支援度」非常不樂觀，所以我就直接無視它了。但我一時為了標題美觀，活生生地把「移動 WEB 端」寫成了「HTML5」，所以為了嚴謹我還是補上這一篇吧。

WebRTC（Web Real-Time Communication），中文一般翻譯為「Web 實時通訊」。它由一組標準、協議和 JavaScript API 組成，用於實現端到端的音視訊及資料共享。與其他瀏覽器通訊機制不同，WebRTC 通過 UDP 傳輸資料，而我們早已熟知的 XMLHttpRequest、WebSocket 都基於 TCP。

縱觀整個瀏覽器市場，其實只有 Google 和 Mozilla 兩家公司對 WebRTC 比較上心，Firefox 22 和 Chrome 23 就開始就支援了它；Microsoft 是搞了自己的一套標準，後續可能會跟 WebRTC 融合，但至少 IE 不會支援現階段的 WebRTC 標準；Apple 也許是因為有 FaceTime 可以很好地實現 Apple 裝置間的多媒體通訊，壓根就沒打算在 Safari 中增加對 WebRTC 的支援；至於 Opera，換核心後基本等同於 Chrome，這下更要被人無視了。

初識 WebRTC

WebRTC 涉及到很多複雜技術，不過好在瀏覽器已經把大多數複雜工作抽象成為下面三個 API：

• MediaStream：獲取音訊和視訊流；
• RTCPeerConnection：音訊和視訊資料通訊；
• RTCDataChannel：任意應用資料通訊；

MediaStream 對應的是 JS 裡的 navigator.getUserMedia() 方法，它負責從底層平臺獲取音視訊流。音視訊流經過 WebRTC 音視訊引擎的自動優化、編碼和解碼，就可以直接用或傳輸到各種目的地用。這裡有個 Demo，就是用 getUserMedia 獲取視訊流，再把每一幀都轉成 ASCII 字元播放。總之 MediaStream API 設計得很簡單，使用起來也很方便。

RTCPeerConnection

首先，要建立端到端連線，不可避免要解決 NAT 穿透問題，RTCPeerConnection 為此引入了 ICE（Interactive Connectivity Establishment）框架。ICE 致力於在端之間建立一條有效的通道，優先直連，其次用 STUN 協商，再不行只能用 TURN 轉發。

STUN（Session Traversal Utilities for NAT）協議，解決了三個問題：1）獲得外網 IP 和埠；2）在 NAT 中建立路由條目，繫結外網埠，使得到達外網 IP 和埠的入站分組能找到應用程式，不被丟棄；3）定義了一個簡單的 keep-alive 機制，保證 NAT 路由條目不會因為超時而被刪除。STUN 伺服器必須架設在公網上，可以自己搭建，也可以使用第三方提供的公開服務，例如 Google 的「stun:stun.l.google.com:19302」。

TURN（Traversal Using Relays around NAT）協議，依賴外網中繼裝置在兩端之間傳遞資料。簡單說就是通過兩端都可以訪問的 TURN 服務轉發訊息，間接把兩端連起來。TURN 還會嘗試使用 TCP 建立，而不僅僅是 UDP，可靠性大大增強，頻寬成本也隨著大幅提升。根據 Google 的統計，UDP 服務中，有 8% 左右的情況下需要 TURN。

其次，要建立端到端的通道，還是需要藉助服務端來交換和協商一些資訊，這個過程被稱之為 Signaling。WebRTC 並沒有規則 Signaling 必須使用某種協議，而把選擇權交給了應用程式。我們可以選用不同方式（XMLHttpRequest、WebSocket），採用已有的 SIP、Jingle、ISUP 等發信協議，來建立通道。

通常，在 WebRTC 應用中，建立通道這一步都是優先走 WebSocket，並支援降級為 HTTP。一來支援 WebRTC 的瀏覽器肯定都支援 WebSocket；二來 WebSocket 實時性更好一些。特別需要注意的是，WebSocket 只用來輔助建立端到端連線，一旦連線建立，信源在端到端之間的傳輸就完全不需要服務端了（當然 TURN 這種中繼模式就另當別論）。

RTCDataChannel 用來支援端到端的任意應用資料交換。建立 RTCPeerConnection 連線之後，除了可以傳輸音視訊流，還可以開啟一個或多個通道用來傳輸任何文字或二進位制內容，這就是 RTCDataChanel。DataChannel API 在使用上跟 WebSocket 非常類似，功能上都可以用來在端到端之間傳輸資料，但是本質上他們還是有區別的：

首先，WebRTC 端與端之間是對等的，DataChannel 可以由任何一方發起；這與 WebSocket 連線只能由客戶端發起不同； 其次，WebSocket 的會話層協議 TLS 是可選的；而 WebRTC 的會話層協議 DTLS 是必須的，這表明通過 WebRTC 傳輸的資料一定會被加密； 再者，WebSocket 執行在 TCP 之上，每條訊息天然有序並可靠；而 DataChannel 可以通過 SCTP 的交付屬性選項來指定訊息是有序還是亂序，是可靠還是部分可靠，部分可靠時還可以指定使用超時重傳還是計數重傳策略。

現階段 DataChannel 執行在下列協議之上：

• SCTP（Stream Control Transmission Protocol），流控制傳輸協議，提供了一些與 TCP 類似的特性；
• DTLS（Datagram Transport Layer Security），傳輸內容加密，UDP 版的 TLS；
• UDP（User Datagram Protocol），使用者資料報協議，整個 WebRTC 的基礎；

這裡我並不打算完整地介紹如何從零開始使用 WebRTC，類似的文章網上大把。這裡推薦幾篇文章，後幾篇中文的出自同一個作者，寫得比較通俗易懂：

另外還推薦《Web 效能權威指南》這本書，它的第 3 章「UDP 的構成」和第 18 章「WebRTC」對 UDP 內網穿透和 WebRTC 有比較詳細的介紹。

一對多直播

前面說過，WebRTC 是用來解決端到端的實時通訊問題，也就是說它很適合用在網路電話這種需要雙向視訊通話的場景上。網上大部分 WebRTC 的 Demo 也都是在頁面上放兩個 Video，分別來播 localStream 和 RemoteStream。那麼究竟 WebRTC 能否用來實現單向一對多直播呢？當然可以，而且貌似還很簡單：

• 首先必須有一個專門負責呼叫 getUserMedia 採集音視訊的頁面，我稱之為信源服務；
• 開啟直播頁面時，建立到信源服務的 PeerConnection，並通過 DataChannel 通知信源服務；
• 信源服務收到通知後，通過對應 PeerConnection 的 addStream 方法提供直播流；
• 直播頁面監聽 PeerConnection 的 onaddstream 事件，將獲得的直播流用丟給 Video 播放；

為了方便，我使用了 PeerJS 這個開源專案來驗證上面這個過程。PeerJS 對 WebRTC Api 進行了封裝，使用更簡單。它還提供了用來輔助建立連線的 Signaling 服務，在官網註冊一個 Api Key 就能用。也可以通過 PeerJS Server 搭建自己的服務，只需要通過 npm install peer 裝好 peer 後，再通過下面這行命令啟動就可以了：

peerjs --port 9000 --key peerjs

啟動好 Peer Server，在頁面中引入 peer.js 就可以開始玩了。首先實現信源服務：

//由於其它端都要連它，指定一個固定的 ID
var peer = new Peer('Server', {
    host: 'qgy18.qgy18.com', 
    port: 9003, 
    path: '/',
    config: {
        'iceServers': [
              { url: 'stun:stun.l.google.com:19302' }
        ]
    }
});

navigator.getUserMedia({ audio: false, video: true }, function(stream) {
    window.stream = stream;
}, function() { /*...*/ });

peer.on('connection', function(conn) {
    conn.on('data', function(clientId){
        var call = peer.call(clientId, window.stream);

        call.on('close', function() { /*...*/ });
    });
});

然後就是直播服務：

//隨機生成一個 ID
var clientId = (+new Date).toString(36) + '_' + (Math.random().toString()).split('.')[1];

var peer = new Peer(clientId, {
    host: 'qgy18.qgy18.com', 
    port: 9003, 
    path: '/',
    config: {
        'iceServers': [
              { url: 'stun:stun.l.google.com:19302' }
        ]
    }
});

var conn = peer.connect('Server');

conn.on('open', function() {
    conn.send(clientId);
});

peer.on('call', function(call) {
    call.answer();
    call.on('stream', function(remoteStream) {
        var video = document.getElementById('video');
        video.src = window.URL.createObjectURL(remoteStream);
    });

    call.on('close', function() { /*...*/ });
});

直播頁面通過指定 ID 的方式跟信源服務建立端到端連線，然後通過 DataChannel 告訴信源服務自己的 ID，信源服務收到訊息後，主動把直播流發過來，直播頁面應答後播放就可以了。整個過程原理就這麼簡單，這裡有一個「完整的 Demo」。

看完上面的 Demo，你也許會想原來使用 WebRTC 直播這麼簡單，隨便找臺帶攝像頭的電腦，開個瀏覽器就能提供直播服務，那還搞 HLS、RTMP 什麼的幹嘛。

實際上，現實並沒有那麼美好，這個 Demo 也就玩玩兒還可以，真正使用起來問題還大著呢！

首先，雖然說在 WebRTC 直播方案中，服務端只扮演橋樑的工作，實際資料傳輸直接發生在端到端之間，但前面說過仍然會有 8% 的情況完全不能直連。要保證服務的高可用性，還是得考慮部署 TURN 這種複雜而昂貴的中轉服務。

其次，Chrome 對每個 Tab 允許連線的終端數有限制，最多 256 個。實際上，在我最新的 Retina Macbook Pro 上，差不多有 10 個連線時，Chrome 就開始變得無比卡，風扇呼呼地轉，記憶體被吃掉 6G，CPU 一直跑滿，網路吞吐開始忙不過來，直播服務也開始變得極其不穩定。

所以實際使用方案中，一般還是需要 Media Server 的支援，把「端到多端」變成「端到 Media Server 到多端」的架構。Media Server 可以有更好的效能和頻寬，可以自己實現 WebRTC 協議，也就有了支援更多使用者的可能。

我找到一個名為 Janus 的 WebRTC Gateway，這個開源專案用 C 語言實現了對 WebRTC 的支援。Janus 自身實現得很簡單，提供外掛機制來支援不同的業務邏輯，配合官方自帶外掛就可以用來實現高效的 Media Server 服務。

Janus 官方提供的 Demo 在這裡，我也嘗試在我的 VPS 上部署了一套。Janus 有個 Streaming 外掛，可以接受 GStreamer 推送的音視訊流，然後通過 PeerConnection 推送給所有的使用者。由於 GStreamer 可以直接讀攝像頭，也就不用再走 WebRTC 的 MediaStream 獲取視訊，這樣架構就變成了傳統的伺服器到端了。整個過程比較複雜和曲折，這裡不寫了，有興趣的同學可以單獨找我討論。

--EOF--

發表於 2015-05-01 00:22:07 ，並被新增「 HTML5 、 Video 」標籤 ，最後修改於 2015-05-02 17:28:00 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 1349 天前，文中所描述的資訊可能已發生改變，請謹慎使用。