編者按：本文由百度智能云RTC產(chǎn)品技術(shù)負(fù)責(zé)人 李永興LiveVideoStack線上分享的內(nèi)容整理而成，從系統(tǒng)架構(gòu)角度，分析了常見的開源SFU在分布式部署以及高可用、高并發(fā)方面的不足，并提出相應(yīng)的解決方案。

大家好，我是來自百度智能云的李永興，在百度智能云媒體云團(tuán)隊(duì)主要負(fù)責(zé)RTC產(chǎn)品的研發(fā)工作。

01 開源SFU的現(xiàn)狀與不足

在研發(fā)RTC產(chǎn)品的過程中，我們調(diào)研了許多優(yōu)秀的開源WebRTC服務(wù)器，例如：Janus、MediaSoup、Licode、SRS4等，這些SFU都有不同的設(shè)計(jì)理念和特點(diǎn)，我們從中受益頗多。同時我們也發(fā)現(xiàn)如果要基于這些優(yōu)秀的開源的SFU構(gòu)建一個高可用高并發(fā)的RTC云服務(wù)，就必須對這些SFU進(jìn)行相應(yīng)的改造。本次分享會主要介紹這些“改造部分”，這些改造其實(shí)具備一些普遍性，即針對開源SFU普遍存在的問題進(jìn)行優(yōu)化和改造，并不局限于某一特定的SFU。RTC云服務(wù)的要求

要想構(gòu)建一個RTC云服務(wù)，存在以下幾點(diǎn)要求：

高并發(fā)：RTC云服務(wù)必須要支持海量并發(fā)用戶，同時還需要支持海量房間。

高性能：除了單機(jī)性能，能抗更多的流次外，還要具備更高的連通率，保證通信的穩(wěn)定。同時還要求有很強(qiáng)的抗弱網(wǎng)性能。

高可用：單機(jī)單節(jié)點(diǎn)出現(xiàn)故障時不影響系統(tǒng)可用性。

彈性伸縮：系統(tǒng)可以很方便的進(jìn)行擴(kuò)容操作，并且擴(kuò)容時盡可能減少相應(yīng)配置，這樣可以使系統(tǒng)迅速進(jìn)行擴(kuò)容。

當(dāng)前一些開源SFU的現(xiàn)狀，例如Janus和MediaSoup，其服務(wù)端都會開UDP的操作范圍，即服務(wù)端用不同的端口服務(wù)不同的客戶端的媒體連接。同時在Janus中，信令和媒體是耦合在一起的；而在MediaSoup中，官方提供了nodejs庫，其本身只是一個媒體層的庫。但同時官方也提供了一個Demo，其媒體層和信令也是耦合在一起的；SRS4實(shí)際是國產(chǎn)之光，產(chǎn)品推出的時間不久，目前只支持WebRTC拉流功能。 對于這些開源SFU，主要的改進(jìn)點(diǎn)有：

使用端的UDP服務(wù)端端口進(jìn)行流媒體的傳輸；

信令和媒體層分離設(shè)計(jì)，可以支持大規(guī)模分布式部署；

關(guān)于級聯(lián)方面，各個開源SFU都沒有相對完整的解決方案。在我們的系統(tǒng)中，采用路由表方式的級聯(lián)，并且是私有協(xié)議的級聯(lián)，可以很好的支持和用戶就近接入。

當(dāng)然對于整個RTC云服務(wù)，除了SFU這個核心功能之外，RTC云服務(wù)還需要支持一些混流、錄制、多協(xié)議網(wǎng)關(guān)支持（例如RTMP的接入：方便微信小程序的接入、SIP的接入）等。 02 單端口方案

目前無論是Janus還是MediaSoup，服務(wù)端都是使用單獨(dú)的UDP端口服務(wù)單獨(dú)的PeerConnection， SFU在啟動時會配置一個可用的UDP的端口范圍，用于客戶端的數(shù)據(jù)傳輸。服務(wù)端接收到客戶端的請求后，會從配置的端口范圍內(nèi)為客戶端分配一個未被使用的端口，通過SDP把服務(wù)端的端口傳給客戶端?？蛻舳耸盏絊DP端口并進(jìn)行解析，然后就可以向服務(wù)端發(fā)送或接收數(shù)據(jù)。這就要求服務(wù)端同時暴露成千上萬個端口，對于網(wǎng)絡(luò)安全性是很不友好的，同時可運(yùn)維性也較差。另外，客戶端的網(wǎng)絡(luò)可能會對目的端口進(jìn)行一些限制，如果分配的端口在允許范圍之外，那么客戶端就連接不到服務(wù)器，導(dǎo)致整個連通的失敗。 為了實(shí)現(xiàn)云服務(wù)的高可用、彈性伸縮一般會配置負(fù)載均衡設(shè)備作為網(wǎng)絡(luò)的接入設(shè)備。在真正生產(chǎn)環(huán)境中，可能一個IP后面會掛著幾十甚至上百臺機(jī)器，當(dāng)機(jī)器宕機(jī)時不會導(dǎo)致整個服務(wù)的不可用。常見的負(fù)載均衡設(shè)備中很少看到有支持UDP PortRange方式的，即使支持了，由于暴露了很多端口，健康檢查方面實(shí)際是不可能完成的任務(wù)。 鑒于以上問題，我們就需要對SFU進(jìn)行相應(yīng)的改造，以使得服務(wù)端使用單端口對流媒體的數(shù)據(jù)進(jìn)行傳輸。 Janus使用了Libnice庫作為底層網(wǎng)絡(luò)傳輸庫，該庫本身是多端口的實(shí)現(xiàn)，因此要在Janus基礎(chǔ)上實(shí)現(xiàn)單端口存在兩種方案：一種是直接替換掉Libnice庫，重新構(gòu)建底層，改為單端口的傳輸方式。但是由于Janus和Libnice庫的耦合非常緊密，若要使用重新構(gòu)建底層的方式，實(shí)現(xiàn)較為復(fù)雜的，難度很大；另外一種方式就是保留Libnice多端口的實(shí)現(xiàn)，在Janus上增加單端口代理的功能。代理的功能是指將單一的對外端口傳輸?shù)目蛻舳说臄?shù)據(jù)，在接收到數(shù)據(jù)之后，同時將相應(yīng)的數(shù)據(jù)轉(zhuǎn)發(fā)到Libnice內(nèi)部分配的不同服務(wù)端的內(nèi)部端口中。這種方式修改起來會更簡單一些。

若選擇使用代理方式，其實(shí)現(xiàn)難點(diǎn)在于來自不同客戶端的數(shù)據(jù)都是通過同一個服務(wù)端端口進(jìn)行傳輸，服務(wù)端該如何判斷傳輸?shù)臄?shù)據(jù)與用戶的對應(yīng)關(guān)系。對此，我們可以通過SDP協(xié)商里面的ICE-Ufrag字段進(jìn)行解決，當(dāng)服務(wù)端接收到客戶端的SDP后，按照之前的流程，會創(chuàng)建本地服務(wù)的端口，并且將相應(yīng)的ICE-Ufrag與該端口映射起來。服務(wù)端會將對外的IP端口寫入SDP傳給客戶端，然后一直監(jiān)聽對外端口?？蛻舳私?lián)時會發(fā)送Stun包， Stun包中會帶有ICE-Ufrag，服務(wù)端接收并解析出ICE-Ufrag，再根據(jù)之前的映射關(guān)系，從IP-MAPS中找到對應(yīng)的服務(wù)端端口。同時服務(wù)端還會記錄Stun包的來源客戶端IP和端口，服務(wù)端就會將用戶側(cè)的IP和端口與服務(wù)端的IP和端口映射起來。每次收到客戶端的數(shù)據(jù)之后，就可以查看數(shù)據(jù)源的IP和端口，通過MAP的映射關(guān)系查到對應(yīng)的服務(wù)端的端口，將數(shù)據(jù)轉(zhuǎn)發(fā)到相應(yīng)的服務(wù)端端口中。同理，服務(wù)端發(fā)出的數(shù)據(jù)也會從映射關(guān)系中找到對應(yīng)客戶端的IP和端口，通過單個端口發(fā)出。 通過這種單端口的方案，我們就可以將SFU部署在負(fù)載均衡設(shè)備之后，并且可以很方便的進(jìn)行臺線擴(kuò)容和健康檢查，達(dá)到高并發(fā)和高可用的目的。另外，服務(wù)端是有公網(wǎng)地址的，因此WebRTC的ICE、打洞的操作實(shí)際上也就不需要了。在進(jìn)行地址映射時，需要使用客戶端Stun包的真實(shí)地址。在測試中我們發(fā)現(xiàn)，有時候真實(shí)地址與客戶端發(fā)送過來的Candidate中的地址不一樣，如果使用Candidate中的地址則會存在連通失敗的問題。 MediaSoup雖然也是多端口方案，但是并未使用Libnice庫，因此可以直接在底層實(shí)現(xiàn)整套單端口方案，并不需要Porxy的存在。 這里值得一提的是SRS4，雖然SRS4目前只支持WebRTC的拉流，但是其實(shí)現(xiàn)是基于原生的單端口方案，沒有使用Libnice庫，整個MAP的建立過程與前面所描述的是一致的，也不需要Porxy的存在。SRS4在單端口方面還是相當(dāng)友好的，可以很簡單的實(shí)現(xiàn)集群化的分布式部署。 03 信令分離

WebRTC標(biāo)準(zhǔn)本身并沒有規(guī)定信令的部分，因此各個開源的SFU基本都是自定義實(shí)現(xiàn)的。Janus實(shí)現(xiàn)了基于HTTP或WebSocket的信令，MediaSoup本身是nodejs的庫，不包含信令部分，但是其官方的Demo也實(shí)現(xiàn)了HTTP或WebSocket的信令。它們的共同點(diǎn)是信令部分的實(shí)現(xiàn)和媒體部分的實(shí)現(xiàn)是集成在一起的。信令一般基于TCP協(xié)議的，媒體一般是基于UDP協(xié)議的。如果它們的實(shí)現(xiàn)集成在一起的話，就需要一個客戶端的TCP信令和UDP流媒體數(shù)據(jù)發(fā)送到服務(wù)端的同一臺機(jī)器上。這主要是因?yàn)榉?wù)端在收到客戶端的信令后，會在本機(jī)進(jìn)行一些資源的初始化工作，如果TCP信令和UDP流媒體數(shù)據(jù)不在同一臺機(jī)器上是無法完成的。 這樣就存在兩種簡單的方案，其一：每臺機(jī)器都有一個單獨(dú)的公網(wǎng)IP；其二使用源地址哈希的負(fù)載均衡。 如果選擇單獨(dú)的公網(wǎng)IP的方案，功能實(shí)現(xiàn)沒有問題，但并不能達(dá)到高可用、高并發(fā)的要求。一臺機(jī)器對應(yīng)一個IP，如果這臺機(jī)器上的流特別多，就會很難負(fù)載，無法進(jìn)行彈性擴(kuò)容。 我們的主要目的就是希望同一個客戶端的TCP和UDP負(fù)載到同一個服務(wù)器上，而使用源地址哈希的方式，會出現(xiàn)兩個問題：一個是負(fù)載不均衡的問題，如果多個用戶共享同一個網(wǎng)絡(luò)出口的話，會造成負(fù)載的不均衡；另外一個問題是在實(shí)際網(wǎng)絡(luò)過程中，即使是同一個客戶端，它的TCP出口與UDP出口也可能并不相同，這就會導(dǎo)致客戶端的整個連通失敗。

根據(jù)以上分析可知，造成這種問題的根本原因是由于SFU同時提供了信令和媒體服務(wù)，我們的解決方案就是將信令從SFU中分離出來，信令分離其實(shí)有兩層意思，其一：是將信令服務(wù)從SFU中分離，SFU作為單純的流媒體處理器使用。其二：是將信令分為兩部分，一部分是與客戶端交互的信令，另外一部分是信令服務(wù)器與SFU或MeidiaServer之間的內(nèi)部交互信令。 將信令服務(wù)分離之后，就可以單獨(dú)實(shí)現(xiàn)信令服務(wù)器，為客戶提供基于TCP的信令服務(wù)，包括SDP解析、生成服務(wù)?？蛻舳耸紫纫B接到信令服務(wù)器上，進(jìn)行媒體協(xié)商，信令服務(wù)器會根據(jù)一定的策略選擇SFU或MeidiaServer的節(jié)點(diǎn)的IP通過SDP返回給客戶端，同時信令服務(wù)器還會把接收到的客戶端信息向?qū)?yīng)的分配的SFU進(jìn)行廣播?？蛻舳私邮盏絊DP之后，根據(jù)IP相應(yīng)的連接到SFU的節(jié)點(diǎn)，SFU的節(jié)點(diǎn)中的所有機(jī)器其實(shí)都已經(jīng)具備了客戶端的信息，這樣客戶端就可以進(jìn)行正常的推拉流。 因?yàn)椴捎昧诵帕罘蛛x，所以也就不需要依賴于源地址哈希的負(fù)載均衡策略。同一個客戶端的多個PeerConnection可能會打到后端不同的SFU上，也就達(dá)到了比較好的負(fù)載均衡的目的。 信令分離之后，緊接著的一個問題就是：信令服務(wù)器與SFU或MeidiaServer之間內(nèi)部信令如何交互。信令服務(wù)器需要向SFU或MeidiaServer廣播用戶的信息，SFU需要向信令服務(wù)器上報一些媒體狀態(tài)。這些內(nèi)部信令的特點(diǎn)就是可以異步處理，不需要等待處理的返回結(jié)果，因此就可以使用消息隊(duì)列去完成內(nèi)部信令的交互，消息隊(duì)列的引入進(jìn)一步使得信令服務(wù)器與SFU進(jìn)行應(yīng)用的解耦，二者的部署就更加靈活。信令服務(wù)器可以與SFU進(jìn)行混合部署，也可以進(jìn)行單獨(dú)部署。 信令服務(wù)器除了向客戶端提供一些信令服務(wù)之外，還會使用客戶端真實(shí)的IP通過http-DNS服務(wù)獲得最佳的SFU節(jié)點(diǎn)地址，并返回給客戶端。這樣就會使得SFU的調(diào)度更加的準(zhǔn)確，提供更好的服務(wù)。 Janus的信令與媒體的耦合較為緊密，因此分離起來會稍顯復(fù)雜，同樣有兩種方案：一種是基于現(xiàn)有的Videoroom的插件去做修改，另外一種是直接自己實(shí)現(xiàn)一個SFU插件。兩者的工作量都不算太小，如果自己實(shí)現(xiàn)SFU插件，Janus Core里面的部分也需要進(jìn)行修改。 對于MediaSoup本身來說，它只是一個nodejs庫，不包含信令部分，只需要實(shí)現(xiàn)一些上層消息隊(duì)列的收發(fā)以及內(nèi)部信令的解析功能即可，需要一個單獨(dú)的信令服務(wù)器與客戶端提供信令服務(wù)。 SRS4內(nèi)部有一個很簡單的拉流信令部分，如果想用SRS4實(shí)現(xiàn)WebRTC的拉流功能，信令的分離工作也是需要去做的。 04 級聯(lián)Relay

對于級聯(lián)Relay部分的改造，RTC的多方通話存在跨地域、跨運(yùn)營商的問題。為滿足更多用戶的優(yōu)質(zhì)體驗(yàn)，需要用戶就近接入，即通話多方分布在不同的SFU上。這就需要我們的SFU具備級聯(lián)Relay的能力，將相關(guān)的媒體流轉(zhuǎn)發(fā)到需要媒體流的SFU上。目前開源的Janus和MediaSoup都不具備完備的級聯(lián)能力，都需要進(jìn)行相應(yīng)的改造。 級聯(lián)主要涉及兩個問題：其一，網(wǎng)絡(luò)拓?fù)涞膯栴}，其二是級聯(lián)協(xié)議的問題。 級聯(lián)網(wǎng)絡(luò)拓?fù)鋯栴}中最主要的是級聯(lián)路由選擇的問題。傳統(tǒng)的CDN網(wǎng)絡(luò)是樹形結(jié)構(gòu)，由中心節(jié)點(diǎn)和邊緣節(jié)點(diǎn)構(gòu)成，其主要優(yōu)點(diǎn)是回源結(jié)構(gòu)比較簡單，多級放大，并發(fā)能力較強(qiáng)。其主要缺點(diǎn)是由于中心源棧的存在，多級的回源結(jié)構(gòu)導(dǎo)致延遲較大，不太適合RTC的應(yīng)用。 由于網(wǎng)絡(luò)狀況每時每刻都在發(fā)生變化，所以我們也不能確定RTC的應(yīng)用最適合哪種結(jié)構(gòu)。因此我們在設(shè)計(jì)的時候，最看重的是網(wǎng)絡(luò)的靈活性和自適應(yīng)性。 網(wǎng)絡(luò)靈活性是指可以靈活的通過配置的方式，改變網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)，并且可以適應(yīng)多種網(wǎng)絡(luò)環(huán)境。級聯(lián)可能會有很復(fù)雜的應(yīng)用場景，例如，Relay可能是在公網(wǎng)做的，也可能是內(nèi)網(wǎng)做的，也可能是幾點(diǎn)間或內(nèi)部進(jìn)行級聯(lián)。 自適應(yīng)性是指系統(tǒng)可以根據(jù)實(shí)時的網(wǎng)絡(luò)狀況自動調(diào)整路由選擇。為此，在級聯(lián)中我們引入了路由表的設(shè)計(jì)，路由表就包括目的地址和下一跳地址。中心控制節(jié)點(diǎn)會將路由表下發(fā)到各個節(jié)點(diǎn)的SFU中，與CDN回源不同，由于RTC中沒有中心源站上的概念，因此采用的是主動轉(zhuǎn)發(fā)的方式，而不是類似CDN拉流回源的方式。中心節(jié)點(diǎn)其實(shí)會保存每條流的節(jié)點(diǎn)位置的信息，當(dāng)某個節(jié)點(diǎn)需要某條流時，中心節(jié)點(diǎn)會向距離最近的并且有這條流的節(jié)點(diǎn)轉(zhuǎn)發(fā)命令，SFU收到轉(zhuǎn)發(fā)命令之后，會將路由信息寫到轉(zhuǎn)發(fā)包的頭里面，并根據(jù)路由表查詢下一跳到哪里，進(jìn)行轉(zhuǎn)發(fā)。下一跳接收到轉(zhuǎn)發(fā)包之后，重復(fù)相應(yīng)的過程，直到到達(dá)最后的目的地。這種做法的優(yōu)點(diǎn)在于每次轉(zhuǎn)發(fā)只需要中心節(jié)點(diǎn)下發(fā)一次命令即可，后續(xù)的轉(zhuǎn)發(fā)完全由SFU自主完成。 中心控制節(jié)點(diǎn)還具備路由表的自動生成能力，如果有新節(jié)點(diǎn)上線，會自動生成新節(jié)點(diǎn)相關(guān)的路由表并下發(fā)，這樣就可以保證新節(jié)點(diǎn)上線時，自動的完成數(shù)據(jù)流轉(zhuǎn)的暢通。自適應(yīng)的原理是節(jié)點(diǎn)主動對相鄰的節(jié)點(diǎn)進(jìn)行延遲和丟包的探測，并將這些探測結(jié)果上傳到中心節(jié)點(diǎn)，中心節(jié)點(diǎn)根據(jù)這些探測結(jié)果對路由表進(jìn)行一些調(diào)整、下發(fā)，這個功能目前我們還在處于測試階段。 級聯(lián)的另外一個問題是協(xié)議的問題，級聯(lián)主要是在SFU之間進(jìn)行，我們采用的是通過私有協(xié)議進(jìn)行級聯(lián)。WebRTC的協(xié)議本身是基于P2P的，因此如果使用WebRTC協(xié)議做SFU之間的級聯(lián)就太重了，很多內(nèi)容是不需要的。同時我們會將一些業(yè)務(wù)信息，例如房間號、用戶號、路由信息等加到私有協(xié)議中，當(dāng)接收端收到包之后就不需要再單獨(dú)進(jìn)行查詢操作，同時也可以自動完成路由數(shù)據(jù)包的轉(zhuǎn)發(fā)。 SFU使用單獨(dú)的Relay端口進(jìn)行私有協(xié)議和數(shù)據(jù)的監(jiān)聽和轉(zhuǎn)發(fā)，同時級聯(lián)的端口也可以開放給客戶端，客戶端也就可以通過私有協(xié)議接入RTC系統(tǒng)。由于有一些公網(wǎng)Relay場景的存在，私有協(xié)議里我們還會加入丟包重傳FEC的功能，以保證公網(wǎng)之下Relay的質(zhì)量。 Janus有一個RTP forword的功能，可以將用戶的媒體流以RTP的方式forword到一個地址里。如果要基于Janus做級聯(lián)，可以基于這個功能進(jìn)行一些改造，增加級聯(lián)的監(jiān)聽功能，可以實(shí)現(xiàn)整個媒體流的轉(zhuǎn)發(fā)。 05 RTC云架構(gòu)

上圖所示是整體的RTC云架構(gòu)，除了前面講到的流媒體服務(wù)器，還包含其它一些模塊，例如業(yè)務(wù)后臺的模塊Platform，包括Relay、路由表、房間等控制，Platform、信令服務(wù)器、流媒體服務(wù)器之間使用MQ進(jìn)行信令的同步和轉(zhuǎn)發(fā)，另外還有一些混流的服務(wù)，將多路視頻流混成一路，推向旁路直播或者存儲，混流服務(wù)器的流媒體轉(zhuǎn)發(fā)也是通過Relay的方式進(jìn)行的。除了以上，還有一些多協(xié)議的網(wǎng)關(guān)，例如支持RTMP(微信小程序)或SIP（傳統(tǒng)的視頻會議、終端）的接入。