每隔一段时间就会有人提出用 WebRTC 广播或进行大规模视频会话的想法，而不使用媒体服务器。只是使用纯 WebRTC 的 P2P 网状技术。
虽然作为大学的研究课题很有趣，但我不认为采取这种生产方式是一种可行的方法。
什么是 WebRTC P2P mesh？
如果你只关注数据的WebRTC mesh结构，那么请跳到本文的最后一节。
在处理 WebRTC 和指示 P2P 或 mesh 时，焦点几乎总是在媒体传输上。信令仍然流经服务器（单个或分布式）。对于简单的 1:1 语音或视频通话，WebRTC P2P 是显而易见的选择。
从 WebRTC 客户端的角度来看，如果使用 P2P mesh或使用媒体服务器完成，1:1 会话是相似的。
下图显示，从 WebRTC 客户端的角度来看，通过媒体服务器或进行 P2P 之间没有区别——在这两种情况下，它发送单个媒体通道并接收单个媒体通道。在这两种情况下，我们希望比特率也相似。
将其转化为 P2P 中的群组通话转化为网状网络，其中每个 WebRTC 客户端都有一个直接向所有其他客户端开放的对等连接。
为什么使用 WebRTC P2P mesh？
供应商希望使用 WebRTC P2P mesh 作为架构解决方案的主要原因有两个：
- 运营成本较低。由于没有媒体服务器，媒体直接在用户之间流动。对于 WebRTC，通常最大的成本是带宽。通过尽可能不通过服务器路由媒体（某些时候仍然需要 TURN 中继），运行服务的成本大大降低
- 它更私密。是的。作为服务提供商，你没有任何机会接触到媒体，因为它没有流经你的服务器，所以你可以把你的服务作为一个为最终用户提供更高程度隐私的服务来推销。
为什么不使用 WebRTC P2P mesh？
如果 WebRTC P2P mesh 这么好，运营成本更低，隐私更好，那为什么不使用它呢？
因为当涉及到带宽和CPU要求时，它带来了很多挑战和麻烦。以至于它在很多情况下都会惨遭失败。
此处还需要注意的是，在通话中有 3 个或更多用户的所有情况下，依赖媒体服务器的替代解决方案可提供更好的性能和用户体验。至少只要正确部署和配置了媒体服务器基础设施。
WebRTC P2P mesh中的带宽挑战
假设我们想要原始质量。单个主持人，10 个听众。
上面的布局说明了这个会议的大多数用户希望看到和体验的东西。在会议期间，发言人可能会交替出现，切换被显示在更大框架中的人。
由于我们都在大屏幕上观看，我们宁愿以高清分辨率而不是 QVGA 接收它。为此，我们希望每个人都能接收到至少 1.5Mbps 的扬声器。
上行链路压力
在网状拓扑中，发言者需要将媒体发送给所有参与者。这就是它的确切含义：
在 WebRTC mesh中，我们对上行链路施加了更大的压力。
1.5Mbps 乘以 10 等于上行链路的 15Mbps。不是大多数人拥有的东西。我不认为我紧张的FTTH网络能够在我需要的时候给我提供这种东西。特别是在大流行期间。
在办公室环境中，人们需要同时使用网络，不可能为远程会议中的每个用户提供 15Mbps 的上行链路。
最重要的是，我们有 10 个独立的对等连接到 10 个不同的位置。WebRTC 有一个内部带宽估计算法，谷歌在 libwebrtc 中实现了它，这很棒。但是它在客户端处理这么多对等连接的效果如何呢？谷歌有没有人试图针对这种情况进行定位甚至优化？记住——谷歌自己的服务都不是在网状拓扑中运行的。赢得这场比赛将是一场艰苦的战斗。
下行带宽估计
让我们看看观众/订阅者/参与者/用户或任何你想称呼他们的人。
如果我们选择画廊视图布局，那么我们将接收 10 个传入视频流。为了简化布局，将其减少到 9，我们得到以下图示：
还有 9 个其他用户生成视频流并以我们的方式发送。这 9 个流在我们的下行链路网络资源和我们机器的注意力和 CPU 上竞争。
它们中的每一个都是独立于其他的，对其他的了解很少。
观众如何正确了解自己的下行网络状况？更不用说尝试指导这些发送方式和发送内容了。媒体服务器也有同样的问题需要处理，但它有两个主要优势：
- 它控制所有发送给观众的视频，它可以统一行动，而不是多个浏览器相互竞争（你可以尝试同步它们，但祝你好运）
- 你可以把所有传入的流放在来自服务器的单一对等连接中，这就是Google Meet所做的（可能也是Google在其WebRTC实现中重点优化的）。
P2P mesh 中的 CPU 挑战
然后是 WebRTC P2P mesh 中要处理的 CPU 问题。
从我们的发言人到观众的每个视频流都有自己的专用视频编码器。我们有10个观众，这意味着有10个视频编码器。
如果可以的话，这里有一些小的见解：
- 如果你的目标是H.264硬件编码，那么请记住，许多笔记本电脑最多允许3-4个并行的编码流。在目前的WebRTC实现中，其余的都是黑屏。
- 视频编码非常耗费 CPU（和内存）。就 CPU 资源而言，编码比解码差很多。拥有 10 个解码器已经够难了，10个编码器是残酷的。
- 如果不添加优化以减轻客户的痛苦并且不消耗他们的 CPU，很难使用 SFU 管理视频通话中的 10 个或更多参与者。那时每个用户都有一个编码器（或联播）来处理
- 你的苹果MacBook Pro 有16个以上核心，并不是你的用户会有的典型设备。如果这就是你在测试WebRTC网状群组视频通话的设备，那么你就做错了。
- 我相信你认为使用VP9（或AV1 或 HEVC）会节省带宽并提高质量。但它比 VP8 或 H.264 吃更多的 CPU，所以根本不可行。
那么，要进行群组视频通话吗？
想使用 WebRTC P2P mesh？
即使你的网络有很好的上行链路，你的外发视频也会停留在300kbps或更少。因为你的设备的CPU会在多次编码中消耗周期。
这也意味着人们不会喜欢听到他们的笔记本电脑的风扇声，或在通话中触摸他们发热的智能手机（和耗尽的电池）。
我们能做得更好吗？
也许可以。一个单一的编码器会使CPU的问题小一点。它将带来与所有观众匹配比特率的问题（每个人都有自己的网络和设备限制）。
在这里以某种方式使用联播可能会有所帮助，但这不是它的预期使用方式或实现方式。
所以这种方法需要有人对 WebRTC 代码库进行修改。并让谷歌采用它们。我是否已经说过 Google 没有动力对此进行投资？
WebRTC P2P mesh的替代品
你可以在 WebRTC P2P mesh架构中进行群组视频通话。这将意味着非常低的比特率和降低的视频质量。但它会工作。至少在某种程度上。
还有其他的模式，性能更好，但需要媒体服务器。
使用 MCU 模型，你可以在 MCU 中混合所有视频和音频流，确保每个参与者只接收和发送单个流到 MCU。
使用 SFU 模型，你可以在参与者之间路由媒体，同时尝试平衡他们的限制与 SFU 接收的媒体输入。
关于WebRTC数据通道网状结构的说明
我还没有真正触及数据通道的WebRTC mesh结构。
上面详述的所有原因和挑战并不直接适用于此。CPU 和带宽依赖于需要编码、发送、接收和解码实时视频的概念。在大多数情况下，这不是我们在尝试构建网状数据通道网络时要处理的问题。在那里，主要关注/挑战将是正确创建和连接 WebRTC 中的对等连接。
如果你正在做的不是群组视频通话（或从浏览器向其他人直播视频），那么 WebRTC P2P mesh架构可能适合你。至于是否可行，要具体情况具体分析。
原文：https://bloggeek.me/webrtc-p2p-mesh/
本文为原创稿件，版权归作者所有，如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/26036.html
