隨著直播的發展，直播實時互動性變得日益重要。又拍雲在 webrtc 的基礎上，憑藉多年的開發經驗，結合當下實際情況，開發 uprtc 系統，解決了網路延時、併發量大、客戶端解碼能力差等問題。
2023年5月，google 花費6820萬美元收購擁有編譯碼、回聲消除等技術的 gips 公司。之後谷歌開源了 gips 的技術，與相關機構 ietf 和 w3c 制定行業標準，組成了現有的 webrtc 專案。
同時webrtc 並不是乙個孤立的協議，它擁有靈活的信令，可以便捷的對接現有的sip 和**網路的系統。
成立uprtc專案前，又拍雲經過多重調研和考慮，選擇了 webrtc，主要有三個原因：
1. webrtc 是開源、 免專利費的專案， 大大節省了開發時間和成本；
2. webrtc 由 google 主導, 技術非常先進；
3. safari 等瀏覽器以及其他終端逐漸加強對 webrtc 技術的支援。
傳輸層協議：底層傳輸協議為 udp
**協議：srtp / srtcp
資料協議：dtls / sctp
p2p 內網穿透：stun / turn / ice / trickle ice
信令與 sdp 協商：http / websocket / sip、 offer answer 模型
△ 圖1：webrtc內部結構
圖2是 webrtc 涉及到的協議棧，webrtc 核心的協議都是在右側基於 udp 基礎上搭建起來的。
其中，ice、stun、turn 用於內網穿透, 解決了獲取與繫結外網對映位址，以及 keep alive 機制。
dtls 用於對傳輸內容進行加密，可以看做是 udp 版的 tls。由於 webrtc 對安全比較重視，這一層是必須的。
srtp 與 srtcp 是對**資料的封裝與傳輸控制協議。
sctp 是流控制傳輸協議，提供類似 tcp 的特性，sctp 可以基於 udp 上構建，在 webrtc 裡是在 dtls 協議之上。
rtcdatachannel 用來支援端到端的任意二進位制資料傳輸。
△ 圖2：webrtc 協議棧
為了使 webrtc 協議更適用於實時互動直播，又拍雲在 webrtc 協議的基礎上進行改造優化，搭建了又拍雲 uprtc 。支援多種應用場景，包括一對
一、一對多和多對多等應用場景。
因為又拍雲擁有效能優異的 cdn 資源，將 webrtc 改造成伺服器中轉模式之後，採用完全分布式系統，部署到全國所有邊緣節點，通過內部加速網路 utun 加速，將**、併發壓力轉移到服務端，保證 uprtc 終端可以承受更多路併發。
以移動裝置從 wifi 網路切換到 4g 網路為例，又拍雲伺服器可以察覺到頻寬變化，統計丟包和延時，進行動態位元速率調整，保證在弱網環境下也能進行正常通話。
又拍雲設計了一套靈活高效的業務信令，用於敏感信令鑑權。
圖3為 uprtc 技術組成：
**通道、資料通道，信令通道；
資料加密模組；
位元速率自適應控制模組；
又拍雲加速網路；
p2p打洞服務；
房間應用業務；
機械人（自動管理功能和互動功能）。
△ 圖3：uprtc技術組成
雖然 webrtc 源**相對成熟，但是在實際應用中依舊需要解決以下問題：
1.音訊處理過程中消耗 cpu 過高；
3.安卓端 webrtc 原始碼對h.264支援並不全面，僅預設支援高通的晶元；
4.服務端架構過程中需要加入位元速率自適應演算法，動態控制總位元速率頻寬在 2m 以內。
w3c api 相關文件:
ietf 協議相關文件:
can匯流排實時通訊排程技術
下面的討論主要針對主從式。原始的辦法是採用輪詢方式，無法保證系統的確定的時態特性，對通訊的滯後無法 和控制。因此要採取恰當的排程策略。1。通訊資料的實時性 通訊是用來節點之間交換資料，這些資料 1 實時資料 包括週期實時資料和非週期性實時資料 2 非實時資料 資料的實時性是以資料的截止期來表示的,所...
基於WebRTC的直播CDN
4.2 拉流 5 最短回源路徑 6 業務系統 7 一些特性 問題 主要特性 整體上這個系統是乙個典型的cdn結構，主要包含排程系統 cdn源節點和cdn邊緣節點。節點服務列表 服務功能 transfmtd 轉格式服務，主要負責webrtc的rtp流與rtmp流的互轉。janus webrtc流 服務...
WebRTC的擁塞控制技術
對於共享網路資源的各類應用來說，擁塞控制技術的使用有利於提高頻寬利用率，同時也使得終端使用者在使用網路時能夠獲得更好的體驗。在協議層面上擁塞控制是tcp的乙個總要的組成部分 但是對於非面向鏈結的傳輸層協議，如udp，其在協議層面上並沒有對擁塞控制進行強制性的要求，這樣做保證了最優的傳輸效能，且在擁塞...