什么是RTC
RTC（Real time communication）實時通信，是實時音視頻的一個簡稱，我們常說的RTC技術一般指的是WebRTC技術，已經被 W3C 和 IETF 發布為正式標準。由于幾乎所有主流瀏覽器都支持 WebRTC 標準 API ，因此也讓瀏覽器之間無插件化的音視頻互通成為可能， 大大降低了音視頻開發的門檻，開發者只需要調用 WebRTC API 即可快速構建出音視頻應用。
更廣義的RTC技術，不單單局限于音視頻，包括IM、圖片、白板、文件共享等富媒體在內的實時交互也屬于RTC技術范疇。
解決什么問題
直播中我們關心的幾個點：延遲、質量、成本等。
傳統rtmp直播痛點：TCP，延遲高、擁塞導致卡頓問題較多（質量問題）。
互聯網網絡復雜、延時敏感、實時音視頻流暢度及清晰度較低以和運營成本較高等。
沒有一項技術能兼顧并解決直播中的所有問題，RTC是時延、流暢、質量、成本等的平衡，成為技術選型落地的模型。
我們在做RTC應用的時候，不應該一味地追求一些點，不應該在某些單點上用力過猛（比如單純的追求抗丟包能力），導致最終的效果會打很多折扣，不能只著眼于延遲低，畫質高，應該把視角放在用戶的整體體驗上。
RTC與傳統RTMP直播對比
| 參數對比 | RTC | RTMP（CDN） |
|---|---|---|
| 底層推流端傳輸協議 | RTP（UDP） | RTMP（TCP） |
| 質量保證Qos | RTCP | - |
| 播放端協議 | RTP | rtmp、hls、http-flv |
| 延遲 | 400ms以內 | rtmp 3s+、hls 15s+、http-flv 3s+ |
| 同步性 | 推流端與播放端基本實時，同步性非常好 | 推流端與播放端同步性差 |
| 互動體驗性 | 優 | 差 |
| 關注點 | 關注實時性 | 關注質量 |
| 拓撲結構 | 雙向，既有推流又有拉流 | 單向，主播推流、觀眾拉流 |
| 技術限制 | 參與人數限制，以聲網為例支持17人互動，百萬觀看（低延遲直播產品） | 一個主播，觀眾數理論無上限 |
| 安全性 | 所有 WebRTC 媒體數據都必須經過加密 | 原生無加密技術，需定制開發視頻加密和防盜鏈 |
| 兼容性 | 為web端而生，提供Native sdk（移動端、PC端），無服務端通用方案需自行開發 | web已不支持發起rtmp直播（Adobe 2020 12棄用flash）rtmp標準協議接入，服務端由技術成熟的CDN分發 |
| 復雜性 | 非常復雜，涉及技術龐雜 | 比較簡單清晰 |
| 典型應用場景 | 推流端與播放端互動性強的場景：視頻會議、連麥互動、語音/視頻聊天 | 推流端與播放端同步性不是很高要求的場景：活動/賽事直播、秀場直播、游戲直播、直播帶貨 |
| 價格（成本） | 高 | 低 |
一套完善的RTC服務應用的技術
RTMP只是TCP上的一個標準協議，所以接入是一個標準體系，推流端可以是OBS這種直播軟件工具，也可自開發rtmp推流工具，播放端可以是Flash播放器（Adobe 2020 12月份已經棄用）、服務端有技術成熟的CDN技術和設施進行分發、Native的播放器或者flv.js/hls.js這種開源播放器組件，遵循rtmp、flv、hls標準即可，接入成本比較低。而一個完善的RTC服務應用，需要從推流端、服務端、到拉流端，一整套完整的全鏈路閉環技術。
RTC的應用場景
視頻會議、在線教育小班課、大班課、1v1視頻連麥、多人視頻連麥互動、語音聊天室、在線面試、在線醫療、云游戲、智能家居、在線簽約、在線K歌等，遍地開花。
比如Zoom、騰訊會議、釘釘會議、微信音視頻聊天
RTC+RTMP
互動連麥+服務端轉推rtmp至CDN，CDN分發給觀眾。
RTC行業狀況
RTC服務提供商
聲網、騰訊云音視頻、即構、阿里云RTC、華為云RTC、微吼VRTC、網易云信RTC、保利威RTC、Ucloud RTC、融云RTC、拍樂云等。
RTC展望
5G時代RTC技術滿足實時通信的同時，將賦能 AI、AR、VR、智能家居、云游戲、遠程輔助駕駛等場景化落地。
