WebRTC
WebRTC 相关协议
NAT（Network Address Translation）
4种类型
- 1 完全圆锥形NAT（Full Cone NAT）：
- 内网主机跟 NAT 进行映射， 远端主机 直接可以访问。
- 2 受限圆锥形NAT（Restricted Cone NAT）
- 类似完全圆锥形 NAT，额外增加IP限制，但外部主机必须先收到内网主机的数据包才能发送数据给内网主机。
- 3 端口受限圆锥形NAT（Port Restricted Cone NAT）
- 类似受限圆锥形 NAT，额外增加端口限制。外部主机必须使用固定的源端口才能发送数据给内网主机。
- 4 对称NAT（Symmetric NAT）
- 完全映射。同一内部 IP 与端口发到不同的目的地和端口的信息包，都使用不同的映射。
穿透关系：4种类型，如果定义他们的值为序列号，N为序列号相加。则N<=6可穿透。
1 和 4 序列相加 = 5 则可穿透。 3(端口受限)和4（对称）= 7 不可穿透。
ICE（Interactive Connectivity Establishment）
ICE(交互式连接建立) 是 WebRTC 中用于处理网络地址转换（NAT）的关键框架。集成了 STUN/TURN 协议， 利用 Stun 和 Turn 服务器来帮助端两端点立连接
RFC5245 对 ICE 做了规范定义，RFC8445 是 2018 年发布的最新的规范，对 RFC5245 进行了部分修改。
信令服务可以跟 ICE 一起，也可以单独拆分。
STUN（Session Traversal Utilities for NAT）
STUN（NAT会话穿越应用程序）允许位于NAT（或多重 NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的 NAT 之后 以及 NAT 为某一个本地端口所绑定的 Internet 端端口。 这些信息被用来在两个同时处于 NAT 路由器之后的主机之间建立 UDP 通信.
重要定义 STUN 通过UDP进行NAT穿越的方式
重要定义 STUN 是 NAT 穿越的一整套工具集，不在局限于 UDP 而是同时适用于 UDP 和 TCP 协议,报文格式变动等。
TURN（Traversal Using Relays around NAT）
NAT 穿透失败，TURN 还可以作为中继传输数据，允许客户端使用同一个中继地址与多个不同的对等端进行通信。
TURN 协议有三个阶段或机制：分配（Allocation）、转发（Relay）和信道（Channel）。 分配机制：客户端向 TURN 服务器申请一个中继地址。服务器为用户开启一个 relay 端口并返回分配成功响应，包含了分配的地址。 转发机制：TURN 允许客户端使用中继服务与对端进行报文传输。数据可以通过 relay 或 channel 两种方式交换。 信道机制：为改善带宽压力，TURN 提供了 channel 数据报文格式，不使用 STUN 头部，而使用一个 4 字节的头部。
WebRTC 相关架构
Mesh（P2P）
Mesh 类似 P2P 通讯模式，每一个 P2P 连接有独立的传输策略控制，需要打洞成功。
- 优点
- 对服务器资源占用最小。 ICE 穿透服务器就用于信令和打洞。
- 缺点
- 依赖穿透成功，用户带宽未必能带起多人同时音视频
2024-09-06-ffmpeg-introduction.md
SFU（Selective Forwarding Unit）
SFU 它不涉及视频解码和编码的计算费用，它以最低的开销来转发各路媒体流，
缺点
优点 a. 服务器压力适中。尽管都需要部署流媒体服务器，但是 SFU 架构和 MCU 架构不一样，它不需要对媒体流解码再混流。SFU 的服务器只负责媒体流的转发或者存储，不做编码、解码、转码、混合等算力要求比较高的任务。所以，服务器端的压力比 MCU 要低很多。
b. 带宽占用适中。以上图为例，依然假设每路媒体流所占带宽为 1MB，那么每个客户端的上行带宽为 1MB，下行带宽为 3MB，每个客户端总体消耗的带宽是 4MB。很明显，占用带宽（4MB）介于 Mesh 架构（6MB）和 MCU 架构（2MB）之间。
c. 布局控制灵活。因为每个参会者都拉取了其他参会者的媒体流，所以，每个用户都可以动态改变自己本地的画面布局，比如放大、缩小等。如果不希望观看某个人的视频画面，还可以不订阅这个人的媒体流。
结论 本文介绍了 Mesh、MCU、SFU 三种 WebRTC 服务架构的基本情况，也论述了它们各自的优缺点。尽管它们都有各种不足，但是它们对 WebRTC 实时音视频通讯技术的发展都起到了一定的推动作用。Mesh、MCU、SFU 三种服务架构有非常多值得我们学习和借鉴的地方。现在很多先进的服务器方案不是单单使用某一种服务架构，更多的是搭配使用。比如我们自己的 WebRTC 流媒体服务器就是使用了 MCU+SFU 的混合模式。所以说，在技术选型时没有绝对的，我们需要根据自己具体的业务场景和技术储备情况挑选最合适的方案。希望本文介绍的内容可以帮到大家，感谢！
MCU(Multi-point Control Unit)
MCU 将接收到的多路流进行转码和混合，并向每个终端输出单路流的做法，节省了终端用户的下行带宽，并且还能够对不同网络条件的用户，订制不同码率的输出视频流，让多人场景有更好的用户体验。典型的应用场景是多人音视频通话。这种架构比较适合客户端条件较差的场景，比如使用手机进行多人的视频通话，由服务端来抵消移动端的资源消耗。
缺点 a. 对服务器压力最大。MCU 服务架构需要系统提供一个中心化的 MCU 混流服务器，所有媒体流的解码、编码、转码、混合都在服务器端完成。如上图所示，四个客户端需要把自己的媒体流推流到 MCU 服务器，然后 MCU 服务器再对这四路媒体流进行解码、混流，最后把合并的媒体流发送给四个参会者。因此，MCU 架构的服务器压力非常大，也是三种服务架构中压力最大的。
b. 自定义布局复杂。一般情况下，MCU 服务器仅混流编码一路合并之后的媒体流，上图中的四个参会者接收到的混流媒体流是同一路，看到的视频画面也是一致的。如果某个参会者想改变视频画面的布局，比如放大某个人的视频画面，或者关闭某个人的视频画面，通常是无法满足的。但是，我们也可以定义单独的信令逻辑，请求 MCU 服务器单独编码一路媒体流发送给特定需求的参会者。但是，需要限制或者避免所有参会者都有类似的需求，否则 MCU 服务架构会退化成 SFU 服务架构。
c. 成本最高。如果资金允许的话，还是应该考虑引入高级的 GPU 加速服务器，用来提高流媒体服务器的混流能力。但是，成本也会相应提高。
优点 a. 带宽占用最小。还以上图为例，假设每路媒体流所占带宽大小为 1MB，每个客户端总体消耗的带宽是 2MB。如果复用 PeerConnection 通道的话，只需要建立四条链路。
b. 客户端解码压力小。因为每个参会的客户端都只需要解码一路媒体流，就可以代替分别解码每个参会者媒体流的情况，而另外两种服务架构都需要单独解码其他参会者的媒体流。