WebRTC без эзотерики

TL;DR

WebRTC, или Web Real-Time Communication, – это открытый стандарт, который позволяет браузеру или мобильному приложению передавать аудио, видео и произвольные данные другому браузеру или приложению с задержкой, достаточно низкой для живого разговора без перебивок. На WebRTC работают Google Meet, голосовые каналы Discord, видеозвонки WhatsApp, звонки в Facebook Messenger, практически любой современный сервис телемедицины и всё больше платформ live-shopping и онлайн-обучения. Под простым JavaScript-интерфейсом – одним объектом RTCPeerConnection – лежит стек из девяти IETF RFC, рекомендации W3C и медиа-плоскости, которая проходит через NAT, шифрует каждый пакет и адаптируется к доступной полосе. Эта статья объясняет, что такое WebRTC, что делает каждый элемент его стека, почему минимум задержки 100–300 мс, тогда как у HLS – 5–30 секунд, и что нужно понимать продуктовой команде, прежде чем запускать WebRTC на масштабе.

Почему это важно

Если вы строите продукт, где два или более человека видят и слышат друг друга в реальном времени – видеовстреча, консультация врача, live-аукцион с голосом зрителей, фитнес-урок с тренером, который контролирует технику, – WebRTC почти наверняка правильный транспорт, и вы обязаны понимать его достаточно, чтобы оценить, заложить в бюджет и обсудить с инженерами. Технология стала рекомендацией W3C в январе 2021 года, в том же месяце IETF опубликовала набор протоколов из девяти RFC (8825–8835), а исходная JavaScript-спецификация была уточнена второй семьёй RFC между 2022 и 2024 годами. К 2026 году каждый современный браузер поставляет WebRTC по умолчанию, а серверная open-source-экосистема – mediasoup, Janus, LiveKit, Jitsi Videobridge, Pion – достаточно зрелая, чтобы компетентная команда запускала конференц-продукт за недели, а не годы. Подвох в том, что простая картинка «два браузера разговаривают друг с другом» неверна, как только у вас больше трёх участников или публичная сеть, а цена непонимания того, что WebRTC есть и чего в нём нет, оплачивается ребуферами зрителей, несостоявшимися медицинскими консультациями и переписыванием кода. Цель этой статьи – сделать картинку правильной, не делая её пугающей.

Что такое WebRTC на самом деле

Самое короткое точное определение: WebRTC – это набор стандартов, превращающих браузер в медиа-эндпоинт, способный отправлять и принимать аудио, видео и данные в реальном времени по публичному интернету, со встроенным шифрованием, обходом NAT и адаптацией к полосе. Стандарты живут в двух местах: W3C владеет JavaScript API, на котором пишет фронтенд-разработчик, а IETF – протоколами на проводе, которые байты соблюдают, покинув браузер. Документ W3C – это WebRTC: Real-Time Communication in Browsers, формально рекомендация с 26 января 2021 года, пересмотренная в марте 2023 года, чтобы включить candidate amendments, уже отгруженные в продакшен (W3C, WebRTC: Real-Time Communication in Browsers, 2023). Документы IETF – это девять RFC, опубликованные одним пакетом в январе 2021 года, а позже расширенные JSEP'ом в виде RFC 9429 в апреле 2023 года, который сделал RFC 8829 устаревшим (IETF, RFC 9429, JavaScript Session Establishment Protocol, 2023).

Практический пересказ, прежде чем мы погрузимся в стек: WebRTC – это набор всего, что нужно, чтобы вызов getUserMedia() на веб-странице создал объект MediaStream, этот поток был передан объекту RTCPeerConnection, и противоположная сторона соединения – другой браузер, мобильное приложение или сервер – получила кадры в пределах нескольких сотен миллисекунд и отрисовала их так, словно две точки соединены прямым кабелем. Всё, что стандартизирует WebRTC, существует, чтобы этот пересказ оставался верным при наличии NAT, файрволов, потерь пакетов, джиттера, асимметричной полосы и при ограничении, что байты никогда не должны идти в открытом виде.

Нажмите, чтобы увеличить

Откуда взялся WebRTC за один абзац

WebRTC начался в Google в 2010 году как покупка двух компаний: On2 Technologies, давшей видеокодек VP8, и Global IP Solutions, давшей аудиодвижок и устойчивый к сетевым проблемам real-time-стек, который раньше работал в десктопных продуктах для звонков. Google открыла исходники в мае 2011 года и тогда же предложила технологию как интернет-стандарт. IETF создала рабочую группу rtcweb; W3C создала WebRTC Working Group; обе организации координировались десять лет; стандарты пересекли финишную черту вместе в январе 2021 года (IETF Blog, WebRTC Standardized, 26 января 2021). Десятилетняя инкубация важна, потому что объясняет дизайн: WebRTC был построен для открытого веба с первого дня – поэтому модель безопасности обязательна, а не опциональна, поэтому каждый браузер реализует его одинаково, и поэтому им не владеет ни один вендор. Это единственный браузерный стандарт real-time-медиатранспорта, переживший plug-in-free переход, убивший Flash, Silverlight и Java-апплеты.

Пять вещей, которые делает WebRTC

Если очистить WebRTC до выполняемой работы, остаётся пять задач. Остальная статья раскрывает каждую; в этом разделе они только названы, чтобы у читателя была карта.

Первая задача – захват медиа: вытащить аудио и видео из микрофона и камеры в JavaScript-объект, которым можно манипулировать на странице. API браузера для этого – navigator.mediaDevices.getUserMedia(), описанный в дочерней спецификации W3C Media Capture and Streams (W3C, Media Capture and Streams, рекомендация с апреля 2025). На выходе – объект MediaStream, содержащий один или несколько объектов MediaStreamTrack, каждый из которых представляет одну аудио- или видеодорожку.

Вторая задача – согласование сессии: эндпоинты должны договориться о кодеках, частотах дискретизации аудио, разрешениях видео, обмене видео в дополнение к аудио и о том, как будут связаны их сетевые адреса. Договорённость выражается парой документов Session Description Protocol – offer и answer, – а правила их создания и применения описаны в JavaScript Session Establishment Protocol, RFC 9429 (IETF, RFC 9429, JSEP, апрель 2023). SDP за вас создаёт браузер; код приложения никогда не пишет SDP вручную. Что код приложения делает – это передаёт SDP-блобы от одного пира к другому. Эта передача – сигналинг, и WebRTC намеренно его не стандартизирует.

Третья задача – обход NAT и сетевых границ: найти путь через все NAT, файрволы и корпоративные прокси между эндпоинтами. Стандарт – Interactive Connectivity Establishment, RFC 8445, плюс помощники STUN (RFC 8489) и TURN (RFC 8656). ICE собирает все вероятные адреса, по которым эндпоинт может быть достижим – локальный IP, публичный IP, обнаруженный через STUN-сервер, и relayed-IP через TURN-сервер, – затем параллельно проверяет все комбинации адресов двух сторон, пока не найдёт работающую пару (IETF, RFC 8445, Interactive Connectivity Establishment, июль 2018).

Четвёртая задача – шифрование. WebRTC требует, чтобы каждый байт на проводе был зашифрован; режима в открытом виде не существует. Handshake использует Datagram Transport Layer Security, RFC 9147, UDP-дружелюбного кузена TLS, для согласования симметричных ключей; затем сами медиа едут внутри Secure Real-Time Transport Protocol, RFC 3711, с ключами, обменянными через расширение DTLS-SRTP, RFC 5764. Отпечатки, доказывающие, что DTLS-сертификаты принадлежат нужным эндпоинтам, переносятся внутри SDP – так канал сигналинга становится якорем доверия для медиа-канала (IETF, RFC 5764, DTLS Extension to Establish Keys for SRTP, май 2010).

Пятая задача – сам медиа-транспорт: как только зашифрованный UDP-канал открыт, кадры аудио и видео идут поверх Real-Time Transport Protocol, RFC 3550, а получатель сообщает отправителю, как ведёт себя сеть, через RTP Control Protocol, RFC 3550 §6. Петля RTP/RTCP – это то, что обеспечивает адаптацию полосы, восстановление потерянных пакетов и джиттер-буферизацию в WebRTC. Сторона data-каналов, если она задействована, использует Stream Control Transmission Protocol, RFC 4960, инкапсулированный в DTLS, – это сознательный выбор, дающий приложению надёжные упорядоченные байтовые потоки без head-of-line-blocking, который привнёс бы TCP.

Это всё, что делает WebRTC, написано без жаргона, где это возможно. Остальная часть статьи разбирает каждую задачу подробнее.

JavaScript-поверхность, до которой касается разработчик

Центральный объект спецификации W3C – RTCPeerConnection. Рабочий пример сводится к нескольким строкам и стоит того, чтобы прочитать его, даже если вы не пишете на JavaScript, потому что он показывает, насколько тонкий API доступен разработчику относительно протокольного стека под ним:

// 1. Получить локальный микрофон и камеру.
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });

// 2. Создать peer connection со STUN-сервером для обнаружения NAT.
const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});

// 3. Прицепить каждую локальную дорожку к peer connection.
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// 4. Когда приходит удалённая дорожка — отрисовать её.
pc.ontrack = (event) => {
  document.getElementById("remoteVideo").srcObject = event.streams[0];
};

// 5. Создать SDP-offer и отправить его через сигналинг-канал приложения.
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
mySignallingChannel.send({ type: "offer", sdp: offer.sdp });

Читатель, не видевший WebRTC API, часто спрашивает, где же вызов шифрования, где вызов адаптации полосы, где вызов обхода NAT. Честный ответ: ни одного из этих вызовов как отдельного API нет; они спрятаны внутри конструктора RTCPeerConnection и согласования, запускающегося при вызовах setLocalDescription и setRemoteDescription. Приложение отвечает только за два: захватить медиа и передать SDP offer и answer между пирами. Всё остальное – работа браузера (Mozilla MDN, RTCPeerConnection, 2026). Это сделано осознанно, и именно поэтому WebRTC потребовалось десять лет на стандартизацию.

Танец SDP offer/answer

Согласование между двумя пирами всегда идёт по одной схеме: offerer создаёт описание того, что хочет отправлять и принимать, answerer отвечает описанием того, на что согласен, и обе стороны применяют оба описания к своему локальному state-машине. Правила – RFC 9429 (JSEP). Документы – блобы Session Description Protocol, изначально определённого для телефонии в RFC 8866 (IETF, RFC 8866, Session Description Protocol, январь 2021).

SDP-offer для одного аудио-и-видеозвонка занимает около 40 строк. Поля, важные для понимания WebRTC: строки m= объявляют медиа-секцию, по одной на каждую аудио- или видеодорожку плюс одна на data-канал; строки a=rtpmap: перечисляют все кодеки, которые offerer готов принять, в порядке предпочтения; строка a=fingerprint: содержит SHA-256-отпечаток DTLS-сертификата, который offerer предъявит в handshake шифрования; строки a=ice-ufrag и a=ice-pwd содержат учётные данные, которыми ICE будет аутентифицировать пакеты connectivity-check; строки a=candidate: перечисляют все пары IP-и-порт, собранные offerer'ом как потенциальные локальные адреса. Answerer всё это читает, выбирает один кодек на медиа-секцию, выбирает пары IP-и-порт, которые будет использовать, подписывает свой DTLS-отпечаток в ответе и отправляет SDP обратно.

Арифметика согласования стоит того, чтобы показать её один раз, потому что это источник одного из вечных сюрпризов WebRTC – SDP большой. Типичный offer с аудио (Opus), видео (VP8, VP9, H.264, AV1), data-каналом и стандартным набором WebRTC header extensions выглядит примерно так:

1 session-level блок            +  6 строк
+ 3 медиа-секции               × 12 строк (m=, c=, a=rtcp, a=ice-ufrag, a=ice-pwd, a=fingerprint, a=setup, a=mid, a=sendrecv, a=rtcp-mux, a=rtpmap × N, a=fmtp × N)
+ 4 кодека на видеосекцию      ×  3 строки (rtpmap, rtcp-fb, fmtp)
+ 12 ICE-кандидатов            × 12 строк (по одной на a=candidate)
= примерно 240 строк, 8–10 КБ текста

Восемь килобайт – это мало на канале 100 Мбит/с, но это не бесплатно – и это нагрузка, которую сигналинг-каналу нужно передать до начала звонка. Продакшены, использующие trickle ICE (более частый паттерн в 2026), отправляют первоначальный SDP меньше – обычно 4 КБ – и дотрикливают строки candidate позже, по мере того как браузер их собирает.

Сигналинг: то, что WebRTC не стандартизировал

У WebRTC нет сигналинг-протокола. Стандарт явно об этом говорит: авторы JSEP сознательно оставили сигналинг за рамками, чтобы приложение могло выбрать тот транспорт, который подходит существующей инфраструктуре (RFC 9429, §1.1, апрель 2023). На практике сигналинг-канал почти всегда – WebSocket между каждым пиром и небольшим сервером, которым владеет приложение; сервер отвечает за маршрутизацию offer'ов нужному answerer'у, answer'ов обратно нужному offerer'у и trickled-кандидатов ICE в обоих направлениях. Сигналинг-сервер без других функций можно написать в несколько сотен строк кода на любом языке.

Неочевидное следствие: каждая команда, делающая WebRTC-продукт, пишет сигналинг-сервер. Некоторые остаются минимальными и переживают весь жизненный цикл продукта без изменений; другие обрастают функциями членства в комнатах, presence, контролем записи, координацией screen sharing и чатом – и тогда сигналинг-сервер становится нервной системой приложения. Open-source-фреймворки вроде LiveKit и mediasoup поставляют референсные реализации сигналинга; Janus и Jitsi Videobridge – свои; закрытые вендоры прячут его внутрь SDK. Канонического ответа нет, потому что нет канонической спецификации.

Где здесь Фора Софт

Фора Софт поставляет WebRTC-продукты с 2011 года – года, когда Google открыла исходники. За более чем 80 проектов в конференц-связи, телемедицине, e-learning, live-shopping и AR-VR-коллаборации команда писала сигналинг-серверы с нуля и интегрировала mediasoup, Janus, Jitsi, LiveKit и Pion как медиа-роутер. Паттерны, всплывающие в каждом проекте, – выбор топологии SFU, расчёт TURN-полосы, проектирование моста WebRTC → HLS для записи, защита сигналинг-сервера от room-bombing'а – это те же паттерны, что разбирает Block 8 раздела Learn. Эта статья – вход; остальные статьи блока идут глубже в каждую тему.

ICE, STUN и TURN: как байты находят друг друга

Самая сложная задача в WebRTC – связать два эндпоинта через публичный интернет, потому что у большинства эндпоинтов нет публично маршрутизируемого IP. Ноутбук в кофейне сидит за NAT кофейни, та – за carrier-grade NAT провайдера, тот – за каким бы то ни было файрволом провайдера; телефон на сотовом – за NAT оператора и, возможно, ещё и за оверлеем приватных IP. Собственная ОС эндпоинта знает только свой приватный адрес – обычно 192.168.x.x или 10.x.x.x – и понятия не имеет, как выглядит публичный.

Interactive Connectivity Establishment, RFC 8445, решает это, собирая параллельно все адреса, по которым эндпоинт мог бы быть достижим. Типов адресов три. Host-кандидат – это локальный IP, как сообщает ОС. Server-reflexive-кандидат – это публичный IP, обнаруженный отправкой STUN binding request публичному STUN-серверу и считыванием source-адреса с точки зрения сервера из ответа: так становится виден NAT-mapped публичный адрес (IETF, RFC 8489, Session Traversal Utilities for NAT (STUN), февраль 2020). Relayed-кандидат – это публичный IP TURN-сервера, которому эндпоинт аутентифицировался и попросил пересылать пакеты от его имени: запасной вариант, когда прямого пути нет (IETF, RFC 8656, Traversal Using Relays around NAT (TURN), февраль 2020).

Когда оба пира собрали кандидатов и обменялись ими через сигналинг, ICE формирует все возможные пары (кандидат-A, кандидат-B) и шлёт STUN connectivity-check пакеты по каждой паре, пока хотя бы одна не успешна в обе стороны. Побеждает первая успешная пара. В продакшене победа обычно – за парой server-reflexive-to-server-reflexive (оба пира за разрешающими NAT, пропускающими входящие пакеты после исходящего) или за парой relayed-to-relayed (оба пира за строгими NAT, где единственный рабочий путь – через TURN-сервер посередине). Процент звонков, которым нужен TURN, варьируется от смеси сетей: публично-интернетные конференц-платформы видят 8–15% relayed сессий; корпоративные платформы со строгими файрволами – 25–40% (Cloudflare, State of WebRTC report, 2025).

Нажмите, чтобы увеличить

Экономику TURN продуктовые команды недооценивают. TURN-сервер – это чистая полосовая ретрансляция: каждый байт медиа проходит через него дважды (входящий от отправителя, исходящий получателю), и счёт идёт за полосу. Один 720p-видеозвонок на 1.5 Мбит/с в каждую сторону ретранслирует 3 Мбит/с на пира, 6 Мбит/с на звонок; умножьте на процент сессий с TURN и на пиковые одновременные звонки – получите доминирующую статью затрат публичного конференц-продукта. Калькулятор B5 внизу страницы помогает смоделировать вашу цифру.

DTLS-SRTP: почему в WebRTC нет режима без шифрования

WebRTC требует шифрование на каждом соединении, всегда. И спецификация W3C, и архитектура безопасности IETF (RFC 8827) этого требуют; ни один браузер не предусматривает отказ. Handshake работает так: каждый пир генерирует self-signed DTLS-сертификат, вычисляет его SHA-256-отпечаток и записывает отпечаток в свой SDP. SDP идёт через сигналинг – который должен быть защищён TLS, если приложение заботится об устойчивости к MitM, – и принимающий пир заранее знает, какой отпечаток должен совпасть с сертификатом другой стороны. Когда DTLS-handshake идёт по UDP-пути, найденному ICE, каждая сторона проверяет сертификат другой стороны против отпечатка из SDP; несовпадение завершает соединение (IETF, RFC 8827, WebRTC Security Architecture, январь 2021).

Когда DTLS произвёл master secret, ключи для SRTP выводятся через расширение DTLS-SRTP (RFC 5764). С этого момента каждый RTP-пакет с аудио или видео шифруется AES (обычно AES-128-GCM в современных деплоях) и аутентифицируется. Сетевой наблюдатель, читающий байты на проводе, видит только SRTP-заголовки и поток шифротекста.

Неочевидное следствие: WebRTC – единственный широко распространённый протокол real-time-медиа, шифрованный по умолчанию с момента появления. В легаси SIP/RTP оператор может выбирать; в WebRTC – нет. Это делает его рациональным выбором для телемедицины, голоса в финансовых сервисах и любого продукта, где регулятор задаёт вопрос «видел ли кто-нибудь на сетевом пути голос пациента в открытом виде?», и ответ должен быть «нет».

RTP, RTCP и как WebRTC читает сеть

Когда зашифрованный UDP-канал открыт, аудио и видео сами по себе едут внутри Real-Time Transport Protocol, RFC 3550. RTP – рабочая лошадь интернет-голоса и видео уже тридцать лет; WebRTC добавляет петлю обратной связи получателя, замыкающую систему управления. Получатель непрерывно шлёт RTCP receiver reports – процент потерь, джиттер (разброс интервалов между прибытием пакетов) и round-trip-delay – обратно отправителю. Алгоритм оценки полосы у отправителя читает эти цифры и подстраивает битрейт кодера, simulcast-слой или SVC-слой соответственно.

Эталонный алгоритм Google, который везут Chrome и большинство Chromium-клиентов, – Google Congestion Control (GCC). Он поддерживает Kalman-фильтр-оценку доступной полосы по RTCP-фидбэку и динамически снижает битрейт кодера при падении оценки, поднимая снова при восстановлении сети (Carlucci et al., Congestion Control for Web Real-Time Communication, IEEE/ACM Transactions on Networking, 2017). Более новое расширение transport-cc позволяет получателю репортить per-packet arrival timestamps, давая отправителю более богатый сигнал, чем стандартный RTCP receiver report; transport-cc сегодня дефолт во всех крупных реализациях (W3C WebRTC spec, §5.6, 2023).

Та же петля обратной связи приводит в действие восстановление потерянных пакетов. Получатель может запросить NACK (negative acknowledgment) на конкретный потерянный пакет, и отправитель ретрансмитнет его из небольшого буфера истории, если успеет до того момента, когда джиттер-буфер получателя его проиграл бы. Для слишком поздних потерь получатель может запросить picture-loss indication (PLI) или full-intra-request (FIR), заставив отправителя выдать keyframe для ресинхронизации декодера. Forward error correction поддерживается, но редко используется по умолчанию – RTT типичной конференции достаточно мал, чтобы ретрансмиссия обычно выигрывала по полосе.

Рабочий бюджет задержки: почему WebRTC попадает в 100–300 мс

Задержка в WebRTC измеряется glass-to-glass – wall-clock-время от момента, когда фотон попал на сенсор камеры с одной стороны, до момента, когда соответствующий пиксель дошёл до экрана с другой. Опубликованный пол задержки WebRTC на чистой сети – около 100 мс; верхняя граница приемлемого интерактивного разговора – около 300 мс; выше 500 мс перебивки начинают ломать естественный обмен репликами. Эти цифры пришли из десятилетий телефонных исследований и применимы к WebRTC без изменений.

Куда уходят эти 100–300 мс? Рабочий бюджет для чистой сети выглядит так:

Сравните с HLS, который буферизует 4–10-секундные сегменты до старта и выдаёт 5–30 секунд glass-to-glass в дефолтной конфигурации; с LL-HLS, попадающим в 2–5 секунд; или с Media over QUIC, новичком 2026 года, нацеленным на 500 мс при CDN-масштабе. Разрыв в два порядка между WebRTC и HLS – единственная важнейшая цифра, которую продуктовая команда должна усвоить: если кейсу нужна задержка ниже секунды, WebRTC – правильный транспорт; если нет – HTTP-протокол обычно дешевле в эксплуатации.

Нажмите, чтобы увеличить

Картинка «два браузера» ломается на трёх

WebRTC описывают как peer-to-peer, потому что API даёт один объект RTCPeerConnection, разговаривающий с одной другой точкой. Проблема в том, что «одна другая точка» – это предел. Если вы хотите трёх человек в звонке, каждому пиру придётся держать peer connection к каждому из остальных: три пира – три peer connection в браузере, четыре – шесть, десять – девять. Полоса масштабируется так же: каждый пир выгружает своё видео N раз, по одному на каждого другого пира, что upstream бытового канала не выдерживает после четырёх-пяти участников. Эта топология – каждый пир соединён с каждым другим – называется mesh, и это дефолт, если вы пишете наивное WebRTC-приложение.

Продакшен-конференцинг решает это сервером посередине. Паттернов два:

Selective Forwarding Unit (SFU) терминирует WebRTC-соединение от каждого пира, расшифровывает только настолько, чтобы прочитать RTP-заголовки, и пересылает шифрованную полезную нагрузку каждому другому пиру. SFU не транскодирует; не микширует; маршрутизирует. Полоса на пира со стороны загрузки падает с O(N) до O(1), потому что каждый пир отправляет своё видео в SFU один раз. mediasoup, Janus, LiveKit, Jitsi Videobridge и Pion – это SFU (LiveKit, SFU vs MCU vs Mesh, 2024).

Multipoint Conferencing Unit (MCU) терминирует каждое соединение, декодирует каждый поток, композитит их в одно выходное видео и заново кодирует этот композит для каждого получателя. Загрузка пира – один поток, выгрузка пира – один поток, но счёт за CPU сервера огромен, потому что он делает real-time-кодирование видео для каждого участника.

К 2026 SFU победил в каждой категории, где устройство участников может справиться с несколькими входящими видеопотоками (web, mobile, smart TV): меньшая нагрузка на CPU и меньшая задержка маршрутизации, а не микширования, перевешивают чуть большую сложность на клиенте. MCU выживают только там, где принимающее устройство не может справиться с несколькими потоками (некоторые легаси-телефонные мосты, некоторые ограниченные embedded-клиенты). Детальное сравнение – в статье 8.4 (SFU vs MCU vs Mesh); сравнение пяти крупных open-source SFU – в статье 8.5.

Частая ловушка: считать WebRTC HTTP-протоколом

Самая частая ошибка команд, впервые отгружающих WebRTC, – рассуждать о нём так, будто это HTTP. Они полагают, что CDN поможет с масштабированием (не поможет – CDN кэширует; WebRTC-потоки уникальны на сессию); что балансировщика перед сигналинг-сервером хватит (не хватит – медиа-плоскость WebRTC идёт по совсем другому транспорту и сигналинг-сервер не проходит); что медиа заработает поверх корпоративного VPN (обычно нет, потому что NAT VPN не подозревает о WebRTC). Честная формулировка для product-менеджера: WebRTC – это peer-to-peer-протокол для медиа, использующий HTTP только для сигналинга и только так, как выберет приложение. Масштабирование, стоимость и режимы отказа полностью отличаются от всего, что есть в HTTP-мире. Архитектуру планируйте соответственно – остальная часть Block 8 проведёт вас через как.

Состояние WebRTC в 2026 году

WebRTC «стабилен» как стандарт с января 2021 года, но экосистема вокруг продолжает развиваться. Три изменения важны любой команде, делающей продукт сегодня.

Первое – улучшилась история с кодеками. AV1 со scalable video coding (AV1 SVC) пришёл в Chrome 90, Firefox получил аппаратный декод в 2024-м, Safari 18 добавил базовую поддержку в конце 2024-го. Где сеть позволяет, AV1 SVC даёт ту же воспринимаемую качество, что VP9, при примерно на 30% более низком битрейте, а слойность SVC позволяет SFU отбрасывать слои медленным получателям без перекодирования (Bitmovin, AV1 in WebRTC, 2024). H.264 остаётся универсальным fallback'ом; Opus – универсальным аудио-кодеком.

Второе – WebTransport достиг baseline-статуса во всех крупных браузерах в марте 2026, когда Safari 26.4 включил его (webrtc.ventures, WebTransport Is Now Baseline, апрель 2026). WebTransport – не замена WebRTC для двусторонней беседы, но дополняет его для односторонних данных и лежит в основе нескольких экспериментов WHIP-over-WebTransport. О нём будут больше говорить в 2026–2027.

Третье – история интеграции ИИ-агентов созрела. Фреймворк LiveKit Agents запустился в 2024, к 2025 достиг продакшен-масштаба, давая разработчикам встроить OpenAI Realtime API модель, Google Gemini Live модель или любую эквивалентную голосовую модель в WebRTC-комнату как ещё одного участника. К Q1 2026 LiveKit Agents набрал 700 ежемесячных поисков как head term в кластере; категории не существовало в 2024-м. Это самый крупный новый кейс и тема статьи 8.10. Если в дорожной карте есть voice-first ИИ-агент любого вида, WebRTC сейчас – предполагаемый транспорт.

Чего в WebRTC нет

Стоит назвать, что WebRTC сознательно не делает, потому что именно эти пробелы определяют архитектурные решения команд:

Нет сигналинга. Его пишете вы. Нет SFU. Покупаете, запускаете open-source или пишете. Нет записи. Делаете мост в HLS- или MP4-рекордер, обычно через бота-участника в комнате. Нет TURN-сервера. Запускаете coturn или покупаете у Twilio, Cloudflare или CDN. Нет модели комнаты и presence. Это делает сигналинг-сервер. Нет rate-limiting и анти-абьюз-контролей. Снова – сигналинг-сервер. Нет способа транслировать один поток миллиону зрителей. WebRTC масштабируется до тысяч в каскаде SFU; для миллионов мостите в HLS, DASH или Media over QUIC.

Список выглядит пугающе; на деле open-source-экосистема закрывает каждую дыру, а паттерны хорошо задокументированы. Смысл их назвать – задать ожидания: как только scope растёт за пределы «два человека разговаривают», работа – это заполнение пробелов, а не сам WebRTC.

Ключевые тезисы

• WebRTC – открытый стандарт W3C и IETF для browser-native real-time-аудио, видео и данных, шифрованный по умолчанию и адаптивный по полосе.
• API браузера показывает один объект – RTCPeerConnection, – скрывающий девять RFC под собой.
• Сигналинг сознательно не специфицирован; каждая команда строит свой сервер, обычно на WebSocket.
• ICE плюс STUN плюс TURN ищут путь по сети; 8–40% сессий в продакшене нуждаются в TURN-релее – это доминирующая статья затрат.
• Бюджет задержки – 100–300 мс glass-to-glass, на два порядка ниже HLS, и это делает WebRTC правильным транспортом для интерактивного разговора.
• Картинка peer-to-peer ломается на трёх пирах; продакшен-конференцинг использует SFU (mediasoup, LiveKit, Janus, Jitsi, Pion) для маршрутизации потоков.

Что почитать дальше

• SDP offer/answer подробно – документ согласования и как его читать.
• ICE, STUN и TURN подробно – каждый тип кандидата, каждый паттерн connectivity-check, с примерами.
• SFU, MCU, Mesh: три топологии WebRTC – когда что выбрать и почему.

Дальше

• Поговорите с инженером по стримингу. Фора Софт делает WebRTC-продукты с 2011 года. Назначьте 30-минутный звонок-скоупинг.
• Посмотрите наши кейсы. WebRTC, конференц-связь, телемедицина, e-learning, AR-VR.
• Скачайте чек-лист стека WebRTC. Одна страница со ссылками на API, RFC, SFU, кодеки и статьи затрат. Скачать чек-лист (PDF).