WebRTC масштабирование

Google Meet обслуживает миллионы одновременных звонков по всему миру. Один SFU в Virginia не справится - как строится глобальная медиаинфраструктура?

• **Livekit Cloud** - 20+ региональных PoP, клиент через latency measurement выбирает ближайший SFU, inter-region backbone на выделенных каналах, цена $0.001/минуту участника
• **Jitsi Octo** - cascading topology для webinar-scale: UN General Assembly использует Jitsi с Octo для трансляций 100K+ слушателей через несколько региональных нод
• **Cloudflare Calls** - WebRTC SFU на базе Cloudflare Workers и anycast network 300+ PoP, медиа входит в ближайший edge без управления собственной инфраструктурой

Cascading SFU

Один SFU обрабатывает порядка 500-1000 участников при типичной нагрузке (VP8, 720p). Для большой конференции на 5000+ участников нужна **cascading** (каскадная) архитектура: несколько SFU связаны между собой server-to-server соединениями, каждый держит свою группу клиентов, но форвардирует медиа между собой.

Механика: SFU-A соединяется с SFU-B через WebRTC или внутренний RTP тоннель. Когда пользователь на SFU-A говорит, его аудио/видео форвардируется на SFU-B, который раздаёт его своим клиентам. Связи между SFU минимальны: только активные потоки, не все участники всем. Livekit называет это **inter-node forwarding**, Jitsi - **Octo** (Olga's Cascading Topology for Oceans).

Jitsi Octo обеспечивает конференции до 100,000 участников (webinars). Реальный пример: UN General Assembly трансляции используют Jitsi с Octo cascading - несколько SFU нод в разных регионах, каждая держит группу слушателей.

Global Distribution

Глобально распределённая WebRTC инфраструктура размещает SFU ноды в разных регионах - клиент подключается к ближайшей. Это снижает RTT: участник из Токио не делает round trip до дата-центра в Вирджинии для каждого медиапакета. SFU в Токио держит его соединение, а межрегиональный trunk доставляет его медиа в другие регионы.

Livekit Cloud строит глобальную сеть на 20+ PoP (Points of Presence): клиент подключается к ближайшему по WebRTC, ноды связаны через выделенные backbone каналы. При трансконтинентальном звонке Москва-Нью-Йорк: Москва -> SFU-EU -> backbone -> SFU-US -> Нью-Йорк. RTT медиа: ~30ms (Москва-EU) + ~60ms (EU-US) + ~20ms (US-NY) = ~110ms. Без PoP - ~180ms.

Cloudflare Calls строится на Workers и Cloudflare's global anycast network - 300+ PoP. Медиа входит в ближайший edge, дальше идёт по Cloudflare backbone. Это позволяет предложить WebRTC SFU без управления собственной медиаинфраструктурой.

Geo Routing

**Geo routing** определяет, к какому SFU подключится клиент. Варианты: DNS-based (GeoDNS возвращает IP ближайшего SFU по IP клиента), HTTP redirect (signaling сервер измеряет RTT до нескольких SFU и направляет на лучший), BGP Anycast (один IP, маршрутизация на уровне сети).

GeoDNS - самый простой, но IP-to-region mapping неточен (~15% ошибок для мобильных). Метод с замером RTT точнее: клиент делает HTTP HEAD к 3-4 региональным endpoint'ам, выбирается тот, от которого пришёл самый быстрый ответ. Так работает Twilio TURN server selection - клиент сам выбирает ближайший relay.

Daily.co публикует: geo routing через latency measurement снижает медиану RTT на 35% по сравнению с GeoDNS для мобильных пользователей. Особенно критично в Азии, где IP-to-region mapping особенно неточен для carrier NAT сетей.

WebRTC Инфраструктура

Полная WebRTC инфраструктура включает несколько компонентов помимо SFU: **TURN серверы** для прохода через строгие NAT и корпоративные файрволы (до 15% соединений требуют TURN), **STUN серверы** для определения публичного IP, **Signaling сервер** для обмена SDP offer/answer и ICE candidates.

TURN трафик - самый дорогой: весь медиапоток идёт через relay сервер. При 15% penetration и средней meeting 30 минут 720p (1.5 Mbps) - это значительные расходы. Twillio и Daily оценивают TURN в 20-30% от общих infrastructure costs. Поэтому TURN серверы размещают рядом с SFU нодами чтобы минимизировать лишние hop'ы.

• **STUN** - определение публичного IP/port (бесплатно, UDP 3478)
• **TURN** - relay сервер для строгого NAT (дорого, весь трафик через него)
• **SFU** - медиасервер, форвардирует RTP между участниками
• **Signaling** - WebSocket/HTTP сервер для SDP и ICE exchange
• **Recording** - pipeline для захвата потоков (опционально)

Livekit Cloud берёт $0.001 за минуту участника - это покрывает SFU + TURN + signaling + STUN. При 1M минут/месяц = $1000. Самостоятельная инфраструктура на той же нагрузке: EC2 + Coturn + сеть = $600-800, но требует DevOps команды.

Итоги

• **Cascading SFU** связывает несколько нод server-to-server, форвардируя только активных спикеров - линейное масштабирование без N^2 роста трафика
• **Global distribution** - региональные SFU рядом с клиентами снижают RTT: клиент в Токио видит 18ms до ближайшего SFU вместо 170ms до Virginia
• **Geo routing** через latency measurement точнее GeoDNS на 35% для мобильных; TURN серверы - дорогой (20-30% costs) но необходимый компонент для 15% соединений

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

Масштабирование WebRTC опирается на базовые принципы распределённых систем:

• Adaptive Bitrate — SVC снижает количество inter-SFU потоков в 3x - напрямую влияет на cascading эффективность
• CDN и Edge — Cloudflare Calls строится на CDN edge nodes - WebRTC как частный случай edge computing
• Load Balancing — Geo routing - специализированный load balancer с учётом latency, а не только CPU/memory

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

• При cascading SFU с 3 нодами по 500 участников и одним активным спикером - сколько дополнительных RTP потоков создаёт cascading? Как это меняется при 5 активных спикерах?
• Livekit использует latency measurement для geo routing, Cloudflare - anycast. В каких сценариях anycast менее эффективен, чем явный latency test?
• TURN сервер стоит дорого при 15% использовании. Как построить TURN capacity planning: какая ёмкость нужна при 10K одновременных участников с известным p15 penetration?

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

• sd-03-scalability