Real-Time Streaming Systems (WebRTC + Live Data) · 课时

SFU 与 MCU 架构

了解选择性转发单元（SFU）和多点控制单元（MCU）在多方 WebRTC 通话中的区别。

SFU 与 MCU 架构 是 CoddyKit 上的免费 Real-Time Streaming Systems (WebRTC + Live Data) 课时。这是第 1 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Real-Time Streaming Systems (WebRTC + Live Data) 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Real-Time Streaming Systems (WebRTC + Live Data) 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Scaling Multi-Party Calls

Imagine a video call with many people. How do all their video and audio streams connect efficiently? Direct peer-to-peer connections, common in 1-on-1 WebRTC, become complex and inefficient for larger groups.

This lesson explores two main server-side architectures for scaling multi-party calls: MCU and SFU.

Introducing the MCU

MCU stands for Multipoint Control Unit. Think of an MCU as a central 'mixer' for all participants' media streams.

In an MCU architecture, every participant sends their individual audio and video stream to a central server.

How MCU Processes Streams

The MCU server receives all individual streams, decodes them, mixes them together into a single composite stream (e.g., a grid layout of videos), and then re-encodes this single stream.

Finally, the MCU sends this *single, mixed stream* back to *all* participants.

MCU: Client Benefits

A big advantage of the MCU model is that each client only needs to send one stream (their own) and receive one stream (the mixed stream from the server).

This significantly reduces the client's bandwidth and processing requirements, making it suitable for users with weaker internet connections or less powerful devices.

MCU: Server Trade-offs

While beneficial for clients, MCUs place a heavy load on the server. The server has to decode, mix, and re-encode many streams in real-time.

Server Intensive: High CPU and memory usage.
Quality Compromise: Re-encoding can introduce latency and reduce individual stream quality.
Limited Customization: Clients receive a fixed layout determined by the server.

Introducing the SFU

SFU stands for Selective Forwarding Unit. Unlike an MCU, an SFU does not mix or re-encode media streams.

An SFU acts as a smart router, forwarding individual streams from one participant to all others who need to receive them.

How SFU Routes Streams

In an SFU setup, each participant sends their stream to the SFU server. The SFU then forwards each participant's stream *individually* to all other participants.

The SFU can selectively choose which streams to forward and at what quality (e.g., sending a lower resolution to clients with poor bandwidth).

SFU: Client-Side Flexibility

With an SFU, each client receives multiple individual streams (one from each other participant). The client then decodes and renders these streams locally.

This allows for greater flexibility in layout and individual stream control on the client side. For example, a client can choose to display only a few main speakers.

Try running this example:

function simulateSFUClient(numberOfParticipants) {
  console.log("--- SFU Client Simulation ---");
  console.log("Receiving individual streams from server:");
  for (let i = 1; i <= numberOfParticipants; i++) {
    console.log(`  - Stream ${i} (from Participant ${i})`);
    // In a real WebRTC app, this would involve
    // creating a <video> element for each stream.
  }
  console.log("Client renders all streams locally.");
  console.log("----------------------------");
}

simulateSFUClient(3); // Simulate a call with 3 other participants

SFU: Balancing Act

SFUs are highly efficient for the server as they don't decode/re-encode, just forward. This makes them more scalable for many participants.

However, clients need more bandwidth (to receive multiple streams) and more processing power (to decode and render them all locally).

Server Efficient: Low CPU/memory per stream.
Client Intensive: Higher bandwidth and CPU for clients.
Flexible: Clients can customize layout and individual stream visibility.

Choosing the Right Architecture

The choice between MCU and SFU depends on your application's specific needs:

MCU: Best for low-bandwidth clients, fixed layouts, and when server cost for processing is acceptable.
SFU: Ideal for high-quality, flexible layouts, and when scaling to many participants is critical, assuming clients have adequate resources.

SFU vs. MCU Quiz

Test your understanding of MCU and SFU architectures.

Recap: MCU vs. SFU

We've explored two key architectures for multi-party WebRTC calls:

MCU (Multipoint Control Unit): Server mixes streams, sends one composite stream to each client. Good for low-resource clients, but server-intensive.
SFU (Selective Forwarding Unit): Server forwards individual streams to clients. Offers better quality and client flexibility, but requires more client bandwidth and processing.

Choosing between them depends on your specific application requirements and user constraints for scalability and quality.

常见问题解答

「SFU 与 MCU 架构」课时是免费的吗？

是的 — 「SFU 与 MCU 架构」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Real-Time Streaming Systems (WebRTC + Live Data) 课程的其余内容，请升级到 CoddyKit PRO。 Real-Time Streaming Systems (WebRTC + Live Data) 课程共包含 4 节课。

「SFU 与 MCU 架构」这节课中我会学到什么？

了解选择性转发单元（SFU）和多点控制单元（MCU）在多方 WebRTC 通话中的区别。你通过在浏览器中直接运行的动手代码来练习 Real-Time Streaming Systems (WebRTC + Live Data)，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Real-Time Streaming Systems (WebRTC + Live Data) 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Real-Time Streaming Systems (WebRTC + Live Data) 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 1 节课，共 4 节。

「SFU 与 MCU 架构」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Real-Time Streaming Systems (WebRTC + Live Data) 课中编写并运行代码吗？

能。每节 Real-Time Streaming Systems (WebRTC + Live Data) 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Real-Time Streaming Systems (WebRTC + Live Data)