目錄
前言
WebRtc有兩種含義，其一是Google開源的流媒體實時通訊客戶端，主要運用於瀏覽器之間的實時通訊，當然也可以通過提取完成移動端，PC端的通訊;另外WebRtc也是一套規範，這套規範只對客戶端做了定義，如客戶端應該是一種什麼行爲，應該是一種什麼樣的流程，如何進行媒體協商，，如何進行通訊，這些是在規範中進行定義的。
相對於服務端來講包括信令或者中繼服務端並沒有規範的定義，這個是由使用WebRtc各個廠商自己去定義的，對於多人實時互動的服務端也是沒有規範的定義。那麼實現多人實時互動通訊目前有3種比較流行的框架，具體請移至 【多人音視頻架構 】閱讀。
在瞭解完各個音視頻架構過後，對比當前主流的流媒體服務器 - Licode、Janus、Medooze、Mediasoup。在後續博文中筆者會對MedouSoup進行詳細的分析，後面會對這四種流媒體服務器進行比較，當然只是純粹的比較不分好壞，具體還要根據各大廠商或者研發人員鍾愛於哪一套有。比較流媒體服務器章節請移至【流媒體服務器的比較】閱讀。
Mediasoup官網：https://mediasoup.org
Mediasoup官方演示：https://v3demo.mediasoup.org
Demo git地址及部署說明：https://github.com/versatica/mediasoup-demo
多人音視頻架構
Mesh方案
由WebRtc客戶端演變過來的，那麼對於Goggle主要實現P2P或者說端與端的通訊，而且是在瀏覽器之間，如果想讓多人進行通訊，那麼就是是多個一對一的通信，比如ABC三者通訊，那麼A和B，C相連，B也要和A，C相連，C也是如此，形成一個交叉的連接，這樣就可以實現多方的通訊。
但其存在一些弊端，弊端在於如果參與人數過多，每個端都要有很多鏈接，如果網絡無法保障的話那麼會出現很大的問題或者帶寬有限，鏈接過多帶寬會不足，目前商用暫時基本不用Mesh方案。
MCU（Multipoint Conferencing Unit）方案
其是由硬件演變而來的,由於硬件MCU成本過高那麼就想着通過軟件方式去實現，於是有了現在MCU方案，,MCU可以提供更多擴展性的功能實現，且降低了帶寬。
當然其也存在一些弊端，主要有2個弊端，其一是當有多個用戶通過MCU進行實時互動，首先要多個音視頻進行混合，好處在於把整個帶寬降低了，每個人都只發一路，但服務端CPU編解碼壓力過大，如果會議越多會導致CPU過渡負載，因此支持的人數或者會議室極其有限。其次是當混合完的音視頻數據發送給客戶端，客戶端沒辦法控制一些數據的參數如視頻的大小位置等。
SFU (Selective Forwarding Unit)方案
純粹的數據轉發，那麼轉發到對端之後可以接收到多人的數據，對數據進行做各種控制或者操作但是帶了一個壞處，相對於MCU來說數據是多路流多來，接收端來說接收的流也多了，如果傳輸的音視頻是 採樣率大或者高清視頻，那麼客戶端與服務端之間帶寬不夠的話會導致大量的丟包並影響一些音視頻的質量；但SFU也有一系列的配套方案來解決這個問題，如降碼率、SVC分層方式（核心層，拓展層，邊緣層）根據帶寬來傳輸不同層的數據。
隨着網絡帶寬不斷得加強，設置的質量越來越高，因此相對於SFU的優劣勢來說，SFU更受歡迎。
流媒體服務器的比較
這裏只針對MediaSoup流媒體服務器詳解，其餘看個大體結構並簡單說明
相關介紹 :
Licode整體框架還是非常不錯，但是過於重量型。包括很多功能很完善，但是對於一些定製一些業務需求的時候相對於會比較困難一些。
相關介紹 :
janus通過插件的形式完成各個業務，整個框架也是非常不錯的，從整個模型來講，可以滿足一些定製需求的修改。
上面這張圖是 Janus 的整體架構圖。在這張圖中我們可以看到， 從大的方面說 Janus 由 Janus CORE、Janus Plugin 以及信令接口三部分組成。
- 信令接口，Janus 支持的信令協議比較多，如 HTTP、WebSocket、RabbitMQ 等。這些信令協議使得 Janus 具有非常好的接入性。因爲很多公司喜歡各種不同的協議，如有的喜歡 websocket，有的喜歡http，proto等。因此 Janus 在信令接入方面具有很大的優勢。
- Janus Plugin，Janus 的業務管理是按照 Plugin 的方式管理的，因此你可以在Janus中根據自己的需要實現自己的業務插件。實際上，對於一般性的需求 Janus 已經相關的插件。如：
- VideoRoom，用於多人音視頻互動，像音視頻會議，在線教育都可以通過該插件來實現。
- VideoCall，用於 1:1 的音視頻通信。
- SIP，用於與傳統電話設備對接。
- Streaming，用於廣播，也就是我們通常所說的一人共享，多人觀看的直播模式。
- TextRoom，它是一個聊天室，通過它可以進行文本聊天。
- RecordPlay，用於錄製和回放。
- Janus Core 是Janus的核心，其作用是處理流的轉發，各種協議的接入。以瀏覽器爲例，要想讓瀏覽器接入到 WebRTC 流媒體服務器上，那流媒體服務器必須要支持 STUN、DTLS、SRTP、ICE 等協議。而 Janus Core 就是專門做這事兒的。
Janus 是由 C語言開發的，因此它的性能非常優秀。要說不足的話，janus 底層沒有使用 epoll 這類異步I/O事件處理機制，這應該說是它的一大缺陷；另外，Janus還使用 glib 庫，由於 glib 庫對於國內的很多開發同學來說用的比較少，所以會有一定的學習成本。
整體上看，Janus採用了插件的架構設計方案。這種方案非常適合於有多種業務模型或業務經常發生變化的公司或項目。另外 Janus 支持多種消息傳輸協議，這對於開發人員來說具有極大的吸引力。
Medooze 的整體架構與 Mediasoup 類似，不過它的信令處理、業務管理以及媒體數據的轉發功能都是放在 Nodejs下進行統一管理的。實際上，這樣的管理方式也不會對性能造成什麼影響，因爲重的媒體流的轉發工作仍然是使用的 C++ 在 Nodejs 底層實現的。
Medooze 的業務功能要比 Mediasoup 強大，像服務端錄製、推流這些 Mediasoup 沒有的功能它都支持。但它性能沒有 Mediasoup 做的極致，在Medooze的底層使用的poll來處理I/O事件，poll與epoll性能相差距大。除此之外，Medooze的業務邏輯也沒有Mediasoup簡潔；另外與 Janus 相比，它的業務管理不如 Janus 靈活，Janus 的插件管理方式顯然要優於 Medooze 和 mediasoup。
但總的來說，Medooze還是一款非常不錯的 WebRTC 流媒體服務器。雖然有一些小的暇疵，但還是非常不錯的一款流媒體服務器。
Mediasoup流媒體服務器架構及特點
Mediasoup也是一個SFU的架構模型，他與Medooze非常的類似，都是通過nodeJs來實現信令的服務，媒體部分的處理 音頻視頻流實際是在C++程序處理的，node和C++通過管道進行通訊。其客戶端機制基本一樣。對於MediaSoup來說它的nodeJs只起到兩個作用，其一是www服務 也就是執行客戶端的啓動代碼，它在www服務上，其次是客戶端和服務端的https連接，通過連接來達到信令的通訊。
- Nodejs，負責 Mediasoup 的信令接收與業務管理。如創建/消毀房間，創建/關閉生產者，創建/關閉消費者等。
- Mediasoup(C++)，這是一個單獨的程序，但該程序無法直接啓動。因爲它在內部會判斷是否是 Nodejs 將它啓動起來了。只有在Nodejs 的 Mediasoup 管理模塊加載之後，再將 Mediasoup(C++)啓動起來，這樣它才能正常工作。
Mediasoup其實底層是一個庫，其實可以根據自身的需求去開發，當然官方也提供了一個demo，可以實現多人的實時互動，如果要實現商用的多人實時互動，其實是需要自己去重構這部分的邏輯。通過底層流媒體庫來搭建自己想要的服務器。
從整個架構模型來講，設計得合理，整體性能相對來說比較高,底層C++更是使用使用libuv處理I/O時間，而且它是一個庫，可以容易和自己的業務模型相結合，即不輕量級也不重量級。但整體的應用來說不及licode。