WebRTC
WebRTC（Web Real-Time Communication）是一种开放框架，用于在网络应用程序和网站之间实现实时通信。它是一个基于浏览器的技术，使开发人员能够创建语音、视频和数据的实时通信应用，而无需用户下载任何插件或第三方软件。
协议类型
WebRTC 包含一系列协议、API 和标准，用于实现实时通信。主要涉及的协议包括：
- ICE（Interactive Connectivity Establishment）：
用于发现和连接两个端点之间的最优路径。 - STUN（Session Traversal Utilities for NAT）：
用于找到对等方的公共 IP 地址。 - TURN（Traversal Using Relays around NAT）：
用于在直接连接不可能时，通过中继服务器传递数据。 - SRTP（Secure Real-time Transport Protocol）：
用于安全的音视频传输。 - DTLS（Datagram Transport Layer Security）：
为 WebRTC 提供安全性和数据加密。
应用场景
- 视频通话和语音通话：用于在浏览器中创建实时音视频通话应用，如视频会议、在线教育等。
- 实时数据传输：可用于文件共享、在线游戏、协作应用等。
- 直播流媒体：WebRTC 可以用于低延迟直播或点对点流媒体传输。
工作机制
WebRTC实际上是两个Web浏览器之间直接通信的标准，主要包含了信令(Signaling)和媒体(Media)两个部分的协议。 信令解决两个设备之间的能力的协商的问题，比如支持的编解码能力。媒体解决两个设备之间加密和低延迟媒体包传输的能力。 除此之外，WebRTC本身还实现了语言处理技术比如3A，网络拥塞控制比如NACK、FEC和GCC，音视频编解码，平滑和低延迟播放技术。
+----------------+ +----------------+
+ Browser +----<--Signaling----->--+ Browser +
+ (like Chrome) +----<----Media----->----+ (like Chrome) +
+----------------+ +----------------+
Note: WebRTC已经是RFC正式标准，因此各种浏览器都已经支持，而开源的实现也很多，因此不限于浏览器，移动端的浏览器和 Native库也有很多，因此为了沟通的简单起见，本文一般以浏览器指代所有支持WebRTC协议的客户端或设备。
在互联网上，两个浏览器几乎无法直接通信，特别是不在一个局域网，而且是在远距离跨城市甚至跨国家时，两个浏览器之间 传输数据会经过非常多的网络路由器和防火墙，因此传输质量无法保障。因此，实际应用是需要经过服务器中转，而WebRTC服务器有 几种类型：
Signaling Server:
信令服务，两个浏览器之间交换SDP的服务。如果是多人会议，则需要提供房间服务，本质上都是为各个浏览器交换SDP。而在流媒体领域，为了可以使用WebRTC推流和播放，像推送和播放RTMP/SRT/HLS流一样，WHIP/WHEP协议被设计出来了。
TURN Server:
转发服务，帮助两个浏览器之间转发媒体数据的服务。这是一种透明转发服务，并不会实现数据缓存，因此当多人会议时，浏览器之间需要传输
N*N + N*(N-2)份数据。一般只应用在非常少的通信场景中，比如一对一。开源实现可查看coturn这个项目。SFU Server:
选择性转发服务，服务器上有缓存数据，因此浏览器只需要上传一份数据，服务器会复制给其他参会者。SRS就是SFU，关于SFU的作用可以参考这里。目前主要的WebRTC服务器都是SFU服务器，会有
N*N份流传输，比TURN少N*(N-2)份上行数据传输，能解决大部分的传输问题。MCU Server:
多点控制服务，服务器将会议中的流合并成一路，这样浏览器只需要传输N*2份数据，上传一路下载一路数据。但由于需要编解码，服务器支持的流的数量比SFU要少一个量级，只有在某些特定场景才会采用。
我们重点介绍SFU的工作流，因为SFU是在WebTC服务器中使用最多的，它本质上就是一个浏览器：
+----------------+ +---------+
+ Browser +----<--Signaling----->--+ SFU +
+ (like Chrome) +----<----Media----->----+ Server +
+----------------+ +---------+
Note: SFU一般都会有Signaling的能力，其实可以把RTMP地址也可以看成是一种非常简化的信令协议，只是WebRTC的信令需要协商 媒体和传输能力，所以比较复杂。在复杂的WebRTC系统中，可能有独立的Signaling和Room集群，但是SFU同样也会有简化的Signaling能力， 只是可能是用于和其他服务通信。
其他问题
WebRTC 是 P2P 的,一对一视频的时候好理解,那多对多怎么做到 P2P 呢
WebRTC 的核心原则是点对点（Peer-to-Peer，P2P）通信，但在多对多的场景中，直接的 P2P 连接可能会变得复杂。WebRTC 的设计初衷是尽可能使用 P2P 连接，以提高效率和降低延迟，但在多对多场景中，可能会使用不同的技术架构和策略。
在多对多的 WebRTC 应用中，通常有两种主要模式来处理点对点通信：
- Mesh 模式：
在 Mesh 模式中，每个参与者与其他所有参与者建立 P2P 连接。这意味着如果有 N 个参与者，每个参与者将建立 N-1 个连接。因此，整个网络中会有 N*(N-1)/2 个连接。- 优点：直接的 P2P 连接提供了最低的延迟，数据不需要经过中间服务器。
- 缺点：连接数量随着参与者数量的增加而指数增长，这会导致带宽和资源消耗的增加。这种模式在小规模会议中效果较好，但在大型会议或资源受限的环境中可能会遇到瓶颈。
- SFU 模式（Selective Forwarding Unit）：
在 SFU 模式中，每个参与者只与一个中间服务器（SFU）建立连接。SFU 服务器负责接收每个参与者的音频和视频流，然后根据需求将其转发给其他参与者。- 优点：减少了参与者之间的连接数量，降低了每个参与者的带宽和处理负担。SFU 服务器可以选择性地转发流，从而支持更大的会议规模。
- 缺点：SFU 服务器引入了一定的延迟，因为数据需要经过中间服务器；而且 SFU 服务器可能成为单点故障。
SFU 与 MCU 的区别
SFU（Selective Forwarding Unit）
SFU 是选择性转发的，可以选择性地转发音频和视频流，允许每个参与者接收不同数量的流或不同质量的流。
MCU（Multipoint Control Unit）
MCU 将多个参与者的音频和视频流进行合成，这意味着每个参与者只需接收一条合成流。由于 MCU 需要对媒体流进行解码、合成和转码，资源消耗相对较高。
架构区别如下：
| 优势 | 劣势 | |
|---|---|---|
| SFU | 灵活分发，并发高 | 下行转发路数多，带宽占用高，多方通话影响体验 |
| MCU | 转发流数少，下行带宽占用少 | 服务器性能要求高，部署成本高，实时性稍差 |
优秀开源项目
WebRTC 的生态中，有许多优异的开源媒体服务器，下面列出部分关注度高的项目：
| Project | SFU | MCU | LIcense |
|---|---|---|---|
| SRS | ☑️ | ✖️ | MIT |
| Janus | ☑️ | ☑️ | GPL v3 |
| Licode | ☑️ | ☑️ | MIT |
| MediaSoup | ☑️ | ✖️ | ISC |
| Kurento | ☑️ | ☑️ | Apache2 |
| Jitsi | ☑️ | ✖️ | Apache2 |
优秀文章
关于WebRTC的传输机制，我看到一篇很详细的文章，可以参考：
WebRTC → 传输技术解析
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 1430797759@qq.com