大家好，我是李橋平，來自學霸君上海互動產品研發中心，本次分享的主題是Janus網關的集成與優化。Janus網關是WebRTC的媒體服務器，它可以接收來自WebRTC客戶端的音視頻數據，根據業務需要對媒體數據進行處理，再轉發到其他WebRTC客戶端上, 以此完成音視頻互動。
本次分享的主要內容是如何把Janus網關集成到我們公司內部的自研RTC系統中，并對其做了一些優化，在集成之后就可以通過瀏覽器和客戶端進行實時互動了。
1 背景介紹
背景介紹主要從三個方面來進行切入，分別是：業務場景、自研RTC體系以及為何要做集成。
1.1 業務場景
我們所做的業務是一個多人在線實時互動的教育場景，基本需求是老師和學生之間能夠進行音視頻實時互動。除了音視頻之外，還需要有一些其他的輔助教學內容，也需要進行實時的交互，比如老師和學生的手寫筆跡、PPT課件、控制的狀態（課件翻頁）等。為了滿足這些功能，從技術上分解來看，首先需要支持多對多的音視頻連麥，其次是課件、手寫筆跡的實時同步。
1.2 自研RTC體系
為了實現這些功能，在袁榮喜老哥的帶領下, 我們開發了自己的RTC系統。自研RTC系統主要包含服務端和客戶端兩大塊，它們都是通過自研實現的(語音處理借助了WebRTC的APM模塊)。客戶端和服務器之間使用UDP協議來進行媒體通信, 數據包采用的是私有格式, 在此基礎之上完成傳輸的控制, 比如數據包排序重組, FEC, 丟包重傳, 主動Get以及擁塞控制等. 整個體系以客戶端的形式提供給用戶，支持windows、Android/ target=_blank class=infotextkey>安卓、mac、IOS這幾個主流平臺，在使用之前需要下載客戶端。
1.3 為何要做集成
我們主要是從用戶接入的易用性來考慮的. 首先是我們的客戶端需要用戶自己去下載，安裝成本是比較高，然后才是注冊賬號、登錄這些步驟。而WebRTC可以在瀏覽器上運行， 而大部分用戶對于瀏覽器是非常熟悉的. 其次, WebRTC的功能通過JS API進行調用，天然跨平臺, 不需要過多的考慮設備兼容性這些問題, 它們都封裝在WebRTC內部了。
通過集成，用戶可以通過瀏覽器來接入我們的產品，對于沒有使用過我們產品的用戶來說, 它提供了一種更加便捷的方式。
上圖是完成集成后的一個效果，左圖是瀏覽器，登錄的是學生端。右圖的窗口是我們PC上的客戶端，登錄的是老師。老師和學生可以進行實時的視頻互動，同時還可以通過PPT課件和手寫筆跡來輔助課堂教學。
2 WebRTC與Janus網關
WebRTC與Janus網關部分包含三個小節：首先是P2P傳輸通道的建立，介紹WebRTC的媒體傳輸是如何建立起來的，其次是介紹WebRTC網關以及Janus網關。
2.1 P2P傳輸通道的建立
P2P是指通信的內容可以不經過服務器, 直接發送給對方，省去了中間服務器的開銷。WebRTC的P2P傳輸底層采用的是UDP協議，從傳輸特性上說，它是無連接、不可靠的協議。當然，WebRTC在進行傳輸時會有比如包確認、包重傳等措施來彌補這些問題。
圖中下方是兩臺需要進行音視頻互動的電腦，電腦中的五色圓圈圖案是WebRTC的logo，表示這個電腦上運行的WebRTC的客戶端，這種客戶端最常見的就是瀏覽器了。實際上只要實現WebRTC的模塊功能，它們都可以進行音視頻的會話，比如WebRTC網關就實現了WebRTC模塊的功能，這里認為這兩臺電腦上運行了支持WebRTC的瀏覽器就可以了。這兩個瀏覽器要進行音視頻互動至少需要兩方面的信息：一是雙方采用怎樣的音視頻編解碼以及相應的編解碼參數，比如采樣率、分辨率、幀率等參數。二是使用UDP發送數據需要知道對方UDP的地址信息，主要包括IP地址和端口。要交換獲取這兩方面的信息的話, 需要借助到一個位于外網的服務器，我們稱之為信令服務器。
接下來我們來分析一下連接建立的過程. 首先，左邊瀏覽器發起一個SDP offer的請求，在SDP中攜帶了它支持的音視頻編解碼和ICE參數。這里引入了兩個概念：SDP和ICE。SDP(Session Description Protocol)是會話描述協議，這里只需知道它封裝了協商的參數就可以了。ICE(Interactive Connectivity Establishment)是互動連接建立，它負責UDP下媒體會話的建立. 在ICE參數里包含了UDP的地址信息(訪問外網的NAT地址需要借助STUN服務, 為了簡單起見, 可以先不考慮)以及建立ICE連接所需要的用戶名跟密碼。
右邊的瀏覽器在接收到SDP offer工作請求以后，會根據自己所支持的編碼器情況進行匹配和篩選，然后生成SDP answer作為響應，通過信令服務器中轉返回給左邊的瀏覽器，這樣雙方就完成了SDP的協商和交換。
在交換了SDP之后, 雙方通信需要的信息都完備了. 隨后這兩個瀏覽器會分別初始化好各自的音視頻設備，比如麥克風、攝像頭設備。然后根據協商好的編解碼, 初始化編解碼器. 于此同時， 它們會向對方發送ICE建立請求的消息，該消息會帶上雙方協商好的ICE參數，主要是攜帶用戶名和密碼的信息(后面的單端口改造借助了這里的用戶名字段)。在完成ICE的請求交換后進行握手認證，這樣就建立起了ICE的連接，雙方隨后以P2P的方式通過ICE連接發送編碼后的媒體數據。
直接將媒體數據發送給對方的這種形式被稱之為P2P直連，這種方式看似很好，因為它中間不需要經過服務器，但在一些情況下會有問題。
首先，一般的設備都沒有公網IP地址，在訪問外網時需要經過路由器，路由器上的NAT轉換會分配相應的外網地址，再進行設備到外網的訪問工作. 這時路由器上的NAT策略直接影響到ICE連接是否能夠建立起來。整個過程涉及到UDP穿透問題，比如在對稱型、限制型錐形NAT上，穿透是很難完成的。
其次，在P2P直連的方式下，中間鏈路我們無法控制，因此傳輸質量難以保證。假設圖中這兩臺電腦，一個位于電信，一個位于網通，即使它們能夠完成UDP的穿透，它們之間的傳輸延遲大概率也是很高的。
最后，因為數據不經過服務器，行為監管和媒體錄制都難以實現,, 尤其對教育行業來講，行為監管這塊是一個必不可少的需求。
2.2 WebRTC網關架構
這是WebRTC網關的架構圖。通常情況下我們將WebRTC網關部署到外網，這兩個瀏覽器分別通過NAT連接到網關，并通過網關來轉發相應的媒體數據。網關上的WebRTC logo表示在網關上實現了WebRTC模塊的功能. 因此它可以和瀏覽器上的WebRTC模塊進行通信。瀏覽器和WebRTC網關之間的紅色箭頭表示信令消息的交互，綠色箭頭表示媒體消息。
下面來看看關于上個小節中的幾個問題在WebRTC網關上是如何解決的。
首先穿透問題，因為WebRTC網關是部署到外網的，瀏覽器通過內網去訪問外網. 只要能夠正常上網，訪問外網是沒有問題的，因此不會有穿透失敗的問題, 同時也可以省去STUN服務.
其次是聯通到電信的情況，可以把WebRTC網關部署到BGP的多線機房, 電信和聯通到BGP的延遲可以做到很低，通過一個中轉，整體的中轉質量反而比P2P直連質量更好。
最后是監管和錄制，因為媒體數據會經過WebRTC網關，可以方便地在網關上進行錄制，同時也可以在網關上針對媒體內容進行相應的數據分析，實現對其監管的功能。
在討論WebRTC網關時，一般會根據網關對媒體消息的處理方式劃分為兩類：SFU和MCU。
SFU在收到媒體數據以后，不會對媒體數據本身進行處理，只做一些基本處理(SSRC, timestamp等轉換)和轉發。左圖是SFU的示意圖，不同顏色所表示的媒體數據在進入SFU之后，它是以原來的形態發送到其他瀏覽器上的。
右圖是MCU的示意圖，媒體數據在進入MCU以后，MCU會對媒體內容進行深度處理，比如把多路的聲音合并成一路或者把多路的頭像合并成一個大頭像，再根據需要做轉碼，并轉發到其他瀏覽器上。合流的一個好處是可以節省相應的帶寬，同時可以在發送媒體數據的時候, 根據瀏覽器所支持的編解碼情況進行轉碼，因此它的適應性會比較好。
2.3 Janus網關
Janus網關是SFU. 它是用C語言來實現的。其次, 在Janus上，業務模塊以插件的形式實現，部署是以SO動態庫的形式進行部署的，所以它的主程序和插件開發是一個分離的方式。最后，Janus Demo非常簡單直觀，很容易上手。
接下來這部分介紹Janus網關的軟件架構。從層級上分析，Janus網關主要分為三層，從上至下分別是插件層、核心層和傳輸層。
插件層主要是決定SFU的轉發邏輯，比如決定轉發給房間里面的所有人，還是只轉發給其中的一部分人，是轉發音頻或者視頻，還是音視頻同時轉發。一個完整的插件方案，除了Janus網關服務器上的插件實現之外，還包括瀏覽器上的JS SDK。JS SDK處理的邏輯主要包括進出房間、訂閱相應的媒體流等. 除此之外, 調用WebRTC的API獲取麥克風和攝像頭的數據，還有播放音頻和視頻數據，都是通過JS SDK來完成的。
核心層主要負責SDP的協商以及ICE連接的建立，UDP媒體數據的接收和轉發也在核心層里完成。而插件和JS SDK的通信使用的是TCP協議, 它是通過傳輸層來完成的.
傳輸層主要負責在JS SDK和網關之間傳輸控制數據, 插件自定義消息等。傳輸層支持多種常見的傳輸協議，比如HTTP、WebSoket等。
3 Janus與自研RTC的集成
第三部分是Janus與自研RTC的集成，主要包含三個小節，分別是系統架構、音視頻互通、集成效果。
3.1 系統架構
這張圖片是高度簡化后的結果，像自研RTC集群里的媒體調度、負載均衡、線性擴展等內容都沒有在這里表達出來，主要是希望能突出與集成相關的內容。圖中大致包含三個部分：自研RTC系統、Janus網關以及中間綠色箭頭代表的媒體通道。
我們按上圖從左至右, 來看一下通信流程。
首先是用戶A通過任意一個平臺的客戶端連接到自研RTC集群，通過中間的媒體通道，間接地和連接到網關上的瀏覽器用戶B進行音視頻互動。在Janus網關和瀏覽器用戶B之間主要傳輸RTP格式的音視頻數據和自定義格式的筆跡數據。其中的音視頻數據走的是P2P的傳輸通道，筆跡數據走的是WebSocket通道。整個集成核心的部分是位于Janus網關和自研RTC集群中間的綠色箭頭所代表的音視頻轉換，更具體的來說， 就是自定義封裝格式和RTP封裝格式的轉換。
前面介紹P2P媒體傳輸通道時提到RTP最終是通過UDP的傳輸協議發送出去的。
為了避免IP分片, 發送的UDP包不能太大， 具體一點是不能超過路徑上MTU的限制，一般來說，以太網上的MTU的最大限制是1500個字節。實際過程中需要除去IP協議頭和UDP協議頭開銷，剩下大概也就1400多個字節, 因此RTP包不能超過這個限制, 這個限制會影響到RTP的封包過程。
3.2 音視頻互通
在我們的系統中音頻采用Opus編碼，視頻采用H.264編碼，WebRTC(主要是Chrome瀏覽器)也支持這兩種編碼，因此不需要在網關上進行轉碼了。
圖中展示的是音頻數據的轉換, 包含了音頻數據從采集到封裝成RTP的過程。從上往下, 首先是聲卡采集到PCM數據，一般是按10毫秒或者20毫秒這種固定長度進行組織. 經過Opus編碼器, 根據PCM數據的內容特征, 編碼成長度不一樣的編碼數據. 編碼后的音視頻數據一般是幾十到幾百個字節左右。這樣的數據量可以直接在單個RTP包中進行攜帶，因此聲音的RTP封裝非常簡單，只需要在數據的前面追加上RTP頭部就行。
RTP頭部中主要的兩個字段是sequence number和timestamp, 即序列號和時間戳。因為UDP傳輸是一個不可靠的協議，在傳輸的過程中可能會發生丟包或者亂序到達。序列號可以幫助接收端正確地組織接收到的數據， 根據序號的缺失情況可以知道哪些數據包丟失，根據丟失包的序號可以要求發送端進行重傳，從而保證傳輸質量。時間戳主要是輔助播放端進行聲音的同步播放。
整個過程倒過來看，就是如何從瀏覽器發過來的RTP數據中提取編碼數據的過程。在提取出編碼數據以后就可以封裝成自研RTC格式，通過自研RTC集群再轉發到客戶端上，并在客戶端上進行播放。
接下來是視頻的轉換。
H.264視頻轉換在RFC6184文檔里有詳細的規定和說明。相對于音頻來說，視頻轉換要復雜一些，這是因為圖像數據編碼后，它的數據幀往往比較大，會超過RTP包的大小限制。
該圖是視頻數據轉換成RTP包的示意圖。還是從上往下看，首先攝像頭采集原始的視頻圖像，一般是YUV格式的，經過H.264編碼后生成H.264的數據幀。數據幀本身是有內部結構的，它包含一個起始碼，后面跟著NAL單元，由多個這樣的結構組成編碼后的數據幀，在轉換的過程中，第一步是要把起始碼去掉，再提取出單個的NAL單元數據。然后根據NAL單元數據能否封裝到單個RTP包中，分別封裝成三種不同的封裝格式。
圖中左邊是單個NAL單元的封裝， 在NAL單元比較小的情況下使用. 中間是單元片段的封裝， 在單個NAL單元大小超過RTP包限制的情況下，采用該封裝格式。
右邊是多個NAL單元聚集到一個RTP包的封裝過程，這里主要針對NAL單元很小，RTP包可以同時攜帶多個NAL單元的情況，封裝到一個包里，可以減少發包的數量。同樣，封包過程需要正確的填充RTP頭部的時間戳和序列號。
整個圖從下往上看，就是從RTP數據流中提取出來H.264編碼數據的過程，完成提取后再封裝成自研RTC系統的格式，發送到客戶端上進行數據的還原，再經過H.264解碼器的解碼，得到原始的視頻數據并在界面上渲染出來.
3.3 集成效果
這個測試主要是想知道中間轉換部分的開銷, 因此這里不考慮客戶兩端到服務器的弱網情況. 首先是穩定WiFi，到服務器RTT是30毫秒，視頻分辨率是320×240，幀率是20幀。整個過程下來音視頻流暢，媒體延遲小于100毫秒。
測試方法借助了一個在線秒表的時間跳動的畫面，虛擬攝像頭采集在線秒表的動畫，通過PC端進行編碼，然后上傳到自研RTC服務器, 轉換成RTP格式, 通過RUDP通道傳輸到Janus網關, 再通過網關發送到瀏覽器上還原出視頻畫面。對比PC端和Web端看到的視頻畫面，就可以得出他們觀看的時間差。
圖中可以看出PC客戶端的畫面時間和Web的畫面時間相差大概幾十個毫秒。由于PC端有一些相應的處理(如美顏)，而且存在渲染的時間消耗, 實際的差值會比這個大一些, 整體的時間延遲估計是100毫秒左右，效果還是不錯的。
4 Janus網關優化
這部分我會從現象入手，介紹集成過程中所做的一些優化，這里主要介紹CPU優化和端口優化。
首先在CPU方面，在測試時我們發現，在同一個房間里進入12個人，八個人開麥進行音視頻互動的話，Janus近程的CPU大概占到30%多。如果是一個四核的CPU, 算打到300%的話，也只能支撐120多個人，這樣的話承受能力會非常有限。因此需要對CPU進行優化。
其次是端口，Janus在服務部署的過程中需要開放大量的端口. 這是因為Janus對于每一路上傳和每一路觀看都需要為它分配一個外網端口。分配過多的端口不管從安全管理上還是運維部署上都會帶來不便。在我們實驗室實際開發過程中就遇到過，當同時開3、4個視頻時，整個視頻的數據下發不來, Web上看到的畫面是黑的. 經過找相應的IT人員一起定位分析后，發現是辦公室交換機出口對UDP訪問端口做了限制導致的，因為每一路視頻上傳下載都需要分配端口, 在交換機策略看來, 多個內網的機器訪問了同一個外網IP(janus網關的IP)的大量不同端口, 被判定是異常狀態了。因此，不管從安全性、運維部署，還是服務質量上來講，最好是用少量的端口來完成同樣的事情。
4.1 CPU優化
這部分介紹針對上述兩個問題的分析和相應的解決方法。CPU問題的原因主要有3個：一是SFU的轉發關系復雜度為M*N，其中M是上麥人數，N是房間內的總人數。假設房間里有100個人，其中10個人上麥，那么轉發的復雜度就是10×100，因為對每一路上傳的視頻都需要轉給其他99個人，一路上傳加上99路轉發就是100處理量，10個人就是1000。
二是對于每一路上傳和轉發，Janus都分配一個對應的UDP端口和socket描述符，該分配行為是Janus所使用的網絡庫Libnice決定的。
三是Libnice的內部采用poll做事件處理，在描述符量很大時，它的效率很低。因為poll在調用時, 需要把所有描述符以數組的形式傳遞到內核, 內核需要對每個描述符進行查詢處理，并且還要注冊相應的事件監聽。如果當前這次調用沒有收集到任何事件的話, 它會進行等待, 在等待過程中, 它會把當前線程注冊到所有描述符的通知等待隊列里，然后被動等待相應事件的喚醒。在事件到達喚醒后, 返回的過程中又需要把當前線程移出所有描述符的等待隊列，這其中涉及到大量鎖操作。以上三個原因疊加起來，就造成了高CPU的情況。
CPU優化的對策主要是從兩方面入手: 減少端口的使用, 以及把glib內的poll調用改為epoll。
在使用上，端口的問題的使用可以采用以下一些辦法來緩解：
一是通過ice_enforce_list限定ICE收集candidate的網卡。默認情況下，Janus會對所有的網卡都做端口收集。我們在開發的過程中所部署的機子上正好有兩個網卡，測試時發現，它所收集的端口數量比單網卡下多了一倍，在開啟這個的配置后，數據數量立馬減半，CPU也降低了很多。
二是確保Janus服務配置中， ice_tcp=false。這是在使用TCP穿透時所需要收集的端口，在實際應用中很少用到，所以將其設置為“false”禁止掉就可以。
其次，把glib內的poll調用改為epoll. 可以采用兩種方式 ：一是修改glib代碼，把事件處理的poll調用替換成epoll. 這種方式需要把glib代碼拉下來修改并測試，整個工作需要比較長的時間；二是采用github上第三方的擴展實現 。
4.2 端口優化
對于端口優化，我們采用了端口復用方案. 實現端口復用的情況下, 可以做到減少端口使用, 同時降低CPU使用率。具體的方法如下, 首先在Janus上接管ICE的處理，通過SDP中的ICE用戶名參數來識別發送端身份。在上文提到的P2P連接建立的過程中，首先要經歷ICE認證的過程，在認證消息里包含了用戶名信息，而用戶名信息是通過SDK的的ICE參數來傳遞給對方的，因此可以在用戶名中添加業務標識的內容，然后在ICE握手的過程中識別出對方的身份，然后將身份和發送的IP地址關聯，這樣只要對方發送消息我們就可以知道是誰發送的，從而實現端口復用。
在實現單端口方案的過程中, 采用epoll來實現描述符事件管理，去掉對libnice和glib的依賴。最終可以通過單一(或少量)的端口對外提供網關的服務，同時降低CPU的消耗。
在方案實施后, 同樣的場景下, CPU占用從30%降到了10%左右, 仍然有點高, 不過已經好很多了。
相比前面的幾種方案，這種方案會復雜很多，首先需要實現ICE邏輯并在Janus Core中把libnice替換成自實現方案，同時還需要實現相關的輔助結構，如ICE定時器等, 總體來看有一定的工程復雜度，但從效果上來說是值得一做的。
