Архитектура и жизненный цикл WebRTC‑сессий в видеочатах

Современные видеочаты и анонимные мессенджеры построены на стеке технологий WebRTC (Web Real-Time Communication). Это открытый стандарт, обеспечивающий передачу аудио, видео и данных в реальном времени напрямую между браузерами или устройствами пользователей без необходимости установки плагинов; В основе всего процесса лежит сессия — временной интервал, в течение которого происходит установление соединения, обмен медиапотоками и разрыв связи.

Ниже подробно разобраны этапы жизненного цикла сессии, протоколы прохождения NAT, архитектурные паттерны и особенности анонимных чатов.

Архитектура сессии: P2P vs SFU/MCU

Выбор топологии определяет, как именно будут маршрутизироваться медиапотоки во время сессии.

Peer-to-Peer (P2P) — Прямое соединение

Идеальный сценарий для 1-на-1 вызовов. После прохождения сигнализации и ICE-negoциации браузеры устанавливают прямой UDP-канал между собой. Данные не проходят через медиасервер, что минимизирует задержку (latency) и нагрузку на инфраструктуру разработчика.

• Плюсы: Минимальная латентность, отсутствие затрат на пропускную способность сервера, максимальная приватность (нет промежуточного узла).
• Минусы: Не масштабируется на группы > 3-4 человек (требуется N² соединений), сложно обойти симметричные NAT без TURN.

SFU (Selective Forwarding Unit) — Выборочная пересылка

Стандарт де-факто для групповых вызовов и современных анонимных чатов (например, Clubhouse, Discord, Telegram Calls). SFU-сервер принимает входящие потоки от каждого участника и пересылает их остальным без перекодирования (транскодинга).

• Участник отправляет 1 исходящий поток и получает N-1 входящих.
• Сервер может присылать разные качества видео (Simulcast / SVC) в зависимости от канала получателя.
• Нагрузка на CPU сервера низкая (нет кодирования), основная нагрузка — на сетевую карту (bandwidth).

MCU (Multipoint Control Unit) — Смешивание

Устаревший, но все еще используемый в некоторых корпоративных системах подход. Сервер декодирует все потоки, смешивает их в один композитный (например, «сетка» 4х4) и кодирует обратно для каждого участника.

• Плюсы: Клиент получает всего 1 поток (экономия полосы клиента).
• Минусы: Огромная нагрузка на CPU/GPU сервера, добавляемая задержка на кодирование, фиксированный лейаут.

Фаза сигнализации (Signaling): «Договорная встреча»

WebRTC не определяет протокол сигнализации — это задача приложения (обычно WebSocket, HTTP/2, MQTT или gRPC). До того как медиапотоки потекут, пиры должны обменяться метаданными.

SDP (Session Description Protocol)

SDP, это протокол переговоров между узлами. Он содержит:

• Список доступных аудио- и видеокодеков (VP8, VP9, H.264, H.265, AV1, Opus, G.711).
• ICE-кандидаты (IP-адреса и порты для подключения).
• Информацию о топологии сети и полосе пропускания;
• Отпечатки DTLS-сертификатов для шифрования.
• Параметры SCTP (для Data Channels).

Процесс Offer/Answer

1. Initiator (Caller) создает RTCPeerConnection, добавляет треки (камера/микрофон), генерирует Offer (SDP) и отправляет через сигнальный сервер.
2. Receiver (Callee) получает Offer, устанавливает его как RemoteDescription, создает Answer (SDP) со своими кодеками и ICE-кандидатами, отправляет обратно.
3. Обе стороны устанавливают LocalDescription и RemoteDescription. Начинается ICE-negoциация.

ICE Framework: Пробивание NAT и Firewall

ICE (Interactive Connectivity Establishment), это фреймворк, задача которого — найти рабочий путь между двумя узлами за NAT/Firewall. Это критически важный этап для анонимных чатов, где пользователи часто за корпоративными фаерволами или симметричными NAT.

Типы ICE-кандидатов

• Host Candidate: Локальный IP/порт интерфейса (Wi-Fi, Ethernet, VPN). Работает только в одной LAN.
• Server Reflexive (srflx): Публичный IP/порт, полученный через STUN-сервер. Показывает, как внешний мир видит клиента.
• Relay Candidate (TURN): IP/порт на TURN-сервере. Медиа трафик идет через сервер. Используется как fallback.

STUN (Session Traversal Utilities for NAT)

Легковесный протокол (RFC 5389). Клиент шлет запрос на STUN-сервер, сервер отвечает: «Ты виден мне как IP:Port». Это позволяет клиенту узнать свой внешний адрес и сгенерировать srflx-кандидаты. STUN не проксирует трафик.

TURN (Traversal Using Relays around NAT)

Тяжелая артиллерия (RFC 5766). Если прямое соединение (P2P) не удалось (симметричный NAT, блокировка UDP), клиент устанавливает TCP/TLS-соединение с TURN-сервером и просит выделить порт для ретрансляции.

• TURN over TLS (TURNS): Шифрованный канал управления и данными (порт 443), проходит почти любые корпоративные прокси и DPI.
• Цена: Весь медиа-трафик идет через сервер. Требует мощных каналов и оплаты трафика.

ICE Nomination & Controlling/Controlled

Стороны проверяют пары кандидатов (Connectivity Checks — STUN Binding Requests) по приоритету. Роль Controlling (обычно Caller) делает финальный выбор (Nominated) пары, которую будут использовать обе стороны.

Транспортный уровень: Безопасность и Надежность

После успешного ICE соединение установлено на уровне UDP. Но WebRTC требует шифрования и контроля перегрузки.

DTLS (Datagram Transport Layer Security)

Рукопожатие происходит поверх UDP до передачи медиа. Используются отпечатки сертификатов, обменянные в SDP (функция a=fingerprint:sha-256 ...). Обе стороны проверяют отпечатки — это защита от MITM (Man-in-the-Middle). Ключи, выработанные в DTLS, экспортируются в SRTP.

SRTP (Secure Real-time Transport Protocol)

Сам медиа-трафик (аудио/видео) шифруется по ключам из DTLS (DTLS-SRTP). Используются шифры AES_CM_128_HMAC_SHA1_80 или AEAD_AES_256_GCM. Защищает конфиденциальность и целостность пакетов;

SCTP over DTLS (Data Channels)

Для текстового чата, файлов, сигнализации внутри сессии (например, переключение камеры) используется SCTP (Stream Control Transmission Protocol), инкапсулированный в DTLS.

• Поддерживает надежную (как TCP) и ненадежную (как UDP, но с порядком) доставку.
• Мультиплексирование: много логических потоков внутри одного UDP-порта (порт 50000 по умолчанию).
• В анонимных чатах Data Channels часто используются для E2E-шифрованного текста (Signal Protocol / MLS), не доверяя серверу сигнализации.

Контроль перегрузки (Congestion Control)

WebRTC использует GCC (Google Congestion Control) / NADA / SCReAM. Анализируется задержка (OWD, One Way Delay) и потеря пакетов (REMB / Transport-wide CC). Энкодер динамически меняет битрейт/разрешение видео в реальном времени.

Особенности сессии в Анонимных чатах

Анонимность накладывает отпечаток на всю архитектуру сессии.

Защита IP-адреса (IP Leak Prevention)

• Проблема: ICE собирает все локальные IP (включая VPN, Docker, IPv6), которые уходят в SDP и могут утечь собеседнику до принятия вызова.
• Решение: Политика iceTransportPolicy: "relay" (принудительное использование только TURN-кандидатов). Это скрывает реальный IP, но увеличивает задержку и нагрузку на TURN.
• mDNS ICE candidates: В браузерах (Chrome/Firefox) локальные IP маскируются в виде a8b3c2d1.local до момента согласия пользователя на звонок.

E2EE (End-to-End Encryption) для медиа

В SFU-архитектуре сервер видит SRTP-пакеты (заголовки RTP, SSRC, sequence numbers), но не может их расшифровать без DTLS-ключей. Для полной анонимности:

• Используется Insertable Streams API (WebRTC Encoded Transform) для шифрования фреймов до отправки в RTCPeerConnection (SFrame / MLS).
• SFU становится «слепым» переключателем (blind forwarder).

Сигнализация без идентификации

• WebSocket-соединение к сигнальному серверу проходит через Tor / VPN / Domain Fronting;
• Аутентификация — через одноразовые токены или Zero-Knowledge Proofs, без логина/пароля.
• Metadata minimization: в SDP не передаются device names, user agents, версии ОС.

Data Channels для текста

Текстовые сообщения в анонимном чате лучше идти через Data Channels (SCTP) с собственным слоем E2EE (Double Ratchet / MLS), а не через сигнальный сервер. Это исключает логирование переписки на бэкенде.

Жизненный цикл сессии: Пошаговый сценарий

1. Init: Пользователь А нажимает «Вызвать». Создается RTCPeerConnection (конфиг: STUN/TURN URLs, iceTransportPolicy, bundle policy).
2. Media Capture: getUserMedia запрашивает камеру/микрофон. Треки добавляются в PC (addTrack).
3. Signaling (Offer): createOffer -> setLocalDescription. SDP Offer уходит по WebSocket (сигнализация).
4. Signaling (Answer): Пользователь Б получает Offer, setRemoteDescription, getUserMedia, createAnswer -> setLocalDescription. Answer уходит обратно.
5. ICE Gathering: Обе стороны собирают кандидатов (host, srflx via STUN, relay via TURN). Кандидаты триклят (trickle ICE) через сигнализацию в реальном времени.
6. ICE Connectivity Checks: STUN Binding Requests/Responses между парами кандидатов. Состояние iceConnectionState: checking -> connected / completed.
7. DTLS Handshake: Рукопожатие поверх выбранной пары UDP. Проверка отпечатков сертификатов. Состояние connectionState: connected.
8. Media Flow: Начинается обмен SRTP пакетами. RTCP Sender/Receiver Reports для мониторинга QoS. PLI/FIR/NACK для восстановления потерь.
9. Mid-session Changes: Renegotiation (add/remove track, change codec, simulcast layers) -> новый Offer/Answer. ICE Restart при смене сети (WiFi -> LTE).
10. Termination: pc.close. Отправка BYE по сигнализации. Освобождение портов TURN, остановка треков.