WebRTC основы

Google Meet для звонка двух человек вообще не трогает видеопоток на своих серверах - пиксели летят напрямую из браузера в браузер. Это WebRTC P2P, и именно так работает реальный realtime video.

• **Whereby** (видеоконференции) строит весь продукт на WebRTC P2P для 1-1 звонков, переключаясь на SFU только при >2 участниках. P2P снижает их серверные расходы на медиа до нуля для большинства звонков
• **Twilio Video** обрабатывает миллионы WebRTC сессий в день. Их статистика: 85% соединений через STUN (P2P через NAT), 5% требуют TURN relay, 10% - прямая локальная сеть
• **Figma** использует WebRTC DataChannel для cursor sharing в мультиплеере - P2P data, не медиа. Это быстрее чем через сервер при прямом соединении
• **Daily.co** публикует open WebRTC stats: среднее время ICE negotiation - 300-800ms в зависимости от типа сети и наличия TURN

Webrtc Concept

WebRTC (Web Real-Time Communication) - набор API и протоколов для прямой peer-to-peer коммуникации между браузерами без промежуточного сервера для медиа-потока. Google открыл WebRTC в 2011 году, сегодня это основа Google Meet, Whereby, Daily.co и тысяч других видеосервисов.

Ключевое отличие от обычного WebSocket или HTTP: данные идут **напрямую между браузерами**, минуя сервер. Для 100 участников видеоконференции это означает 100x экономию серверного трафика по сравнению с relay-архитектурой. Но прямое соединение через NAT и firewall - нетривиальная задача, которую решает ICE.

**Числа:** Google Meet при P2P соединении двух участников - видео идёт напрямую, сервер не видит пикселей. При >2 участниках Meet переключается на SFU (Selective Forwarding Unit) - сервер форвардит потоки, но не декодирует. Экономия трафика vs полноценного relay: 40-80% в зависимости от сети.

Ice Framework

ICE (Interactive Connectivity Establishment) - протокол для нахождения лучшего пути между двумя peers через NAT и firewall. Браузер собирает список **ICE кандидатов** - возможных адресов для соединения - и пробует их в порядке приоритета.

Три типа ICE кандидатов по убыванию приоритета: **host** - локальный IP (работает в одной сети), **srflx** (server reflexive) - публичный IP, узнанный через STUN (работает через NAT), **relay** - адрес TURN сервера (работает всегда, но через relay).

**ICE статистика из продакшна:** Twilio измеряет что ~85% WebRTC соединений устанавливаются через srflx (STUN), ~10% через host (локальная сеть), и только ~5% требуют TURN relay. Но эти 5% - корпоративные клиенты за строгим firewall, которые без TURN вообще не могли бы звонить. Поэтому TURN обязателен для production.

Sdp

SDP (Session Description Protocol) - текстовый формат для описания медиасессии: какие кодеки поддерживаются, какой порт использовать, параметры шифрования. SDP не изобретение WebRTC - он существует с 1998 года (RFC 2327) и используется в VoIP, SIP, RTSP.

В WebRTC SDP - это 'резюме' peer'а: 'я умею H264 и VP8, поддерживаю opus для аудио, DTLS для шифрования, вот мои ICE credentials'. Negotiation - это сравнение двух резюме и выбор наилучших общих параметров.

**Зачем знать SDP руками?** Большинство разработчиков никогда не парсят SDP вручную - браузер создаёт его через `createOffer()`. Но при debugging WebRTC соединений умение читать SDP критично: например, если соединение падает из-за несовместимости кодеков - это видно в SDP. Инструмент: `webrtc-internals` в Chrome (chrome://webrtc-internals).

Offer Answer

Offer/Answer - двухшаговый протокол установки WebRTC соединения. Инициатор создаёт **offer** (SDP с своими возможностями), отправляет через signaling. Получатель создаёт **answer** (SDP с выбранными общими параметрами), отправляет обратно. После обмена - соединение готово к ICE negotiation.

**Trickling ICE** - оптимизация: не ждать сбора всех ICE кандидатов перед отправкой offer, а отправлять их по мере нахождения (`onicecandidate`). Это ускоряет установку соединения на 500-2000ms. Все современные WebRTC реализации используют trickle ICE по умолчанию.

Итоги

• WebRTC = P2P медиа напрямую между браузерами; signaling server нужен только для первоначального обмена SDP и ICE, к медиа он не прикасается
• ICE собирает кандидатов трёх типов (host/srflx/relay) и выбирает лучший путь; TURN обязателен для корпоративных сетей
• Offer/Answer - двухшаговый обмен SDP для согласования кодеков и параметров; trickle ICE ускоряет установку соединения на 500-2000ms

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

WebRTC - это стек протоколов, каждый из которых решает отдельную задачу:

• Signaling сервер — Следующий урок: реализация signaling через WebSocket и perfect negotiation pattern для обработки race conditions
• WebSocket — Signaling channel для обмена SDP/ICE обычно реализуется через WebSocket - это транспорт для bootstrapping WebRTC соединения
• CRDT DataChannel — WebRTC DataChannel можно использовать как P2P transport для CRDT-операций - альтернатива серверному relay

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

• Если WebRTC P2P так эффективен, почему Zoom и Google Meet при большой конференции переключаются на SFU-архитектуру с сервером?
• TURN сервер видит весь медиатрафик при relay. Как WebRTC обеспечивает приватность при этом?
• Trickle ICE отправляет кандидатов по мере нахождения, не дожидаясь всех. Какая race condition может возникнуть если answer придёт раньше всех ICE кандидатов?

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

• net-14-udp
• net-23-https-tls