每一項成功技術的興起都會有一個契機。某一時刻發生一件起催化作用的事,通常是外部的,使它從一個有前途的好點子變成我們生活中一種不可或缺的事物。近期最能體現這點的例子或許就是 2007 年 iPhone 問世,促使了雲端的誕生。智慧型手機為小型開發商開創了龐大的目標市場;即便是大型開發商,他們的客戶群也有了爆炸式增長,惟有使用公共雲端基礎結構才能應對這樣的增長。這兩者都希望能夠專注於開發優秀的應用程式,不必為其基礎結構而操心。

去年 COVID-19 爆發期間,即時通訊也同樣迎來爆發。溝通交流是所有組織的命脈。2020 年之前,大多數的溝通發生在世界各地辦公室內的會議室裡。然而在去年三月,出現了翻天覆地的變化。這些會議室突然變得空空如也。往後的 18 個月,這種工作方式的巨變依然持續著。

毋庸置疑,許多組織無法離開 Slack、Zoom 和 Teams 這樣的即時協作工具,儘管如此,我們認為如今存在的那些通訊工具仍然只是冰山一角。環顧四周,一種感覺縈繞在心頭:我們即將迎來一場創新風暴,促使組織能夠在遠端環境 (或者至少是混合環境) 中自由地通訊。

有鑑於此,我們今天隆重推出 Cloudflare 的即時通訊平台。這是一套全新的產品,旨在幫助您構建下一代即時互動式應用程式。不論是一對一視訊通話、群組語音聊天還是視訊會議,即時通訊的需求只會與日俱增。

運行可靠並可擴充的即時通訊平台,需要建設一個規模龐大的網路。您需要在多個地區讓您的網路邊緣與使用者相隔僅毫秒,確保每個人連線時的體驗始終是低延遲、低丟包率和低斷續的。設立一個骨幹網路來疏導網際網路流量擁堵。基礎結構要能高效擴充,以同時為數千參與者服務。然後,您還需要部署媒體伺服器,編寫業務邏輯,管理多個用戶端平台,並且讓所有一切順暢運作。我們一定能夠幫助您解決這些需求。

今天,我們將推出名為 WebRTC Components 的產品,您將能夠利用 Cloudflare 的邊緣網路來改善基於 WebRTC 的現有視訊和音訊應用程式的連線。這包括擴充到數千 (乃至數萬) 參與者,利用我們的 DDoS 緩解保護您的服務免受攻擊,以及實施基於 IP 和 ASN 的存取原則,全部只需點擊幾下便可。

即時為何稱為「即時」?

即時通常指的是 500 毫秒內發生的通訊:也就是說,速度堪比資料包遍歷連線全球的光纖網路。2021 年,大多數即時音訊和視訊應用程式使用 WebRTC,這一套開放標準和瀏覽器 API 定義了如何透過 UDP 來連線、保護和傳輸媒體和資料。其設計宗旨是帶來更出色、更靈活的雙向通訊,勝過我們目前主要依賴的基於瀏覽器型通訊協定 HTTP。而且,由於 WebRTC 支持位於瀏覽器內,使用者不需要自訂用戶端,開發人員也不需要構建這些用戶端:唯一需要的是瀏覽器。

重要的是,我們發現隨著組織工作方式改變 (我們也不例外),對跨越多個時區和地區進行可靠即時通訊的需求有了巨大增長。

那麼,在實務上,即時的重要性何在?

  • 一對一通話 (例如 FaceTime):我們已經習慣透過傳統電話進行幾乎是瞬間的通訊,沒有理由倒退一步。
  • 群組通話和會議 (Zoom 或 Google Meet):即使只有幾秒鐘延遲,也會導致互相搶話的問題。
  • 社交視訊、遊戲和體育:您可不想因為串流掉幀或需要緩衝,而比實況落後 10 秒或錯過比賽中的關鍵時刻。
  • 互動式應用程式:瀏覽器内 3D 建模、手機上擴增虛擬實境,甚至是遊戲直播,這些全都需要即時進行。

我們認為,對於即時應用程式,如今接觸的都只是皮毛。部分原因在於,將即時應用程式擴充到數千使用者也需要全新的基礎結構範例,對網路的要求也高於傳統的基於 HTTP 型通訊。

登台亮相:WebRTC Components

我們今天啟動 WebRTC Components 的封閉測試。運行集中式 WebRTC TURN 伺服器的團隊可以利用它將負載卸到 Cloudflare 的分散式全球網路,以提升可靠性,擴充到更多使用者,並且減少花費在基礎結構管理上的時間。

TURN 全稱為 Traversal Using Relays Around NAT,旨在解決 WebRTC 的點對點原始伺服器的實行缺點。WebRTC 曾經是 (目前依然是!) 一種點對點技術,但在現實中,由於營運商級 NAT、企業 NAT 和防火牆的原因,建立可靠點對點連線的難度依然較高。另外,每一個對等點都受到本身網路連線的桎梏,在傳統的點對點網路中,參與者會很快發現自己的網路連線達到飽和,因為他們必須要從每個其他點接收資料。在包含多種裝置 (行動或桌面裝置) 和網路 (從高延遲 3G 到高速光纖) 的混合環境中,擴展到稍多一些對等點也會變得異常困難。

將運行 TURN 服務的位置從自己的基礎結構轉移到網路邊緣,可以帶來更優質的連線。Cloudflare 運行一個覆蓋 250 多個城市的 Anycast 網路,這意味著我們與您的使用者距離非常近,不管他們身在何方。也就是說,當使用者連線 Cloudflare 的 TURN 服務時,他們可以與 Cloudflare 網路建立非常好的連線。服務部署就位後,我們就能利用自己的網路和專屬骨幹網為您提供超凡的連線效能,全程貫通至通話的另一方。

甚至更好:不必再擔心規模。眾所周知,擴充 WebRTC 基礎結構並非易事:您需要確保在適當位置上擁有恰當的容量。Cloudflare 的 TURN 服務可以自動擴充,當您想要更多端點時,只需調用一個 API 便可。

使用者嘗試通過集中式基礎結構,利用 WebRTC 在公共網際網路上啟動媒體工作階段。
使用者透過 Cloudflare 的分散式全球邊緣網路進行連線。

當然,WebRTC Components 是在 Cloudflare 網路基礎上構建的,可獲得其 100 Tbps 網路提供的 DDoS 保護。從現在開始,您只需調用幾個 API,就能將可擴充並且安全的作業級 WebRTC 中繼器部署到全球各地。

以開發人員為先的即時平台

然而,正如 Cloudflare 常說:我們才剛剛開始。若要為一對一和小規模群組通話構建即時服務,託管的可擴充 TURN 基礎結構是一個關鍵構建塊,特別是對於一貫自行管理基礎結構的團隊而言。不過,當您開始添加更多參與者時,事情會迅速變得更加複雜

不論是管理每個用戶端都在發送並接收的串流 (用 WebRTC 的說法是「軌」) ,以確保通話品質,或是管理決定誰能在大型活動中發言或廣播的權限系統,以及/或者構建在媒體體驗基礎上、支援聊天和互動的信號基礎結構,有一點非常明確:還有許多問題待解決。

針對這一點,讓我們稍微透露一下未來方向:

  • 優先考量開發人員的 API,不再需要管理和配置低級基礎結構、身分認證、授權和參與者權限。從參與者、聊天室和頻道角度來思考,而不再需要瞭解複雜的 ICE、對等連線和媒體通道。
  • Cloudflare for Teams 整合,以支援組織單位的存取原則:對於如今公司大會需要以遠距方式舉辦的現狀,這一點意義重大。
  • 輕鬆連線任何輸入和輸出源,包括廣播到傳統的 HTTP 串流用戶端、透過 [Stream Live] (https://blog.cloudflare.com/stream-live/) 錄影以實現按需求播放,以及利用 Stream Connect 或未來的通訊協定 (如 WHIP) 從 RTMP 來源擷取視訊等。
  • 透過 Cloudflare Workers 嵌入無伺服器功能:例如讓參與者事件 (如加入或離開) 觸發 Workers,或利用 Durable Objects 和 WebSockets 等建立有狀態聊天和協作工具。

… 這不過是開始。

我們也在尋找雄心勃勃、希望發揮長才協助我們構建 RTC 平台的工程師。如果您對構建下一代即時互動應用程式感興趣,歡迎加入我們

如果您有興趣與我們一起加強世界各地的聯繫,並且您也在努力擴展現有的一對一即時視訊和音訊平台 (面向幾百或幾千個同步使用者),歡迎您報名參加 WebRTC Components 封閉測試。我們特別想跟剛開始使用即時通訊且樂意與我們密切往來的團隊。