SFU архитектура

Zoom поддерживает 1000 участников в одной встрече. При Mesh P2P топологии каждый отправлял бы 999 видеопотоков - это 999 * 2 Mbps = 2 Gbps upload. Это невозможно. Как Zoom это решает?

• **Google Meet** использует SFU для встреч >2 участников. Каждый участник отправляет только один upstream поток на SFU, который избирательно доставляет нужные потоки каждому. При 100 участниках: 100 * 1 upstream = 100 Mbps на сервер vs 100 * 99 = 9.9 Gbps при Mesh.
• **LiveKit** (open-source SFU, Apache 2.0) развёртывается на Kubernetes и используется Daily.co, Mux, StreamElements. Написан на Go, обрабатывает 1000+ участников на одном сервере c40.large. GitHub: 8k+ stars за 2 года.
• **Twilio Video** строит SFU сеть на AWS в 12 регионах. Комнаты автоматически routing'уются в ближайший к большинству участников регион. При комнате с участниками в EU и US используется cascade между регионами.
• **mediasoup** используется в production у Skype Web (Microsoft) и ряде European telehealth платформ. Один Worker процесс обрабатывает до 500 concurrent video producers на современном CPU ядре. Архитектурно ближе всего к 'SFU как библиотека'.

Что такое SFU

SFU (Selective Forwarding Unit) - медиасервер, который получает медиапотоки от участников и избирательно пересылает их нужным подписчикам. В отличие от MCU, SFU не декодирует и не перемикширует видео - оно проходит насквозь в исходном кодированном виде. Это делает SFU дёшевым по CPU, но требует от клиента декодировать N потоков.

SFU - индустриальный стандарт для групповых видеозвонков >3 участников. Google Meet, Zoom, Twilio Video, Agora, Daily.co - все используют SFU или вариации. Ключевое преимущество: upload bandwidth участника не растёт с числом участников (только 1 upstream). AWS Chime SDK, LiveKit, mediasoup - open-source SFU frameworks.

mediasoup

mediasoup - Node.js SFU библиотека с C++ ядром для обработки RTP. Не является самостоятельным сервером - это строительный блок, из которого разработчик строит приложение. Поддерживает simulcast, SVC, DataChannels, pipe между worker процессами для горизонтального масштабирования.

mediasoup используют Skype Web (Microsoft), Twitch (streaming experiments), множество EdTech платформ. Один Worker процесс на современном ядре CPU обрабатывает ~500 video producers. LiveKit (open-source конкурент Zoom) в версии 1.0 переписал своё SFU ядро на Go, но использует идеи mediasoup для RTP routing.

Janus Gateway

Janus - open-source WebRTC gateway на C от Meetecho. В отличие от mediasoup (библиотека), Janus - полноценный сервер с REST/WebSocket/RabbitMQ API и системой плагинов. VideoRoom plugin реализует SFU конференции, VideoCall - 1:1 звонки, Streaming - live broadcast.

Janus используется в Jitsi Meet как SFU (Jicofo), в ряде telehealth платформ и live streaming сервисов. Преимущество перед mediasoup - готовый сервер без написания кода. Недостаток - менее гибкий для кастомной логики. Jitsi Meet (15M+ MAU) мигрирует с Janus на собственный SFU (Jitsi Videobridge) написанный на Java для лучшего масштабирования.

Масштабирование SFU

Один SFU сервер ограничен CPU и bandwidth. Для тысяч concurrent комнат нужна кластеризация: stateful routing (комната привязана к конкретному SFU узлу), cascade SFU (SFU соединены между собой), или географическое распределение (CDN-like).

LiveKit (open-source, AWS/GCP deploy) использует distributed SFU: комнаты могут мигрировать между узлами, NATS.io для межузловой коммуникации. Zoom строит geo-distributed SFU с cascade: участники из разных регионов встречаются через каскадный поток между дата-центрами. Agora глобальная SD-RTN сеть - 200+ PoP с SFU узлами, автоматический выбор ближайшего.

Итоги

• **SFU** пересылает кодированные RTP пакеты без decode. Upload участника = 1 поток независимо от числа коллег в комнате. CPU нагрузка O(streams), не O(pixels).
• **mediasoup** - SFU библиотека (C++ Workers + Node.js API). Максимальный контроль над логикой routing, simulcast, SVC. Требует написания SFU кода.
• **Janus Gateway** - готовый SFU сервер с плагинами (VideoRoom, Streaming). Быстрый старт, меньше гибкости для кастомной логики.
• **Масштабирование** требует stateful routing (consistent hashing по room_id) и cascade topology для cross-datacenter комнат.

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

SFU - центральный элемент групповых видеозвонков. Понимание его требует знания смежных уровней:

• MCU vs SFU vs Mesh — SFU - одна из трёх топологий; сравнение помогает понять trade-offs и когда выбирать каждую
• Media Streams — MediaStream от getUserMedia добавляется через addTrack() и попадает на SFU как Producer; SFU возвращает Consumers для других участников
• STUN и TURN — Каждое ICE соединение клиент-SFU требует STUN для discovery и TURN если клиент за Symmetric NAT; SFU сам выступает как публичный endpoint

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

• mediasoup создаёт Worker на каждое CPU ядро. Если в комнате 50 участников и 8 Workers - как распределить Producers и Consumers чтобы минимизировать cross-worker pipe transport?
• SFU знает битрейт каждого Producer через RTCP. Как это знание можно использовать для адаптации качества видео для участника с плохой сетью, не прерывая остальных?
• Как cascade SFU решает проблему участников из разных регионов - и какую дополнительную задержку это добавляет по сравнению с Mesh P2P между соседними участниками?

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

• sd-06-load-balancer