SFU的作用是什么。，Janus，mediasoup或medooze。在 webRTC 应用程序上

Question

我正在使用带有简单对等npm 包的webRTC应用程序。

我想知道所有这些主题（SFU.、Janus、mediasoup 或 medooze.）的目的是什么，以及如何集成它们以提高我的应用程序性能？

PS：我正在使用node.js服务器捆绑我的体系结构上的对等点之间的请求和信令。这些服务器和服务是否需要使我的应用程序性能良好？

希望我能在这里找到答案......

Answer 1

使用常规的 webrtc，每个对等点都需要分别向其他每个对等点发送和接收其数据。因此，假设有 10 个同行进行视频聊天。然后每个对等点必须同时发送他们的视频 9 次，并且还接收 9 次。每个对等点都会使用大量的上传带宽，而这通常是他们没有的。

SFU 通过每个对等点仅向媒体服务器发送一个流并让该服务器完成到其他对等点的所有路由来解决此问题。这样每个对等点只发送 1 个流并接收 9 个。下载最大下载带宽通常高于上传带宽。

还有一种叫做联播的东西，它会根据对等方的可用带宽自动切换质量。我已经能够通过mediasoup实现这一点。

Answer 2

WebRTC SFU 服务器可以：

• 转发：只需发送 1 个流到 SFU，SFU 转发到房间中的其他对等点。
• 联播：如果流是联播流，SFU 可以像 MCU 一样转发不同码率的流，但 CPU 成本更低，无需转码。
• 协议转换器：SFU还可以将WebRTC转换为其他协议，例如通过RTMP发布到YouTube。
• DVR：将WebRTC流录制为VoD文件，例如MP4文件。
• 网络质量：SFU 提供更好的网络质量，尤其是在无法启用 P2P 的情况下。
• 防火墙穿越：对于企业防火墙后面的对等体，UDP 可能不可用，SFU 可以使用 HTTP(TCP/80) 或 HTTPS(TCP/443) 端口。

向前

WebRTC的默认模型是P2P，如下所示：

PeerA(WebRTC/Chrome) --------> PeerB(WebRTC/Chrome)
PeerB(WebRTC/Chrome) --------> PeerA(WebRTC/Chrome)

如果一个房间里有三名参与者：

PeerA(WebRTC/Chrome) --------> PeerB(WebRTC/Chrome)
PeerA(WebRTC/Chrome) --------> PeerC(WebRTC/Chrome)
PeerB(WebRTC/Chrome) --------> PeerA(WebRTC/Chrome)
PeerB(WebRTC/Chrome) --------> PeerC(WebRTC/Chrome)
PeerC(WebRTC/Chrome) --------> PeerA(WebRTC/Chrome)
PeerC(WebRTC/Chrome) --------> PeerB(WebRTC/Chrome)

对于P2P模型，每个peer需要发送N-1个流并从其他peer接收N-1个流，这需要大量的上传带宽。

SFU 可以将流转发给其他对等点，如下所示：

PeerA(WebRTC/Chrome) ---> SFU --+--> PeerB(WebRTC/Chrome)
                                +--> PeerC(WebRTC/Chrome)
PeerB(WebRTC/Chrome) ---> SFU --+--> PeerA(WebRTC/Chrome)
                                +--> PeerC(WebRTC/Chrome)
PeerC(WebRTC/Chrome) ---> SFU --+--> PeerA(WebRTC/Chrome)
                                +--> PeerB(WebRTC/Chrome)

对于SFU模型，每个peer只需要发送1个流并接收N-1个流，因此该模型比P2P更好，特别是当一个房间中有更多peer时。

联播

由于对等点的网络不同，因此SFU可以使用联播的方式向对等点发送不同的比特率，其工作原理如下：

PeerA(WebRTC/Chrome) --1Mbps-> SFU --+--1Mbps----> PeerB(WebRTC/Chrome)
                                     +--500Kbps--> PeerC(WebRTC/Chrome)

由于PeerC的网络较差，所以SFU以500Kbps的码率发送流。

请注意，这需要 PeerA 使用 AV1 编解码器，默认情况下不支持 H.264，因此这不是一个完美的解决方案。

而且它也很复杂，PeerC 可能不想要低比特率流，但它接受更大的延迟，所以这个解决方案并不总是有效。

注意：联播与 MCU 不同，MCU 需要大量 CPU 成本进行转码。MCU 将房间内的流转换为 1 个流以供对等方接收，因此它已用于某些场景，例如 SIP 嵌入式设备，该设备仅接收 1 个包含视频和音频的流。

有很多 SFU 服务器可以做到这一点，例如SRS、Mediasoup、Janus和Licode。

注意：在2023.02之前，SRS联播功能尚未合并开发，它位于功能分支中。

协议转换器

有时您想将WebRTC转换为直播，例如打开网页并将相机流发布到YouTube。

如何通过SFU做到这一点？它的工作原理如下：

Chrome --WebRTC------> SFU ---RTMP------> YouTube/Twitch/TikTok
        (H.264+OPUS)        (H.264+AAC)

在该模型中，SFU只需将音频流从OPUS转换为AAC，视频流对于WebRTC和RTMP都是旁路H.264。

由于音频转码的原因，很少有SFU服务器可以做到这一点，例如SRS和Janus。

注意：Janus 需要 ffmpeg 来隐藏 RTP 数据包，而 SRS 本身会执行此操作，因此易于使用。

硬盘录像机

SFU还可以将DVR WebRTC流传输到MP4文件，例如：

Chrome ---WebRTC---> SFU ---DVR--> MP4

这使您能够使用网页上传 MP4 文件。例如，允许用户录制相机片段以反馈您的产品。

与直播类似，MP4文件对AAC的支持更好，因此SFU需要将OPUS转换为AAC。

由于音频转码的原因，很少有SFU服务器可以做到这一点，例如SRS。

注意：我不确定哪些 SFU 服务器支持此功能，如果我错过了什么，请告诉我。

网络质量

在互联网上，SFU模式比P2P模式更好。考虑以下流程：

PeerA <----Internet--> PeerB

P2P看似简单、效率高，但实际上有很多路由器和网络设备，一般都是服务器，所以P2P模型的流程应该是：

PeerA <--------Internet----------> PeerB
         Routers, Servers, etc.

从网络传输的角度来看，SFU模型类似：

PeerA <--------SFU-Server----------> PeerB
         Routers, Servers, etc.

SFU网络质量比P2P好，与服务器无关，但您可以通过使用专用服务器甚至专用网络来控制传输网络。

但对于P2P，你无法控制路由器和服务器，所有对等点都是客户端。

注意：TURN服务器模型也提高了网络质量，但SFU仍然更好，因为你可以在SFU上使用一些QoS算法，例如GCC，因为SFU服务器实际上是客户端，而TURN只是一个代理。

注：SFU集群由一组SFU服务器组成，也可以提高同行跨国时的质量。

防火墙穿越

对于企业防火墙后面的某些用户，UDP 不可用：

        Firewall
            |
Chrome -----X---WebRTC--- Chrome(PeerB)
PeerA       |   (UDP)

更糟糕的是，某些防火墙只允许 HTTP(TCP/80) 或 HTTPS(TCP/443)。因此我们可以使用 SFU 来监听 HTTP(TCP/80) 或 HTTPS(TCP/443)，它的工作原理如下：

        Firewall
            |
Chrome -----+---WebRTC-------> SFU ---> Chrome(PeerB)
PeerA       |   (TCP 80/443)

注意：是的，TURN服务器也可以解决这个问题，coturn就是这样，但是注意TURN服务器通常会分配一组端口，而不是固定端口，所以TURN服务器不太容易用作SFU服务器。

很少有 SFU 服务器可以做到这一点，例如SRS和Mediasoup。

注意：我不确定哪些 SFU 服务器支持此功能，如果我错过了什么，请告诉我。