WebRTC開源項目現狀

語言: CN / TW / HK
時間 2022-10-08 08:01:41
主題:

圖片

作者：Tsahi Levent-Levi、Philipp Hancke

翻譯、編輯：Alex

技術審校：李忠

影音探索 #018#

WebRTC的開源環境混亂不堪。它需要成熟起來併成為重要的業務，或者獲得重要的支持。

圖片

本篇文章由我和Philipp Hancke[1]共同創作。我們一起合作了很多事，包括WebRTC課程[2]（新課馬上要來了）和WebRTC洞察[3]等等。

WebRTC是免費的。今天，每個現代瀏覽器都包含了WebRTC。在這些瀏覽器中運行的基礎代碼不僅開源且使用寬鬆的BSD許可證。在某種程度上，免費和開源被融合在一個不那麼愉快的組合中，而開發者以為WebRTC中的一切都應該免費。

結果呢？在WebRTC推出11年之後，我們發現它的處境悲慘。在今天這篇文章中，我們會詳述WebRTC開源生態的現狀，以及我們為什麼需要做出必要的改變以確保WebRTC在未來幾年能夠健康發展。

你的開源輔導筆記

圖片

我們將從你所需要了解的最重要的事情開始：

開源 !=免費

在深入研究之前，先讓我們快速瞭解一下開源。

到底什麼是開源？

圖片

開源項目是指在開源許可協議的規定下，一段被大眾公開使用的源代碼。來自同一家公司或者不同公司的某個人或者某個團隊“聯合起來”開發了一個發揮某種作用的軟件。他們將該軟件的源代碼公開，並貼上許可證，這就成了一個開源項目。

開源並不等於免費。開源同樣要在法律約束下進行，但這並不是本文的重點。實際上，使用開源並不是説你無需向任何人支付任何費用，它意味着不需要任何附加條件，你就可以獲得代碼。

為什麼大家最終都願意為開源項目無償貢獻代碼？這就要從開源項目的商業模式説起。

開源商業模式

圖片

目前存在多種形式的開源許可證[4]。每種開源許可證都有自身的規則，其中一些相對更寬鬆，對商業更加友好。有時許可證類型本身也會被用作商業模式，它通過雙重許可模式實現：一個免費但有限制條款的開源許可協議，同時提供一個商業許可協議。

在其他情況中，開源項目的商業模式圍繞提供項目支持、維護和定製項目。你可以免費獲得代碼，但如果你需要幫助，你可以通過付費獲得支持。

有時，商業模式還圍繞着附加組件（比如，社區版和企業版在項目網頁作為選項彈出）。用於擴展系統的腳本、監測模塊或者其他操作和模塊組件等作為商業產品受到保護。項目的開源部分使各家公司能夠使用它，並提升了項目的知名度，而商業部分是開放開源部分的原因。開發者以此為生甚至發家致富。

近些年，我們看到一些圍繞着託管服務的商業模式，其中的代碼庫開源且免費，但如果你讓這些公司幫你託管並支付費用，那麼他們將為你解決所有維護和擴展問題。

有些人認為開源是真正免費的。Troy Hunt最近寫了一篇很棒的文章，你可以在這裏閲讀：http://www.troyhunt.com/if-youre-not-paying-for-the-product-you-are-possibly-just-consuming-goodwill-for-free/

“有一個建議是：我們這些開發軟件和服務的人必須以某種方式獲得收入。”

對此我想説的是：沒錯！

歸根結底，研究開源終為利。

為什麼這麼説？

  • 如果你創建了一個廣受歡迎的開源項目，那麼你總是想搞清楚如何通過它獲得收入。通過開源項目，你能直接（參見上文例子）或間接地增加獲得高薪工作或者加入更加有趣項目的機會。

  • 有時，研究開源是因為你對某一項技術十分感興趣。但最終結果是一樣的：或許你有時間搞開源，是因為你在其他公司可以獲得收入，只是把開源當作興趣；或許你任職的公司很高興你去研究開源（意味着你所做的事情能夠給公司帶來內在價值）。

  • 也許你搞開源是為了磨練技術。但話説回來，你這麼做的原因還是為了成為一名更優秀的程序員……並最終被公司聘用。

如果你正在開發的項目對另外兩個人或者一家公司有意義，那麼就能獲得金錢上的收益。我們敢説，如果你沒有從這些收益中獲得任何好處（即使很少），那麼開源項目就沒有真正的未來，它也到了生死關頭。

圖片

多説幾句開源項目

在開始WebRTC開源王國之旅之前，讓我們先來了解一些事：

  • 大部分開源項目只是一個將你的應用開發所需的某種性能抽象出來的API。在WebRTC中，我們會關注實現特定網絡實體的此類抽象。我們稍後會詳細介紹。

  • 當使用開源時，你通常對應用程序擁有更多控制權。這是因為你可以修改開源組件的源代碼，而不是在使用預編譯的庫時向廠商尋求幫助。

  • 很多開源項目的文檔都很糟糕。當它們缺乏可靠的商業模式時，更印證了這一事實：開發愛好者更喜歡寫代碼，而不是解釋如何使用這些代碼。

  • 文檔是開源項目商用很重要的一個方面。提供使其更易使用的清晰API外觀和示例代碼的能力也很重要。

WebRTC開源一覽

新手的一個常見錯誤是：WebRTC是一種不需要編碼的解決方案。既然瀏覽器已經實現了它，就沒有其他事要做了。這與真相相去甚遠。WebRTC協議需要一組移動組件、客户端和服務器；它們一起實現了我們所看到的這一豐富的通信解決方案。

圖片

上圖（來自高級WebRTC架構課程[5]）顯示了典型WebRTC應用中的各種必需組件。

  • 客户端： 基於Web或者其他

  • Web瀏覽器客户端作為瀏覽器的一部分“免費”獲得

  • 其他則需要你自己探索

  • 應用服務器： 本文我們並不會介紹應用服務器，因為任何類型的應用都具備這一通用組件，並非WebRTC專屬。

  • 信令服務器： 負責設置和協商WebRTC會話。

  • STUN/TURN 服務器： 處理NAT穿越。幾乎所有部署都需要它。

  • 媒體服務器： 用於媒體處理任務繁重的工作。無論是羣組通話、錄製，還是視頻渲染等，你都可以使用媒體服務器。

對於每個組件，你都可以找到一個或者多個開源項目來實現它。其中一些更好用，但許多開源項目已被遺忘並逐漸棄用，而只有少數設計精妙，令人讚不絕口。

讓我們深入瞭解這些組件，並看看其中可使用的組件以及其所對應的開源社區正處於什麼樣的狀態。

WebRTC開源客户端庫

首先是WebRTC開源客户端庫，它們是WebRTC協議在用户/設備/客户端層面的實現，可以將其視為WebRTC的底層API。

WebRTC曾經只有一個庫：libwebrtc。但漸漸地，更多的庫被推出並在生態中佔據了一席之地。

我們先從libwebrtc開始。

• libwebrtc

圖片

WebRTC中最主要的開源項目就是libwebrtc。為什麼？

  1. 它是第一個推出的開源項目。

  2. Chrome將它用於其WebRTC實現。

  3. Safari、Edge和Firefox也是如此：它們不同程度地集成和使用了libwebrtc。

  4. 許多native移動應用內部使用libwebrtc。

實際上，libwebrtc在WebRTC中無處不在。

這裏有幾個你需要知道的關於libwebrtc的知識點。

  • libwebrtc由谷歌唯一控制和維護。每個更改都需要谷歌同意。

  • Chromium和Chrome都兼容了libwebrtc，意味着它可以觸達幾十億部設備。

  • 谷歌非常保護libwebrtc，所以向libwebrtc貢獻代碼並非易事。

  • 雖然一直有人向libwebrtc貢獻代碼，但外部貢獻者少之又少。

  • 記住，谷歌團隊之所以維護libwebrtc並不是出於公益目的，他們也是為了滿足自身需求，尤其體現在這些年的Google Meet。Google Meet的用例、使用場景、API和代碼流程都很可能比libwebrtc的代碼庫更安全、更穩定並做了深度優化。

  • 值得一提的是，libwebrtc的全部構建系統是為了將其編譯進Chromium而非其他項目（比如你正在構建的那一個）。想了解更多，請觀看Philipp的Fosdem talk[6]。

  • 它的一些接口（比如設備獲取）測試比較少是因為Chrome覆蓋了這些接口，所以谷歌的重點是Chrome接口，而不是libwebrtc中實現的接口。

在過去的代碼貢獻中，谷歌佔據了其中的90%。

圖片

可以看到，在2016年初達到頂峯之後，代碼修改量之後逐年減少。在疫情期間，甚至降到了低於平均每月200個commit的低點。但即使代碼量不斷減少，libwebrtc依然是WebRTC生態中最大以及最頻繁更新的項目。

libwebrtc的外部代碼貢獻量相當低，不到總貢獻的10%， 對於WebRTC這一行業標準庫來説並不是一個好兆頭。如果谷歌可以打開大門，放入一些改進WebRTC或使WebRTC更易使用的貢獻代碼，那麼情況將會改善。

接下來我們將瞭解：libwebrtc的商業模式。

談錢時刻

如果有人決定使用libwebrtc並將它直接集成到自己的應用上怎麼辦？

  • 沒有付費支持選項。

  • 沒有真正的替代方案為定製化開發付費。

  • 維護自己的fork分支，然後和開源upstream 版本保持同步是一件成本非常高的事情。

  • 因此在大部分情況中，libwebrtc是最佳選擇。這是因為它準確支持你在Web瀏覽器中所遇到的各類實現，是最新的開源項目。

  • 值得一提的是，libwebrtc是用C++實現的。有什麼關係嗎？我們接下來要介紹的Pion會解釋這一切。

• Pion

圖片

Pion[7]是WebRTC API的Go實現。Sean DuBois[8]是Pion項目背後的核心人物，他對Pion的熱情頗有感染力。

Tsahi認為，用Go來寫Pion是它成功的主要原因。這只是因為相對於C++，很多開發者更願意使用Go（現代、新穎且時髦）。不論什麼原因，Pion從一開始就發展良好，現在已經成為一個流行的WebRTC開源項目。它常用於嵌入式設備、基於雲的視頻渲染和最近的SFU以及其他媒體服務器實現。

談錢時刻

如果有人決定使用Pion並將它直接集成到自己的應用怎麼辦？

  • 沒有付費支持選項。

  • 沒有官方替代方案為定製化開發付費。

  • Pion有很多代碼貢獻者，他們把這種貢獻當作正式工作。

• Python、Rust等

圖片

WebRTC還有其他語言的實現，其中比較有名的包括：

  • aiortc[9]：WebRTC的Python實現。

  • WebRTC.rs[10]：WebRTC的Rust實現，作為Pion的重寫（rewrite）被開發出來。

也許還有其他實現，但沒有那麼有名。

這裏我們就不介紹談錢時刻了。這些項目的規模太小，我們還沒有看到有很多服務在生產中大規模使用它們。

• GStreamer

圖片

GStreamer[11]是一個比WebRTC還老的開源媒體框架。它應用於使用WebRTC的應用和服務中，甚至沒有使用它的WebRTC能力（主要因為這些能力後面已經添加到了GStreamer中）。

我們看到，當廠商們需要進行實時的視頻內容轉碼時，就會使用GStreamer。比如：

  • 獲取機器渲染（3D、投屏等）並將它們通過WebRTC傳遞給瀏覽器。

  • 混合輸入數據，將它們合併為單個錄製文件或者單個直播流。

  • 在嵌入式平台上收集媒體輸入數據，並將它們準備用於WebRTC會話。

由於WebRTC是GStreamer中所添加的另一個輸出類型，開發者可以直接將它作為廣播實體（broadcasting entity）使用，這是一個不消耗數據只生成數據的實體。

GStreamer是社區努力的成果，並使用C編寫。雖然許多應用都使用GStreamer，但它卻缺乏強健的商業模式。這意味着什麼？

談錢時刻

如果有人決定使用GStreamer並將它直接集成到自己的應用怎麼辦？

  • 具備付費支持官方選項（by Centricular）。

  • 你也可以直接向Centricular支付定製化的開發費用。

  • 整個生態環境的規模已經足夠大，你可以很容易找到具備GStreamer知識的人。

開源TURN服務器

圖片

使用TURN連接WebRTC來轉發消息

接下來是TURN服務器。這裏就變得“簡單”了，因為我們主要討論的是coturn[12]。雖然還有其他幾個選擇，但是coturn是目前最流行的TURN服務器（開源或者其他）。

在很多方面，我們只需coturn即可，因為TURN很簡單，並可用於代碼實現（Cloudflare正在或曾經想要通過他們的管理服務改變這一點[13]）。

但是，凡事都有一個但是：coturn也需要不斷更新和改進。這是最近在coturn的github repo上發佈的一個問題[14]：這個項目死了嗎？

圖片

可以在註釋中的鏈接裏閲讀相關信息，其中的回答很有趣。

coturn的維護者已經精疲力竭，又或者只是沒有時間來維護它（他們都有自己的日常工作）。對於這樣一個廣受歡迎的開源項目，最終結果就是一兩個志願者邊忙碌於自己的日常工作，邊貢獻代碼。

接下來又到了：

談錢時刻

如果有人決定使用coturn並將它直接集成到自己的應用中怎麼辦？

  • 沒有官方付費支持選項。

  • 沒有官方替代方案支付定製化的開發費用。

  • 整個生態環境的規模已經足夠大，你可以很容易找到具備coturn知識的人。

WebRTC的開源信令服務器

圖片

信令服務器是一個很不同的開源項目。WebRTC沒有準確定義它們，但是需要它們在參與者之間傳遞SDP信息和其他信號。對於WebRTC的開源信令解決方案，這裏有幾種替代方案。

值得注意的是，WebRTC中許多信令服務器替代方案僅提供對等通信性能，而無法與媒體服務器交互。有些信令服務器也將處理音頻和視頻流。它們對媒體或信令的注重程度決定了我們是將它們視為媒體服務器還是信令服務器。這一切都取決於它們的關注點以及最終所提供的功能。

信令需要兩個組件，分別是信令服務器和客户端庫（通常是輕量級的，但並不總是這樣）。

我們將從標準庫SIP和XMPP開始。

• SIP和XMPP

SIP和XMPP比WebRTC早出現了10年左右，擁有自己的開源項目生態、廠商和開發者。它們可用作成熟且可擴展的服務器，有時通過擴展支持特定WebRTC應用場景，如為TURN創建驗證token[15]。

我們不會花時間一一解釋這些替代方案。

這裏值得一提的是MQTT。眾所周知，Facebook曾在Facebook Messenger中使用它發送信號（至少過去曾使用過，目前不確定是否還在使用）。

• PeerJS

圖片

PeerJS[16]的存在時間幾乎和WebRTC一樣長。在相當長的一段時間裏，其代碼庫一直沒有得到維護或更新以適應所支持的瀏覽器。這種狀態似乎延續到了今天。

這個項目似乎專注於龐雜的單服務器開發，而沒有考慮水平的分佈式擴展。但對於大部分人來説，應該足夠了。

多年以來，PeerJS幾經易手並更換維護者，今年年初還在招募維護者[17]。

圖片

事不宜遲，讓我們開始談錢時刻吧！

談錢時刻

如果有人決定使用PeerJS並將它直接集成到自己的應用怎麼辦？

  • 沒有官方付費支持選項。

  • 沒有官方替代方案支付定製化的開發費用。

  • 代碼庫規模很小，所以如果你瞭解WebRTC，那麼這些挑戰就不是什麼大問題。

• simple-peer

圖片

Simple-Peer早期由Feross推動，它是另一個僅專注於P2P的“純WebRTC”庫。如果Simple-Peer適用於你的應用場景，非常好，它目前已經成熟並完善。大部分情況下，你的應用場景會隨着時間不斷髮展。

2022年，它只收到了少量維護commit[18]，2021年收到的commit也不多。在使用PeerJS時需要注意的問題同樣適用於Simple-Peer。如果你要在二者之中選擇一個，選擇Simple-Peer吧，因為它的代碼是更地道的JavaScript。

談錢時刻

可以閲讀PeerJS的談錢時刻，因為它們所遵循的規則是一樣的。

• Matrix

圖片

Matrix[19]是一個“用於安全、去中心化通信的開放網絡”。它具有開放標準，同時背後也有商業廠商支持（Element[20]）

新穎時髦的Matrix試圖彌補SIP和XMPP的缺陷，但是它最主要的設計為客户端和服務端的架構，且它的實現類似於把網絡和UI包含在內的Slack。Matrix具有分散的架構和實現，從而更易擴展。

這裏產生了一些分歧。Tsahi認為Matrix是一個很棒的選擇，而Philipp卻沒那麼激動。Matrix從full mesh遷移到Jitsi[21]，最近又遷移到原生SFU[22]。所以對於有些人來説，它的WebRTC歷程有些曲折。

Matrix背後有一家公司支持，但這家公司有自己的傾向（與Slack競爭的私心）。

談錢時刻

如果有人決定使用Matrix並將它直接集成到自己的應用怎麼辦？

  • 沒有官方付費支持選項。

  • 沒有官方替代方案支付定製化的開發費用。

  • 儘管如此，Matrix上有一個Jobs Room[23]，你可以在上面搜索付費幫助。

• GitHub“叢林”中的其他項目

在創作這篇文章的時候，有26121個repository提到了WebRTC[24]。你在閲讀這篇文章時，這一數目還在增加。

在這些混亂的repository中，特別突出的並不是很多，所以很難弄清哪些項目更適合你，尤其當你的需求會持續下去的時候。如果你正在尋找獲得足夠支持並具備繁榮社區的項目，那更是難上加難。

WebRTC的SFU和媒體服務器

媒體服務器和SFU[25]是另一組重要的開源WebRTC項目。

信令服務器處理設置實際會話的對等通信，而媒體服務器聚焦在信道——我們想要發送的實際數據——音頻和視頻流，提供實時視頻流和處理。每當你需要羣組會話、廣播或錄製（假設你希望在應用程序中加入視頻通話或視頻會議）時，你最後都會使用媒體服務器。

下面是商業方面：

• Janus、Jitsi、mediasoup和Pion

我曾在《2022 WebRTC發展趨勢分析》中詳細介紹過這些項目，相關內容可以參見下圖。

圖片

Janus、Jitsi、mediasoup和Pion在商業解決方案中非常有用且流行。讓我們使用分析其他WebRTC開源項目的方法來分析它們。

• Janus

圖片

  • 來自meetecho的官方付費支持。

  • 你可以向meetecho支付諮詢和（付費）開發費用。從經驗來看，他們大部分人都很忙，這也意味着他們對最終合作的人選非常挑剔。

  • Janus生態規模足夠大，並且還有其他人為其提供開發服務。

• Jitsi

圖片

可以將Jitsi看作其自己的平台：

  • Jitsi 的核心是Jitsi Videobridge，與周圍的其他組件共同組成了Jitsi Meet視頻聊天應用程序。

  • 它還包括一個託管的CPaaS服務產品：8×8 JaaS[26]。

談錢時刻

  • 幾年以前8×8收購了Jitsi，這也説明它沒有官方付費選項。

  • ‍‍‍‍‍‍‍‍同樣，也無法進行付費的定製化開發。

  • Jitsi生態規模足夠大，並且還有其他人為其提供開發服務。

  • 和Matrix（Element 提供付費託管）一樣，8×8 JaaS 為Jitsi（CPaaS）提供付費託管。還有Jitsi Meet，它本質上是建立在Jitsi之上的免費託管服務。‍‍‍‍‍‍‍‍

• mediasoup

圖片

  • mediasoup由在Around[27]工作的兩名開發人員維護，這也説明它沒有付費支持官方選項。

  • 同樣，也無法使用定製化開發。

  • mediasoup的生態意味着你也可以找到它的開發人羣。

• Pion

圖片

  • 我們在上文介紹WebRTC客户端時已經討論了Pion。

  • 假設媒體服務器也是如此。

  • 你唯一頭疼的是選擇使用哪個基於Pion編寫的媒體服務器。

需要明確的是，在上述的所有情況中，如果讓廠商幫助你解決那些無人維護的特定媒體服務器代碼庫問題，那就意味着實現質量方面的結果將非常不確定。也就是説，你很難搞清楚是在和誰合作。

• Kurento的失敗

圖片

Kurento媒體服務器已經死了，連它背後的那羣開發者都去開發OpenVidu（下文會介紹）了，並讓OpenVidu在mediasoup之上運行。

千萬別碰它。

Kurento已經沉寂多年，但有人依然想使用它。先去搞清楚它的狀況吧。

• 抽象概念的更高層次

更高層的概念開源項目努力成為某種平台。在 WebRTC 生態系統中，它們最關注的是在開源媒體服務器之上提供一層工具。OpenVidu和LiveKit很可能是其中最值得關注的兩個項目。

• OpenVidu

圖片

OpenVidu[28]是一種包括UI、實現了房間服務的抽象層。

Kurento被收購後，團隊剩下的人創建了OpenVidu。他們甚至逐漸採用mediasoup作為使用的媒體服務器[29]，而將Kurento置於一邊。

談錢時刻

和我們之前所看到的很多開源解決方案都不同，OpenVidu看似有其自己的商業模式：

  • 具備官方商業支持。

  • 提供託管商業計劃以及諮詢和開發工作。

• LiveKit

圖片

LiveKit[30]提供“開源WebRTC基礎設施”，即Pion SFU之上的管理層。

我一直不太理解LiveKit的商業模式。他們並不只是一個開源項目，還是一家公司。因此，他們需要收入維持下去。

也許他們從採用LiveKit的企業那裏獲取支持和開發收入，但很難從他們的網站看出來。

其他一些不太流行的WebRTC開源選擇

其他公司也提供商業解決方案（本質上為專用），有些人將它們作為本地替代方案：這些公司提供軟件和支持，但你需要部署和維護。

這種解決方案，或者非常合適，或者會帶來災難，尤其是當這樣的廠商決定轉移或者離開市場時。所以遇到這類解決方案一定要謹慎。

WebRTC開源是時候發展起來了嗎？

圖片

本文是一篇很長的WebRTC開源現狀概覽文章，我想我們可以達成一致的是：WebRTC開源目前的狀況不太妙。

  • WebRTC已經存在超過10年。

  • WebRTC開源項目不斷髮展。

  • 技術愛好者和專業技術人員都在使用這些項目。

  • 這些開源項目存在於為數百萬用户的商業應用中。

  • 但它們卻很少提供付費幫助支持。

  • 不知何故，其市場並沒有在商業方面獲得發展。

我們認為WebRTC開源並沒有真正成長起來。我們希望看到更加成熟的市場，這樣才能為企業和企業家提供更多更好的商業解決方案。

參考文獻：

[1] http://twitter.com/hcornflower

[2] http://webrtccourse.com/

[3] http://bloggeek.me/webrtc-insights/

[4] http://bloggeek.me/using-open-source-license/

[5] http://webrtccourse.com/developers/

[6] http://archive.fosdem.org/2021/schedule/event/webrtc_shipping/

[7] http://pion.ly/

[8] http://www.linkedin.com/in/sean-dubois/

[9] http://github.com/aiortc/aiortc

[10] http://github.com/webrtc-rs/webrtc

[11] http://gstreamer.freedesktop.org/

[12] http://github.com/coturn/coturn

[13] http://bloggeek.me/managed-webrtc-turn-speed/

[14] http://github.com/coturn/coturn/issues/915

[15] http://xmpp.org/extensions/xep-0215.html

[16] http://peerjs.com/

[17] http://github.com/peers/peerjs/issues/938

[18] http://github.com/feross/simple-peer/commits/master

[19] http://matrix.org/

[20] http://element.io/

[21] http://www.youtube.com/watch?v=tVh0vYnBM4k

[22] http://matrix.org/blog/2022/08/05/this-week-in-matrix-2022-08-05

[23] http://matrix.org/docs/guides/matrix-jobs-room

[24] http://github.com/search?q=webrtc

[25] http://bloggeek.me/webrtcglossary/sfu/

[26] http://jaas.8x8.vc/

[27] http://www.around.co/

[28] http://openvidu.io/

[29] http://openvidu.medium.com/a-new-era-for-openvidu-better-perfomance-and-media-quality-with-mediasoup-24d46a9eb10d

[30] http://livekit.io/

作者簡介：

Tsahi Levent-Levi：WebRTC專家，曾為testRTC的聯合創始人和CEO，現為Spearline公司testRTC的產品負責人。Tsahi擁有多年WebRTC技術培訓經驗，並擁有自己的技術博客BlogGeek.Me，你可以到這裏（http://webrtccourse.com/）瞭解和學習他的課程。

致謝：

本文已獲得作者Tsahi Levent-Levi授權翻譯和發佈，特此感謝。

原文鏈接：

http://bloggeek.me/state-of-webrtc-open-source-projects/

圖片

「」