聊聊 WebRTC 網關服務器1：如何選擇服務端端口方案？

《聊聊 WebRTC 網關服務器》系列文章系由 WebRTCon2018 中網易雲信音視頻技術專家的分享內容《從零開始構建音視頻網關服務器》整理而成，該系列文章將和你們分享網易 NRTC 在 WebRTC 網關項目的自研過程當中遇到的一些問題，以及咱們最終的解決方法。

《聊聊 WebRTC 網關服務器》第一篇文章將和你們分享如何選擇服務端的端口方案。

標準 WebRTC 鏈接創建流程

在討論如何選擇服務器端的端口方案前，咱們先來看看標準 WebRTC 的鏈接創建流程，這爲咱們理解這篇文章後續內容提供最基礎的知識。

這裏描述的是 Trickle ICE 過程，而且省略了通話發起與接受的信令部分。流程以下：

1. WebRTC A 經過 Signal Server 轉發 SDP OFFER 到 WebRTC B。WebRTC B 作完本地處理之後，經過 Signal Server 轉發 SDP ANSWER 到 A。
2. A、B 同時向 STUN Server 發送 Binding request 請求自身的外網地址，並從 STUN Server 回包的 MAPPED-ADDRESS 中獲得各自的外網地址；
3. A、B 收集完內外網 ICE Candidate，並經過 Signal Server 發送給對方；
4. 雙方開始作 NAT 穿越，互相給對方的 ICE Candidate 發送 STUN Binding Request；
5. NAT 穿越成功，A、B 之間的 P2P 鏈接創建，進入媒體互通階段。在這個過程當中，咱們看到了有三個核心的部分，SDP 協商、ICE Candidate 交換、Stun Binding Req/Res 的連通性檢查。

WebRTC網關鏈接創建流程

在瞭解了標準 WebRTC 的建連流程之後，咱們來看看 WebRTC 客戶端如何與網關建連。

首先，咱們網關的 Media Server 擁有公網 IP，所以 Server 就不須要經過 Stun Server 收集自身的公網 IP。WebRTC 客戶端先與網關 Signal Server 協商 SDP，包括 ICE Candidate，Media Server 分配 IP 和端口做爲網關的 ice candidate 發送給客戶端。由於網關是公網 IP，因此客戶端向這個 IP 發送 STUN Binding Request 會被服務器收到， 並回復 Response。接着客戶端與網關媒體服務器進行 DTLS 握手與祕鑰協商，在此基礎上進一步進行 SRTP 的音視頻通訊。至此，WebRTC 客戶端與網關服務器建連成功。
好的，如今咱們已經具有了探討服務器端端口選擇的基礎知識，接下來咱們來看看具體有哪些方案。

WebRTC 網關服務器媒體架構

最簡的服務器端端口方案是咱們能夠爲每一個客戶端分配一個端口，服務器上使用這個端口區分每一個用戶，就像圖裏描述的 A、B、C、D 四我的在 WebRTC 網關服務器上分別對應 UDP 端口 10001~1004。這種方案邏輯上很簡單，不少開源的服務器都採用這個方案，如 janus。另一個緣由是使用了 libnice 庫在服務器上來和客戶端作 ice 建連，相似的作法都是採用多端口的架構。
那麼多端口有什麼不足呢？

1. 不少的網絡出口防火牆對可以經過的 UDP 端口是有限制的；
2. 對於服務端來講開闢這麼多端口，安全性自己也有必定的問題，特別是網易的運維同窗，更是拒絕；
3. 開闢這麼多的端口在 Server 端上，端口的開銷和性能均有必定的影響。那可否用單端口？使用單端口前，核心要解決的一個問題是：如何區分每個 RTP/RTCP 包是屬於哪個 WebRTC 客戶端。

爲了解決這個問題，咱們須要使用一些小技巧。首先，有幾個基礎知識點咱們先了解一下。以下圖：

1. SDP offer 和 answer 裏配置的 ice-ufrag 字段裏面內容，原來是用來做爲stun數據包的鑑權的，所以 STUN Binding Request 裏面的 USERNAME 字段就是由上 Offer 和 answer 的 ice-ufrag 內容拼接而成。
2. 發送 STUN Binding Request 的客戶端本地 udp fd，與 ice 建連成功後發送媒體數據的 udp fd 是同一個，也就是說 Server 上看到的 ip port 是同一個。

有了上面的背景知識，聰明的大家確定已經大體有一個方案了。咱們來看看實現細節是怎麼樣的：

1. 在服務器給 Web 端的 SDP Answer 中設置 ice-ufrag 爲roomid/userid，其中 RoomID 和 UserID 是通話業務層分配的內容，用於區分每統統話以及參與這。接着作 Ice candidate 協商，Web端開始作連通性檢測，也就是 stun binding request 裏的USERNAME 爲 SDP local 和 remote 的 ice-ufrag 指定內容。
2. 服務器收到 stun binding request 的客戶端 ip 和端口，並正常回 stun binding response。
3. 記錄客戶端地址與用戶的信息的映射關係。
4. 服務器收到一個 rtp/rtcp 媒體數據包，經過包的源 ip 和端口，查詢映射表就能夠識別這個包屬於哪一個用戶。

在分享完服務端端口選擇的方案後，你們都知道 WebRTC 客戶端使用 PeerConnection 來表示不一樣的媒體鏈接，這對於 WebRTC 來講是基礎也是核心，在《聊聊 WebRTC 網關服務器》第二篇文章將繼續爲你們介紹如何選擇 PeerConnection 的方案。

---

隨着音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易 MC 官方博客以及微信公衆號：**

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網

官網微信公衆號：