WebRTC現在已經成為W3C和IETF的標準

WebRTC經過多年的發展，現在已經解決各廠商大多數的分歧，成為W3C和IETF的標準

文/李建興 | 2021-01-28

W3C和IETF兩大標準制定組織，宣布WebRTC（Web Real-Time Communications，WebRTC）已經成為官方標準，可在網頁平臺良好地支援聲音及影像通訊。

WebRTC是由網頁即時通訊JavaScript API和一組通訊協定組成，可讓任何網路上的連接裝置，成為網頁上潛在通訊端點，其為瀏覽器、行動裝置和桌面應用程式，提供即時視訊通話能力。Google在2009年的時候開始創建WebRTC，並且之後對外開源，該程式碼庫也整合在Chrome中，供WebRTC應用程式使用，而之後瀏覽器供應商及其他網路公司，包括Mozilla、微軟、思科和Ericsson，便與Google一起在W3C和IETF中，著手進行WebRTC標準化的工作。

在2013年的時候，Mozilla與Google首次透過WebRTC，展示在兩個瀏覽器間，建立起視訊通話，但在之後，隨著標準的發展，許多架構上的討論，導致不同瀏覽器實作出現差異，進而產生相容性和互通性的問題。幸好近年WebRTC標準逐漸定案，大多數的分歧現在已經解決，WebRTC規範也隨附相容性測試工具，而且瀏覽器都最大程度調整了實作方式，現在網頁應用程式開發人員已經渡過那段，需要為不同瀏覽器調整程式的時期，終於迎來只要支援唯一標準的時刻。

WebRTC可應用在任何網站，任何應用程式中，建構即時聲音與影像通訊系統。WebRTC框架提供建構組塊，供開發人員利用這些組塊，在包括遠端教育、遠端醫療、娛樂和遊戲等應用程式，添加視訊通訊功能。由於WebRTC標準化且免授權金的特性，瀏覽器和各種裝置平臺，都可以內建WebRTC影音通訊系統，因此用戶也不需要額外安裝套件，或是下載單獨的應用程式。

目前WebRTC被廣泛地部署為通訊平臺，在瀏覽器、桌面和行動平臺，提供視訊和協作功能，官方提到，特別是在2020年全球對旅遊與接觸限制，WebRTC被應用在更廣泛的用途上。由於商業和家庭對影像通訊的需求，增加了WebRTC的採用率，企業透過WebRTC進行培訓、訪談或是會議，另外，無論是醫療、國防、學術、社交和娛樂等領域，也都在嘗試使用WebRTC建構多元應用。

官方表示，WebRTC的使用範圍，已經從最初的核心設計，逐漸擴展朝向支援多元應用發展，IETF多個工作組開始將WebRTC，融入到原本的工作基礎上，包括QUIC、HTTPBIS，並且試圖將其應用到單向媒體廣播中。W3C WebRTC工作組也開始研究下一版的WebRTC，計畫要在有中繼伺服器的視訊會議中，支援端到端加密，並且利用機器學習即時處理聲音與影像摘要，還要更好地支援物聯網應用。

資料來源：https://www.ithome.com.tw/news/142505

📜 [專欄新文章] libp2p — 模組化的點對點網路協議
✍️ Ken Lin
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

libp2p — 模組化的點對點網路協議

可重用的輪子

『不要重複造輪子』，是在軟體開發時，經常被引用的一句話。

這句話隱含的意義是，盡可能的去重用（reuse）其他人分享的開發成果，因為很多的經驗及知識，就是在這樣的重用過程中，逐漸的被累積及驗證。而許多被廣泛重用的輪子，往往就這樣成為某個特殊領域中共用的基石，進而加速了其他專案開發時的迭代過程。

本次CrossLink Taipei 2019的研討會中，也出現了一個這樣的輪子，那就是libp2p專案。

分佈式應用的共業

傳統的中心化網路架構當中，每一個參與的節點，其Server與Client的角色是確立的，因此封包在路由傳遞時也相對單純，對於開發者而言，大家也都非常熟稔這樣的架構。

而在分佈式的網路架構當中，每一個節點都同時肩負了Server與Client的角色(或者換一個說法，不再有Server-Client的區別)，再加上各種異質的網路環境與網路通訊協議，開發者往往要耗費許多資源來解決這些網路底層的通訊問題，例如NAT穿透、加密傳輸等等。

如果這些難題，一再的困擾著不同的開發者，那麼有沒有一種可能，可以把這些難題所需要的解決方案集合在一起，方便大家去重複使用並改進？libp2p的出現，便是這個問題的答案。藉由高度模組化的設計，開發者可以方便的取用自己所需要的部分模組，並在現有的模組上疊加自己額外的應用邏輯，以適應各種不同的應用場景。

由於其高度模組化的特性，使得libp2p受到許多知名專案的青睞，紛紛使用了libp2p作為其底層網路框架，例如Ethereum 2.0、Palkadot、Filecoin、0X等等。

libp2p原先是IPFS專案中的網路框架，後來抽出變成一個獨立的專案。

libp2p的特色

以下所提到的各種libp2p特色，很多都以模組的形式被實作，開發者可選擇適合的模組，進而開發出符合其應用場景的服務。

具有兼容性的定址方式

libp2p使用了類似檔案路徑的概念(PLAN9 Ubiquitous Filesystem)，為每一個行程(process)定義了專屬的位址。這種定址方式，可以增加行程定址的兼容性，假設某個行程改用了新的網路傳輸協議(例如從ipv4改為bluetooth)，可以很方便的以相同的定址結構去表達新的位址。

以目前常見的ipv4位址為例，假設某個節點是以ip 1.2.3.4以及port 80提供了服務，在libp2p中其位址可表示為/ip4/1.2.3.4/tcp/80。

支援多種傳輸協議

針對目前常見的傳輸協議，libp2p也實作了相對應的模組，例如：TCP、QUIC、WebSockets、WebRTC。在未來，libp2p預計還會支援Bluetooth、uTP、UDP，或者目前尚未發明的新協議(歸功其兼容性的定址方式)。

可升級的傳輸協議

在libp2p的設計當中，一個行程與另一個行程建立連線時，首先會以某個底層協議作為原始連線(raw connection，例如TCP協議)。一旦原始連線建立完畢，兩個行程可以進一步依據他們的需求進行協調，決定是否將原始協議升級(upgrade)為另一個協議連線(capable connection)，例如將單純的TCP協議升級為具有加密性質的連線。

多路複用

有時候在兩個節點之間建立一個連線，需要不少的成本(像是需要穿透NAT、經過多次的交握確認後才能建立連線)，如果能夠重複使用已經成功建立的連線，兩個節點之間就能以更有效率的方式實現異質的資料傳輸。舉例來說，兩個節點可以在同一個TCP連線上，進一步的產生不同的串流(stream)。

協議協調

由於libp2p支援多種傳輸協議，並且能夠多路複用，兩個節點在互相傳輸資料之前，便需要有一套機制去互相溝通，確定兩者要以哪種協議進行資料的傳輸，這便是協議協調。

目前的協議協調機制是multiselect 1.0，libp2p接下來會將協議協調機制升級為更有效率的multiselect 2.0。

節點發現與訊息傳播

在建立分佈式應用的時候，如何有效率的尋找節點(節點發現)是建立一切服務的起點，能夠找到節點，才能進一步和節點建立連線，接著才能建構其上的應用。libp2p提供了數種節點發現的實作(DHT、Randezvous、mDNS等等)。

除了節點發現，如何進行訊息傳播也是建立一個分佈式應用必須考慮的事情。在這邊要特別提起PubSub這個訊息傳播模式。這是一種類似MQTT的發布-訂閱(Publish-Subscribe)模式，允許訊息以M-to-N的方式在網路中傳遞，這種傳播模式是非同步(asynchronous)。和MQTT不同的是，libp2p是分散式的，並不需要一個中心化的broker來負責訊息的路由(routing)。

目前PubSub提供數種訊息路由演算法，包括floodsub、gossipsub等等。在Ethereum 2.0也將會採用PubSub作為其訊息傳播模式。

NAT穿透及中繼

現今的網路架構中，NAT無所不在，而這也是點對點連線時最大的困擾。libp2p實作了NAT穿透，而對於那些無法進行NAT穿透的節點，libp2p另外提供了中繼技術(relay)來作為補強方案。

結語及後記

以上所描述的libp2p特色，是在參與CrossLink Taipei 2019研討會時，印象較為深刻的幾點，尚有其他特色沒有節錄於本文之中。除此之外，各項特色的描述多半以重點式的形式紀錄，很多細節仍有待深入挖掘。

在撰寫本文時，筆者參考了許多前人的貢獻，其中有不少是來自於CrossLink Taipei 2019 的線上共筆，謝謝這些參與共筆的志工。除此之外，也要特別感謝Taipei Ethereum Meetup的朋友Kevin，提供了不少寶貴的建議以及實作經驗。

參考資料

https://segmentfault.com/a/1190000015410582

https://zhuanlan.zhihu.com/p/33535984

https://ethfans.org/posts/why-libp2p

https://medium.com/r/?url=https%3A%2F%2Fgithub.com%2Fmultiformats%2Fmultiaddr

libp2p — 模組化的點對點網路協議 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌