原作者：Tsahi Levent-Levi（原文鏈接）

翻譯：劉通

原標題：With WebRTC, Don’t Never Ever Mix Media and Signaling

?

???????? 如果你想使用WebRTC做一個運行穩定并且足夠好的產品，你就必須把下面這三個實體分開。讓我們來一一分析。

?

信令服務器

???????? 我們每一個人的WebRTC產品中一定都有信令服務器。

???????? 這是為什么呢？

???????? 因為沒有信令服務器，就沒有網絡通話。完全進行不了任何通話，甚至連簡單的Hello World都完成不了。答案就是這么簡單。

???????? 你可以將信令服務器和你的應用服務器配置在一起。

???????? 下面這些關于服務器的特點你可能已經知道了：

#1 你可以配置一個服務器來平行地處理1000個，甚至100,000個連接和會話。

#2 這些服務器必須有所連接用戶的狀態，以保證它們很難超出容量范圍。

#3 通常，這些服務器所作出的決定是依據外部數據庫得出的。

#4 幾百毫秒的延遲對于這些服務器來說是可以接收的，但是但是如果沒有正確的設計和實施的話，它很容易出錯

???????? 另外信令服務器還是用高層語言編寫的，比如Java，Node.js，Rails，Python，PHP（我的天啊）等等。

?

NAT穿越服務器

???????? 我在這里說的是?STUN和?TURN。

???????? 而且是的，通常我們會把?STUN“塞”到?TURN中去。在這二種之中，?TURN是一頭占用資源的巨獸，但是?STUN可以被依附到同一個服務器上，因為?STUN和?TURN的目的是一樣的（以合適的方式獲取媒體流）。

???????? 這就是我為什么在這里忽略?STUN而只是將注意力集中在?TURN上的原因。

???????? 有的時候人們會忘記?TURN。他們之所以會忘記的原因是WebRTC在兩個瀏覽器標簽頁之間，或者同一個辦公室的兩個同事之間運行的很好。這是因為這兩個場景根本不需要用到?TURN。然后他們就把產品發出去了。后果可想而知。

?????????TURN作用是在會話參與方無法直接連接其他參與者的時候，在他們之間傳遞媒體。這種傳遞機制的兩個特點：

#1?TURN會吞噬掉大量的帶寬資源。

#2?你要做的是盡可能將你的TURN服務器部署在參與方附近。這是從?TURN服務器出發提高媒體質量、降低延時的唯一方法。而你會對網絡有更多的控制。

???????? 盡管你有可能不需要用很多?TURN服務器，但是你最好還是從你使用的云服務提供商那里辦一個。

???????? 我所知的絕大多數NAT穿越服務器都是用C/C++編寫的。

?

媒體服務器

???????? 媒體服務器不是必需的。媒體服務器其實并不是規范的一部分—只是用來滿足你的一些特定功能的。群組通話和錄音就是一個好例子，基本上都是要通過媒體服務器才能進行傳輸的。

???????? 但是問題是，相比于WebRTC所需的其他服務器，媒體服務器所消耗的資源要多的多。

???????? 而且媒體服務器的規范與其他服務器都不一樣。這就是為什么大多數情況下都把媒體服務器“隔離”安放的原因。

???????? 可以將媒體服務器和?TURN服務器配置在一起。但是我大多數情況下不贊成這種做法，因為相比于媒體服務器，?TURN更要面向網絡。而且我現在還沒聽說過有黑客攻擊過媒體服務器，我覺得這可能只是一個時間早晚問題。

???????? 媒體服務器通常是用C/C++編寫的。

????????

為什么要將他們分開？

???????? 因為他們彼此互不相同。

???????? 它們有不同的工作。

???????? 而且他們需要被設置在不同的地方。

???????? 所以邏輯上要把它們分開配置，而且準備好在需要的時候也要在現實將它們分開。

總結

以上是生活随笔為你收集整理的做WebRTC，千万别把媒体和信令混在一起的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。