WebRTC

Обмен данными напрямую между браузерами не является новшеством, предложенным исключительно W3C и IETF; предыдущие разработки и реализации были нестандартизированы (из-за использования проприетарных плагинов вроде Adobe Flash или ActiveX), а также плохо документированы^[10]. Это приводило к проблемам совместимости и обновления для сайтов, использующих такие системы. Несмотря на поддержку видеоконференций (например, на основе протокола Real Time Media Flow Protocol от Adobe^[11]), такие решения зависели от проприетарных плагинов и были лишены стандартизации^[12].

С развитием богатых веб-приложений пользователям стали доступны анимация, drag-and-drop и двунаправленные потоки аудио/видео^[13], однако их коммуникация ограничивалась взаимодействием браузера с одним или несколькими веб-серверами.

WebRTC предлагает прямые коммуникации (без участия веб-сервера) между несколькими браузерами^[14], при поддержке крупных компаний, включая Google^[15], Mozilla и Opera^[16] в рамках стандартизации W3C, первые черновики которой опубликованы в мае 2011 года. Для развития WebRTC была создана рассылка W3C в апреле 2011 года^[17][18], а также рабочая группа в IETF в мае 2011 года^[19].

В качестве альтернативы Microsoft выдвигала конкурентное предложение CU-RTC-WEB 8 августа 2012 года^[20].

Стандарт WebRTC в 2012 году ещё не был завершён, обсуждались различные варианты, велась экспериментальная работа. API базируется на наработках WHATWG^[21] и лабораторий Ericsson^[22].

Архитектура WebRTC строится по треугольной схеме: сервер и два клиента (браузера)^[12]. Оба браузера загружают с сервера JavaScript-приложение, используемое как точка координации для дальнейшей прямой коммуникации «браузер-браузер» через WebRTC API. После установления прямого соединения потоки данных идут без участия сервера. При организации потоков могут участвовать промежуточные серверы для обхода NAT, прокси или брандмауэров^[23].

Для соединения по WebRTC оба браузера должны одновременно быть подключены к сервису, загрузить страницу и соответствующий JavaScript-код (через HTTPS или WebSocket). Для передачи медиа производится обработка разрешения пользователя на доступ к камере или микрофону.

После создания объекта PeerConnection браузер A отправляет серверу параметры медиа и цифровую подпись; сервер передаёт их B. B оповещается о запросе соединения, подтверждает или отклоняет, после чего соединение устанавливается; можно добавлять потоки медиа и данных. Для обмена видеоконтентом, браузеру требуется получить метаданные и список пиров, далее загружаются фрагменты, собираются и проигрываются в HTML5-плеере^[24].

API WebRTC использует существующие стандарты: STUN, ICE, TURN, DTLS, SRTP^[25][26]. Многие из этих технологий происходят из проекта libjingle.

API PeerConnection^[27] — это логическая связь с удалённым браузером, обычно реализованная через UDP. Для установления канала связи требуется предварительный обмен данными через сервер (XMLHttpRequest или WebSocket)^[28]. Демонстрации работы проводили Mozilla и Google в феврале 2013 года^[29][30].

Для согласования параметров (аудио/видео) используется SDP (Session Description Protocol), регламентированный RFC 3264. Сейчас он постепенно вытесняется протоколом JSEP^[31] из-за неудобства формата передачи SDP^[32]. Передача SDP осуществляется через сервер по выбранному механизму^[33].

Для обхода NAT и брандмауэров применяются UDP, STUN и ICE^[34]. После успешного соединения между двумя браузерами могут быть инициированы медиа- или дата-потоки.

Data channels предоставляют двунаправленный peer-to-peer канал для передачи произвольных данных^[28], в частности, изображений или текста. Первая демонстрация Mozilla прошла в ноябре 2012 года^[35].

Каналы данных создаются между пирами через PeerConnection. Данные передаются поверх SCTP, который инкапсулируется в DTLS. Это позволяет мультиплексировать медиа- и дата-потоки через один порт. SCTP поддерживает до 65536 потоков в каждом направлении и позволяет задавать приоритеты. Для аутентификации используется DTLS.

Передача может быть как упорядоченной, так и неупорядоченной; порядок доставки сохраняется внутри одного и того же канала данных. Новый data channel создаётся вызовом метода CreateDataChannel().

DTLS — не только инкапсуляция для SCTP, но и механизм установления ключей и параметров для SRTP, используемого для передачи медиа^[36].

MediaStream — объект, представляющий медиа-поток (аудио или видео). Через него осуществляется вывод, запись и отправка потока другому пирy. Для доступа к локальному устройству используется функция getUserMedia(), краеугольная для работы с камерой, динамиками и микрофоном.

Для передачи аудио/видеопотока применяется RTP, а для безопасной передачи — его расширение SRTP, с ключевой информацией через DTLS. Один и тот же SRTP-канал может использоваться для нескольких медиа-потоков (идентификацию обеспечивает SSRC).

WebRTC предусматривает мультиплексирование нескольких типов трафика (данные и медиа) через одну транспортную сессию. Протоколы STUN, SRTP и DTLS работают параллельно на одном уровне; различие определяется по первому октету UDP-пакета^[37]. Число 0 или 1 — STUN, 20-63 — DTLS, 128—191 — SRTP. Это упрощает использование NAT и облегчает прохождение брандмауэров.

С марта 2012 года черновики IETF требуют обязательной поддержки следующих аудиокодеков^[38]:

• PCMA/PCMU (RFC 3551);
• Telephone Event (DTMF, RFC 4733);
• Opus (RFC 6716) — обязателен для клиентов.

Видеокодеки должны поддерживать минимум 10-30 кадров в секунду, минимальное разрешение 320×240, дополнительные требования для VP8^[39].

С WebRTC связаны следующие проблемы безопасности:

• JavaScript-код может быть загружен и выполнен без явного разрешения пользователя;
• Доступ к медиа-устройствам должен подтверждаться пользователем;
• Необходимость защищённости и аутентификации против атак «человек посередине»;
• Личные данные пользователя не должны быть раскрыты без согласия.

Для медиаобмена применяется SRTP.

WebRTC позволяет обнаружить внутренний IP-адрес пользователя даже при работе через VPN^[40].

Так как UDP не гарантирует доставку пакетов, возможны потери при peer-to-peer соединениях. WebRTC применяет две техники:

• NACK (Negative-Acknowledgment) — уведомление об ошибках доставки;
• FEC (Forward Error Correction) — порядковый контроль целостности;
• RPS (Reference Picture Selection).

Гибридная схема NACK+FEC плюс динамические буферы позволяют повысить качество передачи^[41][42].

WebRTC не всегда корректно работает за корпоративными брандмауэрами и SBC (Session Border Controller), поскольку каналы peer-to-peer чувствительны к задержкам, а управляющий трафик не стандартизирован^[43]. Кроме того, шифрование DTLS препятствует анализу трафика SBC. Как вариант, возможно преобразование трафика в SIP, но это усложняет архитектуру^[43].

Для обхода NAT применяются две основные техники:

• «Пробивание дыр» («hole punching») с помощью STUN-сервера;
• Использование TURN-реле в демилитаризованной зоне для ретрансляции трафика между пирами^[44].

• Opera: первая интеграция — январь 2012 года, поддержка реализована в стабильной версии^[45];
• Google Chrome: технология появилась в дев-ветке в январе 2012, стабильная — с июня 2012 года^[46][47] (PeerConnection/MediaStream активируются через chrome://flags);
• Mozilla Firefox: первая демонстрация — апрель 2012 года^[48]. 8 января 2013 года в Firefox 18 появилась экспериментальная поддержка, а с версии 22 (25 июня 2013) WebRTC включён по умолчанию^[49];
• Internet Explorer: Microsoft разрабатывает аналогичное API, в Edge поддержка реализована частично^[50];
• Ericsson анонсировала в октябре 2012 года мобильный браузер с поддержкой WebRTC для iOS и Android^[51];
• Safari: по состоянию на апрель 2016 поддержка отсутствовала^[50], но Apple анонсировала ведение работ^[52]. С сентября 2017 года WebRTC поддерживается в Safari и Chrome для iOS 11^[53].
• OpenWebRTC — свободный программный стек для реализации стандарта WebRTC.

WebRTC был реализован в ряде проектов уже в 2011 году, включая разработки Ericsson и Doubango Telecom (SIPML5) — первый SIP клиент на HTML5 с использованием WebRTC^[54]. В сентябре 2012 команда Versatica выпустила JsSIP — JavaScript-фреймворк для SIP поверх WebSocket.

Сервисы, использующие WebRTC: tawk.com, appear.in, Talky.io, vroom.im^[55], Bistri.com и др. В ноябре 2012 года ToxBox запустила OpenTok для разработки видеочатов для сайтов и мобильных приложений iOS/Android^[56]. Для обмена файлами через DataChannel существует rtccopy.

В 2013 году WebRTC демонстрировали Mozilla, Ericsson и AT&T на Mobile World Congress^[57]. Проект Google Talk также планировал интеграцию WebRTC.

В августе 2012 года Microsoft предложила альтернативу CU-RTC-WEB (Customizable, Ubiquitous Real Time Communication over the Web) для W3C^[58], разработанную совместно со Skype (приобретённым в 2011 году).

Google продвигает кодек VP8^[59], не обременённый роялти, тогда как Microsoft делает ставку на H.264^[60], патентно-зависимый.

Состояние поддержки кодеков на 2016 год: Opera и Google Chrome — только VP8, Firefox и Bowser — H.264 и VP8, Edge — частично H.264^[50].