大家好，我是李橋平，來自學(xué)霸君上海互動產(chǎn)品研發(fā)中心，本次分享的主題是Janus網(wǎng)關(guān)的集成與優(yōu)化。Janus網(wǎng)關(guān)是WebRTC的媒體服務(wù)器，它可以接收來自WebRTC客戶端的音視頻數(shù)據(jù)，根據(jù)業(yè)務(wù)需要對媒體數(shù)據(jù)進行處理，再轉(zhuǎn)發(fā)到其他WebRTC客戶端上, 以此完成音視頻互動。

本次分享的主要內(nèi)容是如何把Janus網(wǎng)關(guān)集成到我們公司內(nèi)部的自研RTC系統(tǒng)中，并對其做了一些優(yōu)化，在集成之后就可以通過瀏覽器和客戶端進行實時互動了。

1 背景介紹

背景介紹主要從三個方面來進行切入，分別是：業(yè)務(wù)場景、自研RTC體系以及為何要做集成。

1.1 業(yè)務(wù)場景

我們所做的業(yè)務(wù)是一個多人在線實時互動的教育場景，基本需求是老師和學(xué)生之間能夠進行音視頻實時互動。除了音視頻之外，還需要有一些其他的輔助教學(xué)內(nèi)容，也需要進行實時的交互，比如老師和學(xué)生的手寫筆跡、PPT課件、控制的狀態(tài)（課件翻頁）等。為了滿足這些功能，從技術(shù)上分解來看，首先需要支持多對多的音視頻連麥，其次是課件、手寫筆跡的實時同步。

1.2 自研RTC體系

為了實現(xiàn)這些功能，在袁榮喜老哥的帶領(lǐng)下, 我們開發(fā)了自己的RTC系統(tǒng)。自研RTC系統(tǒng)主要包含服務(wù)端和客戶端兩大塊，它們都是通過自研實現(xiàn)的(語音處理借助了WebRTC的APM模塊)。客戶端和服務(wù)器之間使用UDP協(xié)議來進行媒體通信, 數(shù)據(jù)包采用的是私有格式, 在此基礎(chǔ)之上完成傳輸?shù)目刂? 比如數(shù)據(jù)包排序重組, FEC, 丟包重傳, 主動Get以及擁塞控制等. 整個體系以客戶端的形式提供給用戶，支持windows、Android/ target=_blank class=infotextkey>安卓、mac、IOS這幾個主流平臺，在使用之前需要下載客戶端。

1.3 為何要做集成

我們主要是從用戶接入的易用性來考慮的. 首先是我們的客戶端需要用戶自己去下載，安裝成本是比較高，然后才是注冊賬號、登錄這些步驟。而WebRTC可以在瀏覽器上運行， 而大部分用戶對于瀏覽器是非常熟悉的. 其次, WebRTC的功能通過JS API進行調(diào)用，天然跨平臺, 不需要過多的考慮設(shè)備兼容性這些問題, 它們都封裝在WebRTC內(nèi)部了。

通過集成，用戶可以通過瀏覽器來接入我們的產(chǎn)品，對于沒有使用過我們產(chǎn)品的用戶來說, 它提供了一種更加便捷的方式。

上圖是完成集成后的一個效果，左圖是瀏覽器，登錄的是學(xué)生端。右圖的窗口是我們PC上的客戶端，登錄的是老師。老師和學(xué)生可以進行實時的視頻互動，同時還可以通過PPT課件和手寫筆跡來輔助課堂教學(xué)。

2 WebRTC與Janus網(wǎng)關(guān)

WebRTC與Janus網(wǎng)關(guān)部分包含三個小節(jié)：首先是P2P傳輸通道的建立，介紹WebRTC的媒體傳輸是如何建立起來的，其次是介紹WebRTC網(wǎng)關(guān)以及Janus網(wǎng)關(guān)。

2.1 P2P傳輸通道的建立

P2P是指通信的內(nèi)容可以不經(jīng)過服務(wù)器, 直接發(fā)送給對方，省去了中間服務(wù)器的開銷。WebRTC的P2P傳輸?shù)讓硬捎玫氖荱DP協(xié)議，從傳輸特性上說，它是無連接、不可靠的協(xié)議。當(dāng)然，WebRTC在進行傳輸時會有比如包確認(rèn)、包重傳等措施來彌補這些問題。

圖中下方是兩臺需要進行音視頻互動的電腦，電腦中的五色圓圈圖案是WebRTC的logo，表示這個電腦上運行的WebRTC的客戶端，這種客戶端最常見的就是瀏覽器了。實際上只要實現(xiàn)WebRTC的模塊功能，它們都可以進行音視頻的會話，比如WebRTC網(wǎng)關(guān)就實現(xiàn)了WebRTC模塊的功能，這里認(rèn)為這兩臺電腦上運行了支持WebRTC的瀏覽器就可以了。這兩個瀏覽器要進行音視頻互動至少需要兩方面的信息：一是雙方采用怎樣的音視頻編解碼以及相應(yīng)的編解碼參數(shù)，比如采樣率、分辨率、幀率等參數(shù)。二是使用UDP發(fā)送數(shù)據(jù)需要知道對方UDP的地址信息，主要包括IP地址和端口。要交換獲取這兩方面的信息的話, 需要借助到一個位于外網(wǎng)的服務(wù)器，我們稱之為信令服務(wù)器。

接下來我們來分析一下連接建立的過程. 首先，左邊瀏覽器發(fā)起一個SDP offer的請求，在SDP中攜帶了它支持的音視頻編解碼和ICE參數(shù)。這里引入了兩個概念：SDP和ICE。SDP(Session Description Protocol)是會話描述協(xié)議，這里只需知道它封裝了協(xié)商的參數(shù)就可以了。ICE(Interactive Connectivity Establishment)是互動連接建立，它負(fù)責(zé)UDP下媒體會話的建立. 在ICE參數(shù)里包含了UDP的地址信息(訪問外網(wǎng)的NAT地址需要借助STUN服務(wù), 為了簡單起見, 可以先不考慮)以及建立ICE連接所需要的用戶名跟密碼。

右邊的瀏覽器在接收到SDP offer工作請求以后，會根據(jù)自己所支持的編碼器情況進行匹配和篩選，然后生成SDP answer作為響應(yīng)，通過信令服務(wù)器中轉(zhuǎn)返回給左邊的瀏覽器，這樣雙方就完成了SDP的協(xié)商和交換。

在交換了SDP之后, 雙方通信需要的信息都完備了. 隨后這兩個瀏覽器會分別初始化好各自的音視頻設(shè)備，比如麥克風(fēng)、攝像頭設(shè)備。然后根據(jù)協(xié)商好的編解碼, 初始化編解碼器. 于此同時， 它們會向?qū)Ψ桨l(fā)送ICE建立請求的消息，該消息會帶上雙方協(xié)商好的ICE參數(shù)，主要是攜帶用戶名和密碼的信息(后面的單端口改造借助了這里的用戶名字段)。在完成ICE的請求交換后進行握手認(rèn)證，這樣就建立起了ICE的連接，雙方隨后以P2P的方式通過ICE連接發(fā)送編碼后的媒體數(shù)據(jù)。

直接將媒體數(shù)據(jù)發(fā)送給對方的這種形式被稱之為P2P直連，這種方式看似很好，因為它中間不需要經(jīng)過服務(wù)器，但在一些情況下會有問題。

首先，一般的設(shè)備都沒有公網(wǎng)IP地址，在訪問外網(wǎng)時需要經(jīng)過路由器，路由器上的NAT轉(zhuǎn)換會分配相應(yīng)的外網(wǎng)地址，再進行設(shè)備到外網(wǎng)的訪問工作. 這時路由器上的NAT策略直接影響到ICE連接是否能夠建立起來。整個過程涉及到UDP穿透問題，比如在對稱型、限制型錐形NAT上，穿透是很難完成的。

其次，在P2P直連的方式下，中間鏈路我們無法控制，因此傳輸質(zhì)量難以保證。假設(shè)圖中這兩臺電腦，一個位于電信，一個位于網(wǎng)通，即使它們能夠完成UDP的穿透，它們之間的傳輸延遲大概率也是很高的。

最后，因為數(shù)據(jù)不經(jīng)過服務(wù)器，行為監(jiān)管和媒體錄制都難以實現(xiàn),, 尤其對教育行業(yè)來講，行為監(jiān)管這塊是一個必不可少的需求。

2.2 WebRTC網(wǎng)關(guān)架構(gòu)

這是WebRTC網(wǎng)關(guān)的架構(gòu)圖。通常情況下我們將WebRTC網(wǎng)關(guān)部署到外網(wǎng)，這兩個瀏覽器分別通過NAT連接到網(wǎng)關(guān)，并通過網(wǎng)關(guān)來轉(zhuǎn)發(fā)相應(yīng)的媒體數(shù)據(jù)。網(wǎng)關(guān)上的WebRTC logo表示在網(wǎng)關(guān)上實現(xiàn)了WebRTC模塊的功能. 因此它可以和瀏覽器上的WebRTC模塊進行通信。瀏覽器和WebRTC網(wǎng)關(guān)之間的紅色箭頭表示信令消息的交互，綠色箭頭表示媒體消息。

下面來看看關(guān)于上個小節(jié)中的幾個問題在WebRTC網(wǎng)關(guān)上是如何解決的。

首先穿透問題，因為WebRTC網(wǎng)關(guān)是部署到外網(wǎng)的，瀏覽器通過內(nèi)網(wǎng)去訪問外網(wǎng). 只要能夠正常上網(wǎng)，訪問外網(wǎng)是沒有問題的，因此不會有穿透失敗的問題, 同時也可以省去STUN服務(wù).

其次是聯(lián)通到電信的情況，可以把WebRTC網(wǎng)關(guān)部署到BGP的多線機房, 電信和聯(lián)通到BGP的延遲可以做到很低，通過一個中轉(zhuǎn)，整體的中轉(zhuǎn)質(zhì)量反而比P2P直連質(zhì)量更好。

最后是監(jiān)管和錄制，因為媒體數(shù)據(jù)會經(jīng)過WebRTC網(wǎng)關(guān)，可以方便地在網(wǎng)關(guān)上進行錄制，同時也可以在網(wǎng)關(guān)上針對媒體內(nèi)容進行相應(yīng)的數(shù)據(jù)分析，實現(xiàn)對其監(jiān)管的功能。

在討論WebRTC網(wǎng)關(guān)時，一般會根據(jù)網(wǎng)關(guān)對媒體消息的處理方式劃分為兩類：SFU和MCU。

SFU在收到媒體數(shù)據(jù)以后，不會對媒體數(shù)據(jù)本身進行處理，只做一些基本處理(SSRC, timestamp等轉(zhuǎn)換)和轉(zhuǎn)發(fā)。左圖是SFU的示意圖，不同顏色所表示的媒體數(shù)據(jù)在進入SFU之后，它是以原來的形態(tài)發(fā)送到其他瀏覽器上的。

右圖是MCU的示意圖，媒體數(shù)據(jù)在進入MCU以后，MCU會對媒體內(nèi)容進行深度處理，比如把多路的聲音合并成一路或者把多路的頭像合并成一個大頭像，再根據(jù)需要做轉(zhuǎn)碼，并轉(zhuǎn)發(fā)到其他瀏覽器上。合流的一個好處是可以節(jié)省相應(yīng)的帶寬，同時可以在發(fā)送媒體數(shù)據(jù)的時候, 根據(jù)瀏覽器所支持的編解碼情況進行轉(zhuǎn)碼，因此它的適應(yīng)性會比較好。

2.3 Janus網(wǎng)關(guān)

Janus網(wǎng)關(guān)是SFU. 它是用C語言來實現(xiàn)的。其次, 在Janus上，業(yè)務(wù)模塊以插件的形式實現(xiàn)，部署是以SO動態(tài)庫的形式進行部署的，所以它的主程序和插件開發(fā)是一個分離的方式。最后，Janus Demo非常簡單直觀，很容易上手。

接下來這部分介紹Janus網(wǎng)關(guān)的軟件架構(gòu)。從層級上分析，Janus網(wǎng)關(guān)主要分為三層，從上至下分別是插件層、核心層和傳輸層。

插件層主要是決定SFU的轉(zhuǎn)發(fā)邏輯，比如決定轉(zhuǎn)發(fā)給房間里面的所有人，還是只轉(zhuǎn)發(fā)給其中的一部分人，是轉(zhuǎn)發(fā)音頻或者視頻，還是音視頻同時轉(zhuǎn)發(fā)。一個完整的插件方案，除了Janus網(wǎng)關(guān)服務(wù)器上的插件實現(xiàn)之外，還包括瀏覽器上的JS SDK。JS SDK處理的邏輯主要包括進出房間、訂閱相應(yīng)的媒體流等. 除此之外, 調(diào)用WebRTC的API獲取麥克風(fēng)和攝像頭的數(shù)據(jù)，還有播放音頻和視頻數(shù)據(jù)，都是通過JS SDK來完成的。

核心層主要負(fù)責(zé)SDP的協(xié)商以及ICE連接的建立，UDP媒體數(shù)據(jù)的接收和轉(zhuǎn)發(fā)也在核心層里完成。而插件和JS SDK的通信使用的是TCP協(xié)議, 它是通過傳輸層來完成的.

傳輸層主要負(fù)責(zé)在JS SDK和網(wǎng)關(guān)之間傳輸控制數(shù)據(jù), 插件自定義消息等。傳輸層支持多種常見的傳輸協(xié)議，比如HTTP、WebSoket等。

3 Janus與自研RTC的集成

第三部分是Janus與自研RTC的集成，主要包含三個小節(jié)，分別是系統(tǒng)架構(gòu)、音視頻互通、集成效果。

3.1 系統(tǒng)架構(gòu)

這張圖片是高度簡化后的結(jié)果，像自研RTC集群里的媒體調(diào)度、負(fù)載均衡、線性擴展等內(nèi)容都沒有在這里表達出來，主要是希望能突出與集成相關(guān)的內(nèi)容。圖中大致包含三個部分：自研RTC系統(tǒng)、Janus網(wǎng)關(guān)以及中間綠色箭頭代表的媒體通道。

我們按上圖從左至右, 來看一下通信流程。

首先是用戶A通過任意一個平臺的客戶端連接到自研RTC集群，通過中間的媒體通道，間接地和連接到網(wǎng)關(guān)上的瀏覽器用戶B進行音視頻互動。在Janus網(wǎng)關(guān)和瀏覽器用戶B之間主要傳輸RTP格式的音視頻數(shù)據(jù)和自定義格式的筆跡數(shù)據(jù)。其中的音視頻數(shù)據(jù)走的是P2P的傳輸通道，筆跡數(shù)據(jù)走的是WebSocket通道。整個集成核心的部分是位于Janus網(wǎng)關(guān)和自研RTC集群中間的綠色箭頭所代表的音視頻轉(zhuǎn)換，更具體的來說， 就是自定義封裝格式和RTP封裝格式的轉(zhuǎn)換。

前面介紹P2P媒體傳輸通道時提到RTP最終是通過UDP的傳輸協(xié)議發(fā)送出去的。

為了避免IP分片, 發(fā)送的UDP包不能太大， 具體一點是不能超過路徑上MTU的限制，一般來說，以太網(wǎng)上的MTU的最大限制是1500個字節(jié)。實際過程中需要除去IP協(xié)議頭和UDP協(xié)議頭開銷，剩下大概也就1400多個字節(jié), 因此RTP包不能超過這個限制, 這個限制會影響到RTP的封包過程。

3.2 音視頻互通

在我們的系統(tǒng)中音頻采用Opus編碼，視頻采用H.264編碼，WebRTC(主要是Chrome瀏覽器)也支持這兩種編碼，因此不需要在網(wǎng)關(guān)上進行轉(zhuǎn)碼了。

圖中展示的是音頻數(shù)據(jù)的轉(zhuǎn)換, 包含了音頻數(shù)據(jù)從采集到封裝成RTP的過程。從上往下, 首先是聲卡采集到PCM數(shù)據(jù)，一般是按10毫秒或者20毫秒這種固定長度進行組織. 經(jīng)過Opus編碼器, 根據(jù)PCM數(shù)據(jù)的內(nèi)容特征, 編碼成長度不一樣的編碼數(shù)據(jù). 編碼后的音視頻數(shù)據(jù)一般是幾十到幾百個字節(jié)左右。這樣的數(shù)據(jù)量可以直接在單個RTP包中進行攜帶，因此聲音的RTP封裝非常簡單，只需要在數(shù)據(jù)的前面追加上RTP頭部就行。

RTP頭部中主要的兩個字段是sequence number和timestamp, 即序列號和時間戳。因為UDP傳輸是一個不可靠的協(xié)議，在傳輸?shù)倪^程中可能會發(fā)生丟包或者亂序到達。序列號可以幫助接收端正確地組織接收到的數(shù)據(jù)， 根據(jù)序號的缺失情況可以知道哪些數(shù)據(jù)包丟失，根據(jù)丟失包的序號可以要求發(fā)送端進行重傳，從而保證傳輸質(zhì)量。時間戳主要是輔助播放端進行聲音的同步播放。

整個過程倒過來看，就是如何從瀏覽器發(fā)過來的RTP數(shù)據(jù)中提取編碼數(shù)據(jù)的過程。在提取出編碼數(shù)據(jù)以后就可以封裝成自研RTC格式，通過自研RTC集群再轉(zhuǎn)發(fā)到客戶端上，并在客戶端上進行播放。

接下來是視頻的轉(zhuǎn)換。

H.264視頻轉(zhuǎn)換在RFC6184文檔里有詳細(xì)的規(guī)定和說明。相對于音頻來說，視頻轉(zhuǎn)換要復(fù)雜一些，這是因為圖像數(shù)據(jù)編碼后，它的數(shù)據(jù)幀往往比較大，會超過RTP包的大小限制。

該圖是視頻數(shù)據(jù)轉(zhuǎn)換成RTP包的示意圖。還是從上往下看，首先攝像頭采集原始的視頻圖像，一般是YUV格式的，經(jīng)過H.264編碼后生成H.264的數(shù)據(jù)幀。數(shù)據(jù)幀本身是有內(nèi)部結(jié)構(gòu)的，它包含一個起始碼，后面跟著NAL單元，由多個這樣的結(jié)構(gòu)組成編碼后的數(shù)據(jù)幀，在轉(zhuǎn)換的過程中，第一步是要把起始碼去掉，再提取出單個的NAL單元數(shù)據(jù)。然后根據(jù)NAL單元數(shù)據(jù)能否封裝到單個RTP包中，分別封裝成三種不同的封裝格式。

圖中左邊是單個NAL單元的封裝， 在NAL單元比較小的情況下使用. 中間是單元片段的封裝， 在單個NAL單元大小超過RTP包限制的情況下，采用該封裝格式。

右邊是多個NAL單元聚集到一個RTP包的封裝過程，這里主要針對NAL單元很小，RTP包可以同時攜帶多個NAL單元的情況，封裝到一個包里，可以減少發(fā)包的數(shù)量。同樣，封包過程需要正確的填充RTP頭部的時間戳和序列號。

整個圖從下往上看，就是從RTP數(shù)據(jù)流中提取出來H.264編碼數(shù)據(jù)的過程，完成提取后再封裝成自研RTC系統(tǒng)的格式，發(fā)送到客戶端上進行數(shù)據(jù)的還原，再經(jīng)過H.264解碼器的解碼，得到原始的視頻數(shù)據(jù)并在界面上渲染出來.

3.3 集成效果

這個測試主要是想知道中間轉(zhuǎn)換部分的開銷, 因此這里不考慮客戶兩端到服務(wù)器的弱網(wǎng)情況. 首先是穩(wěn)定WiFi，到服務(wù)器RTT是30毫秒，視頻分辨率是320×240，幀率是20幀。整個過程下來音視頻流暢，媒體延遲小于100毫秒。

測試方法借助了一個在線秒表的時間跳動的畫面，虛擬攝像頭采集在線秒表的動畫，通過PC端進行編碼，然后上傳到自研RTC服務(wù)器, 轉(zhuǎn)換成RTP格式, 通過RUDP通道傳輸?shù)絁anus網(wǎng)關(guān), 再通過網(wǎng)關(guān)發(fā)送到瀏覽器上還原出視頻畫面。對比PC端和Web端看到的視頻畫面，就可以得出他們觀看的時間差。

圖中可以看出PC客戶端的畫面時間和Web的畫面時間相差大概幾十個毫秒。由于PC端有一些相應(yīng)的處理(如美顏)，而且存在渲染的時間消耗, 實際的差值會比這個大一些, 整體的時間延遲估計是100毫秒左右，效果還是不錯的。

4 Janus網(wǎng)關(guān)優(yōu)化

這部分我會從現(xiàn)象入手，介紹集成過程中所做的一些優(yōu)化，這里主要介紹CPU優(yōu)化和端口優(yōu)化。

首先在CPU方面，在測試時我們發(fā)現(xiàn)，在同一個房間里進入12個人，八個人開麥進行音視頻互動的話，Janus近程的CPU大概占到30%多。如果是一個四核的CPU, 算打到300%的話，也只能支撐120多個人，這樣的話承受能力會非常有限。因此需要對CPU進行優(yōu)化。

其次是端口，Janus在服務(wù)部署的過程中需要開放大量的端口. 這是因為Janus對于每一路上傳和每一路觀看都需要為它分配一個外網(wǎng)端口。分配過多的端口不管從安全管理上還是運維部署上都會帶來不便。在我們實驗室實際開發(fā)過程中就遇到過，當(dāng)同時開3、4個視頻時，整個視頻的數(shù)據(jù)下發(fā)不來, Web上看到的畫面是黑的. 經(jīng)過找相應(yīng)的IT人員一起定位分析后，發(fā)現(xiàn)是辦公室交換機出口對UDP訪問端口做了限制導(dǎo)致的，因為每一路視頻上傳下載都需要分配端口, 在交換機策略看來, 多個內(nèi)網(wǎng)的機器訪問了同一個外網(wǎng)IP(janus網(wǎng)關(guān)的IP)的大量不同端口, 被判定是異常狀態(tài)了。因此，不管從安全性、運維部署，還是服務(wù)質(zhì)量上來講，最好是用少量的端口來完成同樣的事情。

4.1 CPU優(yōu)化

這部分介紹針對上述兩個問題的分析和相應(yīng)的解決方法。CPU問題的原因主要有3個：一是SFU的轉(zhuǎn)發(fā)關(guān)系復(fù)雜度為M*N，其中M是上麥人數(shù)，N是房間內(nèi)的總?cè)藬?shù)。假設(shè)房間里有100個人，其中10個人上麥，那么轉(zhuǎn)發(fā)的復(fù)雜度就是10×100，因為對每一路上傳的視頻都需要轉(zhuǎn)給其他99個人，一路上傳加上99路轉(zhuǎn)發(fā)就是100處理量，10個人就是1000。

二是對于每一路上傳和轉(zhuǎn)發(fā)，Janus都分配一個對應(yīng)的UDP端口和socket描述符，該分配行為是Janus所使用的網(wǎng)絡(luò)庫Libnice決定的。

三是Libnice的內(nèi)部采用poll做事件處理，在描述符量很大時，它的效率很低。因為poll在調(diào)用時, 需要把所有描述符以數(shù)組的形式傳遞到內(nèi)核, 內(nèi)核需要對每個描述符進行查詢處理，并且還要注冊相應(yīng)的事件監(jiān)聽。如果當(dāng)前這次調(diào)用沒有收集到任何事件的話, 它會進行等待, 在等待過程中, 它會把當(dāng)前線程注冊到所有描述符的通知等待隊列里，然后被動等待相應(yīng)事件的喚醒。在事件到達喚醒后, 返回的過程中又需要把當(dāng)前線程移出所有描述符的等待隊列，這其中涉及到大量鎖操作。以上三個原因疊加起來，就造成了高CPU的情況。

CPU優(yōu)化的對策主要是從兩方面入手: 減少端口的使用, 以及把glib內(nèi)的poll調(diào)用改為epoll。

在使用上，端口的問題的使用可以采用以下一些辦法來緩解：

一是通過ice_enforce_list限定ICE收集candidate的網(wǎng)卡。默認(rèn)情況下，Janus會對所有的網(wǎng)卡都做端口收集。我們在開發(fā)的過程中所部署的機子上正好有兩個網(wǎng)卡，測試時發(fā)現(xiàn)，它所收集的端口數(shù)量比單網(wǎng)卡下多了一倍，在開啟這個的配置后，數(shù)據(jù)數(shù)量立馬減半，CPU也降低了很多。

二是確保Janus服務(wù)配置中， ice_tcp=false。這是在使用TCP穿透時所需要收集的端口，在實際應(yīng)用中很少用到，所以將其設(shè)置為“false”禁止掉就可以。

其次，把glib內(nèi)的poll調(diào)用改為epoll. 可以采用兩種方式 ：一是修改glib代碼，把事件處理的poll調(diào)用替換成epoll. 這種方式需要把glib代碼拉下來修改并測試，整個工作需要比較長的時間；二是采用github上第三方的擴展實現(xiàn) 。

4.2 端口優(yōu)化

對于端口優(yōu)化，我們采用了端口復(fù)用方案. 實現(xiàn)端口復(fù)用的情況下, 可以做到減少端口使用, 同時降低CPU使用率。具體的方法如下, 首先在Janus上接管ICE的處理，通過SDP中的ICE用戶名參數(shù)來識別發(fā)送端身份。在上文提到的P2P連接建立的過程中，首先要經(jīng)歷ICE認(rèn)證的過程，在認(rèn)證消息里包含了用戶名信息，而用戶名信息是通過SDK的的ICE參數(shù)來傳遞給對方的，因此可以在用戶名中添加業(yè)務(wù)標(biāo)識的內(nèi)容，然后在ICE握手的過程中識別出對方的身份，然后將身份和發(fā)送的IP地址關(guān)聯(lián)，這樣只要對方發(fā)送消息我們就可以知道是誰發(fā)送的，從而實現(xiàn)端口復(fù)用。

在實現(xiàn)單端口方案的過程中, 采用epoll來實現(xiàn)描述符事件管理，去掉對libnice和glib的依賴。最終可以通過單一(或少量)的端口對外提供網(wǎng)關(guān)的服務(wù)，同時降低CPU的消耗。

在方案實施后, 同樣的場景下, CPU占用從30%降到了10%左右, 仍然有點高, 不過已經(jīng)好很多了。

相比前面的幾種方案，這種方案會復(fù)雜很多，首先需要實現(xiàn)ICE邏輯并在Janus Core中把libnice替換成自實現(xiàn)方案，同時還需要實現(xiàn)相關(guān)的輔助結(jié)構(gòu)，如ICE定時器等, 總體來看有一定的工程復(fù)雜度，但從效果上來說是值得一做的。