什么是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、智能家居、云游戏、远程辅助驾驶等场景化落地。
