MCU vs SFU vs Mesh

1:1 звонок в WhatsApp работает без серверов (P2P). Google Meet с 100 участниками - через SFU. Видеоконференция на PSTN телефоне - через MCU. Три разных архитектуры для трёх разных задач. Как понять какая нужна?

• **Whereby** (formerly appear.in) начал с чистого Mesh WebRTC без серверной инфраструктуры - это позволило команде из 3 человек запустить продукт и достичь 1M MAU. При превышении 4 участников в комнате автоматически переключается на SFU (собственная реализация на WebRTC). Типичный пример эволюции от Mesh к SFU.
• **Zoom** использует SFU с Active Speaker Detection: клиент декодирует 3-5 потоков (активный спикер + несколько плиток), а не все N. При 1000 участниках это принципиально - иначе клиент тратил бы 1000 * 2 Mbps на download и CPU на decode.
• **Cisco WebEx** исторически строился на MCU для совместимости с legacy H.323 и SIP endpoint'ами (conference room системы Polycom, Tandberg). MCU микширует WebRTC, H.323 и PSTN звонки в единый поток. Переход на SFU для WebRTC клиентов при сохранении MCU для legacy.
• **Discord** динамически выбирает топологию: голосовые каналы до 4 человек = Mesh P2P (минимальная latency для gaming), 5+ = Go SFU. Это позволяет геймерам получать <50ms latency при малых группах - критично для координации в real-time играх.

MCU

MCU (Multipoint Control Unit) - медиасервер, который декодирует потоки от всех участников, микширует их в одно композитное видео/аудио, и кодирует обратно для каждого участника. Клиент всегда получает только один поток независимо от числа участников. Это дорого по CPU, но идеально для клиентов с ограниченными ресурсами (legacy телефоны, слабые устройства).

MCU используется для интеграции с PSTN (телефонными сетями) - телефон получает один микшированный аудиопоток. Cisco WebEx исторически строился на MCU архитектуре, что давало хорошую совместимость с legacy устройствами, но ограничивало масштаб. Современные платформы переходят на SFU с MCU только для аудио микшинга.

SFU как топология

SFU (Selective Forwarding Unit) в контексте сравнения топологий - это компромисс между MCU (тяжёлый сервер, лёгкий клиент) и Mesh (нет сервера, тяжёлый клиент). SFU не декодирует медиа, но маршрутизирует RTP пакеты. Upload = 1 поток, download = N-1 потоков, server CPU = O(streams).

Zoom использует гибридную модель: SFU для маршрутизации видео, Active Speaker Detection для определения кто говорит, и Spotlight mode (один спикер full screen). При Active Speaker режиме клиент декодирует 1-5 потоков вместо всех N - что снижает нагрузку на слабые устройства. Twilio Video переключается между SFU и P2P автоматически: 1:1 звонки = P2P, группы = SFU.

Mesh топология

Mesh - прямые P2P соединения между всеми участниками. Каждый участник отправляет N-1 upstream потоков и получает N-1 downstream. Число соединений растёт квадратично: N*(N-1)/2. Bandwidth ограничивает Mesh до ~4-6 участников на типичном интернет-подключении.

Appear.in (ныне Whereby) начинал с чистого Mesh WebRTC - именно это позволило им быстро запустить продукт без серверной медиаинфраструктуры. При росте перешли на SFU для комнат >4 участников. Discord использует Mesh для малых голосовых каналов (<4 участников) и переключается на их Go SFU для больших групп. Facebook Messenger 1:1 calls - Mesh P2P.

Simulcast и SVC

Simulcast - отправка нескольких версий одного видеопотока с разным качеством (low/mid/high). SFU выбирает нужный layer для каждого подписчика в зависимости от пропускной способности. SVC (Scalable Video Coding) - альтернативный подход: один поток, но с кодированием иерархических слоёв - базового (240p) и дополнений (480p, 720p).

Google Meet использует VP9 SVC: один поток с 3 spatial layers (360p/720p/1080p) и 3 temporal layers. Это вдвое эффективнее Simulcast по upload bandwidth - кодируется один поток вместо трёх. Zoom использует H.264 Simulcast. Agora поддерживает оба режима. Apple использует H.265 SVC в FaceTime Group Calls для эффективной адаптации к сети участников.

Итоги

• **Mesh**: нет сервера, upload растёт как N-1, масштаб 3-6 участников. Минимальная latency. Используется для 1:1 и малых групп.
• **SFU**: upload = 1 поток, download = N-1, server CPU = routing. Масштаб до 500+ участников. Индустриальный стандарт для видеоконференций (Zoom, Meet, Twilio).
• **MCU**: upload = 1, download = 1 composite, server CPU = O(N) decode+encode. Совместимость с legacy устройствами. Используется для PSTN интеграции.
• **Simulcast** (H.264/VP8): 3 версии одного потока, SFU выбирает layer. **SVC** (VP9/AV1): один поток с иерархическими слоями - эффективнее по upload.

Связанные темы

Выбор топологии определяет всю архитектуру системы - от STUN/TURN до клиентского кода:

• SFU архитектура — Детальное рассмотрение SFU: mediasoup, Janus, масштабирование кластера
• Data Channels — В Mesh каждый DataChannel требует отдельного RTCPeerConnection; в SFU DataChannels можно мультиплексировать через один путь клиент-SFU
• STUN и TURN — Mesh создаёт N*(N-1)/2 ICE соединений, каждое потенциально через TURN; SFU создаёт N соединений клиент-SFU - принципиально меньше TURN нагрузки

Вопросы для размышления

• Discord динамически переключается между Mesh и SFU по числу участников. Какие проблемы возникают при этом переключении в runtime, и как их решить без разрыва звонка?
• Google Meet показывает не более 49 видеоплиток одновременно даже при 100+ участниках. Как SFU и Simulcast участвуют в реализации этого ограничения?
• Simulcast требует тройного upload bandwidth от клиента. Как веб-конференции определяют, поддерживает ли конкретный браузер/устройство Simulcast, и что делают при его отсутствии?

Связанные уроки

• sd-06-load-balancer