WebRTC基础介绍
WebRTC 全称为：Web Real-Time Communication。
它是为了解决 Web 端无法捕获音视频的能力，并且提供了 peer-to-peer（就是浏览器间）的视频交互。
WebRTC汇集了先进的实时通信技术，包括：先进的音视频编解码器（Opus和VP8/9），强制加密协议（SRTP和DTLS）和网络地址转换器（ICE＆STUN）。
根据最初的定义，WebRTC被指定为P2P（peer-to-peer）技术。
自成立以来，WebRTC已经大大降低了Web开发人员通过简单的Java API构建实时通信应用程序的难度。
但要清楚，WebRTC是一种技术，而不是一个完整的应用程序或服务。
目前来看，WebRTC在电视会议和直播领域有很大的潜力。
虽然WebRTC最初被设想为纯粹的P2P技术，但许多日常业务应用程序需要集中式媒体功能，通过P2S（peer-to-server）架构提高可靠性、效率或扩展性。
对于P2P和P2S架构之间的问题对于构建WebRTC应用程序很重要。
P2P与P2S
WebRTC旨在通过其浏览器（也称为P2P）在客户端之间直接发送媒体流。在P2P架构中，客户端建立通信之前，首先需要建立到应用服务器（有时也称为信令服务器）的信令连接。而 WebRTC规范中没有规定信令方法或协议，它允许采用现有方法（SIP，WebSockets，XMPP等）或实现专有信令过程。应用服务器保存业务逻辑，并作为会话描述协议（SDP）交换的中介。一旦SDP交换完成，两个客户端之间的直接媒体通信即可开始。
虽然WebRTC主要是浏览器到浏览器，但是随着服务器将媒体锚定在网络中以充当媒体P2S（如下图）。在P2S架构中，客户端再次建立到应用服务器的信令连接。在该体系结构中，应用服务器继续管理业务逻辑，而且还利用到服务器的媒体控制连接来进行客户端和媒体服务器之间的SDP交换。一旦SDP交换完成，客户端和服务器之间的媒体通信即可开始。
使用服务器端处理可以引入高级功能，例如用于合规性的集中审查，音频/视频回放，用于视频流的媒体分析，从而实现人脸监测、人脸识别等。根据架构，服务器端处理可以优化带宽并最大限度地减少客户端计算，从而能够使移动客户延长电池使用时间，并为其提供灵活的用户界面。
典型网络结构
p2p
Mesh
音视频数据流只在终端用户之间相互传输，不经过任何服务器节点，而且每个人都要与其它所有人建立P2P连接。
p2s
MCU（Multi-point Control Unit）
MCU是传统视频会议系统中的核心控制单元，在WebRTC的系统实现中， 适合于多人音视频通话场景，MCU可以对接收到的多路流进行转码和混合，并向每个终端输出单路流。
SFU（Selective Forwarding Unit）
SFU从发布客户端复制音视频流的信息，然后分发到多个订阅客户端。典型的应用场景是1对多的直播服务。
三种构架的差异
Mesh:每一个P2P连接有独立的传输策略控制，通讯质量有一定的保障。但是，这种架构对于客户端系统是一种浪费，一方面需要分配更多的端口，消耗更多的系统资源；另一方面，由于要向其它三个客户端发送本地音视频数据，增加了上行网络带宽的消耗，在同等带宽条件下，支持的多人通话路数就相对有限，视频质量(码率)也比较低。
MCU:MCU将接收到的多路流进行转码和混合，并向每个终端输出单路流的做法，节省了终端用户的下行带宽，并且还能够对不同网络条件的用户，订制不同码率的输出视频流，让多人场景有更好的用户体验。典型的应用场景是多人音视频通话。
SFU:SFU是解决服务器性能问题的有吸引力的方法，因为它不涉及视频解码和编码的计算费用，它以最低的开销来转发各路媒体流，典型的应用场景是1对多的直播服务。
从微观角度来看
WebRTC包含三个部分：
- MediaStream:捕获音视频流
- RTCPeerConnection:传输音视频流（一般用在 peer-to-peer 的场景）
- RTCDataChannel: 用来上传音视频二进制数据（一般用到流的上传）
当然，PeerConnection也可以用于P2S的场景。
WebRTC 利用的是 UDP 方式来进行传输视频包。这样做的好处是延迟性低，不用过度关注包的顺序。不过，UDP 仅仅只是作为一个传输层协议而已。WebRTC 还需要解决很多问题：
遍历 NATs 层，找到指定的 peer
双方进行基本信息的协商以便双方都能正常播放视频
在传输时，还需要保证信息安全性
WebRTC的架构如下：
信令服务
WebRTC使用RTCPeerConnection来在浏览器之间传递流数据，在建立RTCPeerConnection实例之后，想要使用其建立一个点对点的信道，我们需要做两件事：
- 确定本机上的媒体流的特性，比如分辨率、编解码能力啥的（SDP描述符）
- 连接两端的主机的网络地址（ICE Candidate）
注：由于连接两端的主机都可能在内网或是在防火墙之后，我们需要一种对所有联网的计算机都通用的定位方式。这其中就涉及NAT/防火墙穿越技术。
实现上，就是两个点间的交互过程——通过offer和answer交接SDP描述符——我们称请求进行连接一端发出的信令为offer，另一端的回复称为answer。
模拟两个用户（甲和乙）之间建立点对点连接流程如下：
1)甲和乙各自建立一个PC实例
2)甲通过PC所提供的createOffer()方法建立一个包含甲的SDP描述符的offer信令
3)甲通过PC所提供的setLocalDescription()方法，将甲的SDP描述符交给甲的PC实例
4)甲将offer信令通过服务器发送给乙
5)乙将甲的offer信令中所包含的的SDP描述符提取出来，通过PC所提供的setRemoteDescription()方法交给乙的PC实例
6)乙通过PC所提供的createAnswer()方法建立一个包含乙的SDP描述符answer信令
7)乙通过PC所提供的setLocalDescription()方法，将乙的SDP描述符交给乙的PC实例
8)乙将answer信令通过服务器发送给甲
9)甲接收到乙的answer信令后，将其中乙的SDP描述符提取出来，调用setRemoteDescripttion()方法交给甲自己的PC实例
流程图：
注意，实体B收到A的请求offer后，根据自身支持的媒体类型和编码策略，回复响应：
a. 如果实体B回复的响应中的媒体流数量和顺序必须（MUST）和请求offer一致，以便实体A进行甄别和决策。即m行的数量和顺序必须一致，B不能（MUST NOT）擅自增加或删除媒体流。如果B不支持某个媒体流，可以在对应的端口置0，但不能不带这个m行描述。
b. 对于某种媒体，实体B必须（MUST）从请求offer中选出A支持且自己也支持的该媒体的编码标识集，并且可以（MAY）附带自己支持的其它类型编码。
c. 对于响应消息中各个媒体的方向：
如果请求某媒体流的方向为sendonly，那么响应中对应媒体的方向必须为recvonly；
如果请求某媒体流的方向为recvonly，那么响应中对应媒体的方向必须为sendonly；
如果请求某媒体流的方向为sendrecv，那么响应中对应媒体的方向可以为sendrecv/sendonly/recvonly/inactive中的一种；
如果请求某媒体流的方向为inactive，那么响应中对应媒体的方向必须为inactive；
d. 响应answer里提供IP和端口，指示Offerer本端期望用于接收媒体流的IP和端口，一旦响应发出之后，Offerer必须（MUST）准备好在这个IP和端口上接收实体A发来的媒体流。
e. 如果请求offer中带了ptime（媒体流打包间隔）的a行或带宽的a行，则响应answer也应该（SHOULD）相应的携带。
f. 实体B Offerer应该（SHOULD）使用实体A比较期望的编码生成媒体流发送。一般来说对于m行，如m=video 0 RTP/AVP 31 34，排充越靠前的编码表示该实体越希望以这个编码作为载体，这里示例31(H261)，34（H263）中H261为A更期望使用的编码类型。同理，当实体A收到响应answer后也是这样理解的。
参考：
https://webrtc.org/
https://www.sohu.com/a/193572223_472885
https://www.cnblogs.com/qcloud1001/p/6640885.html
关于webRTC协议的介绍：https://w3c.github.io/webrtc-pc/