㈠ 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概念简介