㈠ RTC技術（WebRTC）
RTC（Real time communication）實時通信，是實時音視頻的一個簡稱，我們常說的RTC技術一般指的是WebRTC技術，已經被 W3C 和 IETF 發布為正式標准。由於幾乎所有主流瀏覽器都支持 WebRTC 標准 API ，因此也讓瀏覽器之間無插件化的音視頻互通成為可能， 大大降低了音視頻開發的門檻，開發者只需要調用 WebRTC API 即可快速構建出音視頻應用。
更廣義的RTC技術，不單單局限於音視頻，包括IM、圖片、白板、文件共享等富媒體在內的實時交互也屬於RTC技術范疇。
直播中我們關心的幾個點：延遲、質量、成本等。
傳統rtmp直播痛點：TCP，延遲高、擁塞導致卡頓問題較多（質量問題）。
互聯網網路復雜、延時敏感、實時音視頻流暢度及清晰度較低以和運營成本較高等。
沒有一項技術能兼顧並解決直播中的所有問題，RTC是時延、流暢、質量、成本等的平衡，成為技術選型落地的模型。
我們在做RTC應用的時候，不應該一味地追求一些點，不應該在某些單點上用力過猛（比如單純的追求抗丟包能力），導致最終的效果會打很多折扣，不能只著眼於延遲低，畫質高，應該把視角放在用戶的整體體驗上。
RTMP只是TCP上的一個標准協議，所以接入是一個標准體系，推流端可以是OBS這種直播軟體工具，也可自開發rtmp推流工具，播放端可以是Flash播放器（Adobe 2020 12月份已經棄用）、服務端有技術成熟的CDN技術和設施進行分發、Native的播放器或者flv.js/hls.js這種開源播放器組件，遵循rtmp、flv、hls標准即可，接入成本比較低。而一個完善的RTC服務應用，需要從推流端、服務端、到拉流端，一整套完整的全鏈路閉環技術。
視頻會議、在線教育小班課、大班課、1v1視頻連麥、多人視頻連麥互動、語音聊天室、在線面試、在線醫療、雲游戲、智能家居、在線簽約、在線K歌等，遍地開花。
比如Zoom、騰訊會議、釘釘會議、微信音視頻聊天
互動連麥+服務端轉推rtmp至CDN，CDN分發給觀眾。
聲網、騰訊雲音視頻、即構、阿里雲RTC、華為雲RTC、微吼VRTC、網易雲信RTC、保利威RTC、Ucloud RTC、融雲RTC、拍樂雲等。
5G時代RTC技術滿足實時通信的同時，將賦能 AI、AR、VR、智能家居、雲游戲、遠程輔助駕駛等場景化落地。
㈡ WEBRTC基本概念
AIMD英文全稱：Additive Increase Multiplicative Decrease。TCP/IP模型中，屬於[運輸層]，為了解決[擁塞控制]的一個方法，即：加性增，乘性減，或者叫做「和式增加，積式減少」。
aimd controller是TCP底層的碼率調節概念，但是WebRTC並沒有完全照搬TCP的機制，而是設計了套自己的演算法。
如果處於Incr狀態，增加碼率的方式分為兩種：一種是通信會話剛剛開始，相當於TCP慢啟動，它會進行一個倍數增加，當前使用的碼率乘以系數，系數是1.08；如果是持續在通信狀態，其增加的碼率值是當前碼率在一個RTT時間周期所能傳輸的數據速率。
如果處於Decrease狀態，遞減原則是:過去500ms時間窗內的最大acked bitrate乘上系數0.85,acked bitrate通過feedback反饋過來的報文序號查找本地發送列表就可以得到。
aimd根據上面的規則最終計算到的碼率就是基於延遲擁塞評估到的bwe bitrate碼率。
WebRTC在發送端收到來自接收端的RTCP RR報文，根據其Report Block中攜帶的丟包率信息，動態調整發送端碼率As。
基於延遲的碼率控制運行在接收端，WebRTC根據數據包到達的時間延遲，通過到達時間濾波器，估算出網路延遲m(t)，然後經過過載檢測器判斷當前網路的擁塞狀況，最後在碼率控制器根據規則計算出遠端估計最大碼率Ar。然後，通過RTCP REMB報文返回Ar等到發送端。
發送端綜合As、Ar和預配置的上下限，計算出最終的目標碼率A，該碼率會作用到Encoder、RTP和PacedSender等模塊，控制發送端的碼率。
GCC演算法充分考慮丟包率和延遲對碼率的影響，在實時通訊應用(如視頻會議)中能夠發揮良好效果。然而，在某些特定應用場景下(比如實時在線編輯)，GCC演算法的表現不太讓人滿意，主要體現在它應對峰值流量的能力上，具體表現在：
1）演算法一開始基於Increase狀態增加碼率，當檢測到Decrease狀態時調用Ar[t(i)] = Alpha * Rr[t(i)]，這個時候實時碼率Rr(ti)可能遠小於Ar[t(i-1)]，這樣在後續過程中Ar處於較低水平；此時若有視頻關鍵幀沖擊，則數據包大量在PacedSender的隊列中排隊，造成較大排隊延遲。
2）基於1）中論述的情況，碼率估計模塊反饋給Codec的編碼碼率很低，但編碼器需要編碼關鍵幀時，內部的碼率控制模塊控制出的最小碼率仍然大於反饋碼率。這兩種情況都會造成較大的發送端排隊延遲，進而在接收端造成較大的JitterBuffer延遲，最終導致端到端延遲到達500ms的水平，這在實時在線編輯應用中是無法容忍的。
基於此，Google官方從WebRTC M55開始引入新的碼率估計演算法，把所有碼率計算模塊都移動到發送端，並採用全新的Trendline濾波器，基於碼率探測機制快速准確地估計出實時碼率。
WebRTC在評估延遲差的時候不是對每個包進行估算，而是採用了包組間進行延遲評估，這符合視頻傳輸（視頻幀是需要切分成多個UDP包）的特點，也減少了頻繁計算帶來的誤差。那麼什麼是包組呢？就是距包組中第一個包的發送時刻t0小於5毫秒發送的所有的包成為一組，第一個超過5毫秒的包作為下一個包組第一個包。
㈢ WebRTC概念簡介
WebRTC（Web Real-Time Communication）。Real-Time Communication，實時通訊。
WebRTC能讓web應用和站點之間選擇性地分享音視頻流。在不安裝其它應用和插件的情況下，完成點對點通信。
WebRTC背後的技術被實現為一個開放的Web標准，並在所有主要瀏覽器中均以常規JavaScript API的形式提供。對於客戶端（例如Android和iOS），可以使用提供相同功能的庫。 WebRTC是個 開源項目 ，得到Google，Apple，Microsoft和Mozilla等等公司的支持。2011年6月1日開源並在Google、Mozilla、Opera支持下被納入萬維網聯盟的W3C推薦標准。
WebRTC包括一系列API和相互關聯的協議來實現通信。
Voice over Internet Protocol，在網路上傳輸聲音消息的技術。
例如網路音頻通話。或者叫做IP電話，寬頻電話。使用VoIP技術的一大原因是費用低。
Network address translation，網路地址轉換。
NAT能給你的設備一個公共IP地址。一個路由器（router）有一個公共IP地址，每個連接到路由的設備有一個私有的IP地址。
設備發送請求時，會從一個特定埠，通過私有IP發送到路由的公共IP。這樣每個設備在網上不需要都有一個公共IP地址，但也能被其它設備發現。
參考 IP Network Address Translator (NAT) Terminology and Considerations
Interactive Connectivity Establishment，互動式連接建立（互動式連通性建立）。
ICE是一套能讓web瀏覽器之間互相連接的框架。通常來說，節點A到B是很難直接相連的。防火牆會阻止連接，設備沒有公共IP地址，路由不允許直接連接其他節點。
ICE使用STUN或者TURN服務（或者同時使用兩者）來建立連接。
參考 ICE | rfc8445
Session Traversal Utilities for NAT (STUN) ，NAT會話傳輸工具。
STUN協議能發現客戶端（節點）的公共地址。客戶端發送一個請求給網上的STUN伺服器，伺服器返回客戶端的公共地址。不管客戶端在路由器的NAT後能否可達。
STUN為請求者提供了可公開訪問的IP地址，它就不再參與對話了。
有些路由器會限制設備與外面其它設備的連接。這意味著即使STUN伺服器知道了路由的公共IP地址，也沒法建立連接。
這種情況下我們需要使用 TURN 。
Traversal Using Relays around NAT，使用中繼繞過NAT傳輸。
一些路由器使用一種叫「Symmetric NAT」（對稱型NAT）的限制。這意味著路由器僅允許之前連接過的節點（peer）來建立連接。
STUN 提供了一個能讓應用（終端，節點）穿過NAT的方法。STUN允許客戶端獲得一個傳輸地址（一個IP和埠）來獲取其它節點的數據。
然而STUN獲取到的地址不一定能被所有節點使用。這些地址是否可用取決於網路拓撲的情況。所以，單獨STUN無法提供完整的穿越NAT的方案。
TURN協議允許兩個處於NAT環境的主機利用中繼進行通訊。客戶端能夠在TURN伺服器上分配資源，與其它客戶端（peer）進行通訊。
客戶端關聯一個TURN伺服器的地址（relayed server address）來作為中繼。
客戶端發送報文給TURN服務，TURN服務使用relayed server address作為源地址向其他客戶端中繼轉發報文。
穿越NAT，這個過程就像是「打洞」。也有人稱TURN伺服器為「打洞伺服器」。
這么看，TURN伺服器需要有大的帶寬。因此，ICE會優先考慮直接通訊，無法直接通訊情況下會使用TURN。
參考 TURN rfc8656
Session Description Protocol，會話描述協議。
描述多媒體連接內容的協議。例如解析度，格式，編碼，加密演算法等等。
實際上，SDP不是個真正的協議。它也是用來描述設備之間連接與傳輸多媒體的數據格式。
參考 SDP: Session Description Protocol | rfc8866
一些縮寫
更多請參考 WebRTC概念簡介