SFUとMCUのアーキテクチャ
複数人で行うWebRTC通話におけるSelective Forwarding Unit(SFU)とMultipoint Control Unit(MCU)の違いを理解します。
「SFUとMCUのアーキテクチャ」はCoddyKit上の無料Real-Time Streaming Systems (WebRTC + Live Data)レッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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 participantsSFU: 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のアーキテクチャ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Real-Time Streaming Systems (WebRTC + Live Data)コースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Real-Time Streaming Systems (WebRTC + Live Data)コースには全4レッスンが含まれています。
「SFUとMCUのアーキテクチャ」で何を学びますか?
複数人で行うWebRTC通話におけるSelective Forwarding Unit(SFU)とMultipoint Control Unit(MCU)の違いを理解します。 ブラウザで直接実行するハンズオンコードでReal-Time Streaming Systems (WebRTC + Live Data)を演習し、24時間対応の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フィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- SFUとMCUのアーキテクチャ
- シグナリングサーバーの負荷分散
- 分散STUN/TURNサービス
- 地理的スケールに向けたSFUのカスケード