WebRTC: веб-коммуникации в реальном времени

Значительные изобретения обычно являются закономерным результатом предшествующего эволюционного процесса, и веб-коммуникации в реальном времени (Web Real-Time Communications, WebRTC) не исключение. Появление этого способа обмена информацией естественным образом было подготовлено всей историей WWW  —  к 2010 году накопилось достаточно компонентов,  для того  чтобы собрать из них качественно новый способ передачи звука и  изображения  в режиме реального времени.

До изобретения письменности коммуникации между людьми, если не прибегали к помощи гонцов, осуществлялись устно в естественном режиме реального времени, а с изобретением способов переноса слов на какой-либо носитель в коммуникациях возникло то, что мы сегодня называем латентностью, вызванной необходимостью физически перемещать этот носитель. Изобретенный в середине XIX века телефон снова предоставил людям возможность общения в реальном времени, а теперь в эпоху Интернета может быть сделан следующий шаг в развитии телефонии, но поскольку передается не только звук, то говорят о коммуникациях в реальном времени  —  этот шаг и получил название WebRTC.

Тема коммуникаций в реальном времени привлекла к себе заметное внимание, но, вообще говоря, термин RTC не нов — уже давно так называют любой способ взаимодействия, при котором можно пренебречь задержками. К RTC относят обмен данными в дуплексном (двунаправленно) и полудуплексном (абоненты используют носитель поочередно) режимах, а также передачу данных по одноранговым, или пиринговым, сетям (Peer-to-Peer, P2P). Безадресная широковещательная передача (Broadcast) и ее подмножество (Multicast), адресуемое ограниченной группе абонентов, представлению об RTC не соответствуют — в них нет обмена в обоих направлениях. С появлением Интернета к традиционным средствам из категории RTC добавились технологии мгновенного обмена сообщениями (Instant Messaging, IM), обмен сообщениями на прикладном уровне в сетях IRC (Internet Relay Chat), различного рода технологии телеконференций, в то же время электронная почта и блоги не относят к RTC по причине заметного времени задержки.

В создании «новой телефонии» главную роль будут играть не сервисы, как было до сих пор, а приложения, которые, например, сами могут находить абонентов по их именам, освободив абонентов от привязки к номерам. Очень удачно, что перестройка на новую телефонию ограничивается исключительно приложениями и не затрагивает собственно технологии передачи сигналов — физика и логика коммуникаций могут развиваться автономно. В конечном счете речь идет о принятии новых стандартов, по своему значению сравнимых с семейством протоколов TCP/IP — будущее видится в пиринговых сетях, хорошо знакомых пользователям децентрализованных файлообменных сетей. Упрощенно их суть сводится к тому, что сервер только устанавливает связь между участниками обмена, а затем весь остальной обмен отдается на откуп абонентам.

Чаще всего WebRTC представляют как сумму технологий объединения двух браузеров (Browser to Browser, B-to-B) и их превращения в коммуникационные устройства, но это верно лишь отчасти. На первых этапах действительно так будут объединяться компьютеры или гаджеты, способные поддерживать традиционные браузеры, и первые приложения WebRTC ограничатся парным или групповым общением — например, таким как телеконференции. Но, теоретически, ничто не мешает использовать те же самые принципы WebRTC в телевизорах, автомобилях, фотоаппаратах и другой профессиональной и бытовой технике, где не обязательно присутствие человека, то есть WebRTC будет востребован в Интернете вещей.

Действительно, у WebRTC есть ряд преимуществ: «машинные браузеры» не привязаны к какой-то определенной ОС, не требуется загрузка плагинов, а загружаемые браузеры могут избавить объекты Интернета вещей от одной из потенциальных угроз: если ПО объекта сделать необновляемым, то он легко станет предметом хакерских атак. Если все пойдет так, как это представляется сегодня, то можно предположить, что мы находимся на пороге серьезных изменений в коммуникациях в целом, а что касается браузеров, то изменение их функциональности можно сравнить с тем, что произошло в 1993 году, когда открылась возможность средствами браузеров воспроизводить изображения, — в этот момент Паутина перестала быть чисто текстовым пространством.

Проект WebRTC ассоциируют с Google, хотя на самом деле история вопроса несколько сложнее. Да, эта компания стала главной действующей силой проекта, но включилась в него только после покупки в 2010 году шведской компании Global IP Solutions (GIPS, ранее Global IP Sound). GIPS получила известность своими кодеками в открытых кодах, один из них, iLBC (internet Low Bitrate Codec), предназначен для узкополосных сетей Интернет, а второй, ISAC (Internet Speech Audio Codec), — для широкополосных. GIPS была основана группой шведских экспертов, осознавших, что существующие решения VoIP наследуют традиции сетей с коммутацией каналов, а отнюдь не пакетов и поэтому плохо адаптированы к задержкам и возможной потере пакетов в IP-сетях. В результате эксперты разработали принципиально новую технологию для целей VoIP. Кроме этого, заметную роль в становлении WebRTC сыграли наработки, выполненные в исследовательском подразделении Ericsson. Показательно, что в статье [1] о проблемах стандартизации WebRTC компания Google ни разу не упомянута, однако именно она в мае 2011 года объявила проект WebRTC открытым и подхватила работы по стандартизации. В апреле 2014 года была принята очередная версия стандарта «WebRTC 1.0: Real-time Communication Between Browsers».

Компоненты и архитектура WebRTC

Какой бы ни была реализация системы коммуникаций реального времени, в том числе и WebRTC, она должна включать в себя три основные части: визуальный интерфейс, управление и «медийный движок» (Media Engine, ME). Первые две составляющие выполняют очевидные служебные функции, а ME — ключевую, позволяющую отличать возможные решения. Основная функция ME в любой системе RTC заключается в управлении приемом и передачей аудио- и видеопотоков в реальном времени. В зависимости от выбранного решения ME может быть реализован аппаратно, если используются специализированные устройства, или программно, если используются компьютеры или смартфоны. Отличительная особенность WebRTC состоит в том, что здесь предпринята попытка встроить ME (рис.1) непосредственно в браузер и согласовать его со стандартными API к приложениям и операционным системам с тем, чтобы получить RTC, работающую за счет обмена данными между браузерами. Благодаря такому подходу WebRTC становится универсальным, допуская применение различных кодеков и различных способов соединения устройств между собой. Аудио- и видеопотоки невозможно передавать без выполнения вспомогательных операций, однако производительности современных процессоров достаточно для решения этих проблем внутри браузеров.

Рис. 1. Медийный движок WebRTC

Медийный движок  —  важнейшая часть браузера со встроенными функциями WebRTC. Он имеет три типа интерфейсов (рис. 2): для связи с приложениями, для обмена данными в режиме P2P и для получения сервисов операционной системы.

Рис. 2. Интерфейсы для ME

Широкому распространению WebRTC мешает «война стандартов», каждый раз разгорающаяся при серьезных технологических прорывах, — в данном случае это относится к кодекам. Для аудио в IETF в 2012 году утвердили кодек Opus, придав ему статус «обязательного к внедрению», а для видео принятие аналогичного  стандарта  затрудняется противостоянием заинтересованных сторон, хотя стандартизация видеокодеков позволит общаться без ограничений на тип используемого устройства.

На рис. 3а приведена версия архитектуры коммуникации WebRTC. Два пользователя являются клиентами одного сервера, а связь между ними осуществляется напрямую по протоколу RTP (Transport Protocol for Real-Time Applications). Cервер управляет клиентами, а данные передаются в режиме Peer-to-Peer. Такая архитектура освобождает сервер от каких-либо действий, связанных с поддержкой процесса коммуникации, — ему достаточно обнаружить, что два клиента выражают желание вступить в контакт, и связать их. Такое решение может быть удобно в социальных сетях типа LinkedIn, во взаимодействии сотрудников компании, покупатель-продавец и т. д. Соединение двух клиентов через общий для них сайт называют треугольником, оно не требует услуг со стороны телекоммуникационных компаний. В качестве одного из клиентов может выступать обычный аппарат, подключаемый по телефонной сети общего пользования (PSTN); в случае, если он подключен к PSTN-шлюзу, сервер присваивает браузеру номер, который набирается на телефоне, и после соединения на компьютере раздается  звонок.  Для соединения компьютер-телефон в приложение на сервере передается требуемый номер.

Рис. 3а. Соединение WebRTC треугольником

Рис. 3б. Соединение WebRTC трапецией

Если клиенты подключены к разным серверам, то для связи между ними потребуется участие телекоммуникационного оператора  —  такую архитектуру соединения WebRTC называют трапецией. В этом случае два сервера взаимодействуют между собой по протоколам SIP (Session Initiation Protocol) или Jingle. Протокол SIP широко используется во многих системах VoIP и для поддержки видеоконференций, описывая способ установки и завершения пользовательского сеанса, включающего обмен мультимедийным контентом. Jingle расширяет протокол Jabber, предназначенный для систем обмена сообщениями, способностью передавать аудио- и видеоданные. Открытость процесса соединения веб-серверов позволяет стандартизировать WebRTC — этот подход к коммуникациям не подчиняет себе способы взаимодействия веб-серверов, а лишь позволяет наладить управление клиентами и обеспечить коммуникации между ними. Достаточно, чтобы серверы взаимодействовали между собой по стандарту SIP или какому-то иному, но в результате устройства, подключенные к разным серверам, получают возможность «общаться» напрямую.

Протоколы и стандарты WebRTC

В основе архитектуры WebRTC лежит более десятка стандартов (рис.4), которые можно разделить на две группы; первая (Web Real-Time Communications) распространяется на API между приложениями и браузерами, а вторая (Real-Time Communications in Web-browsers) — на передачу данных в пиринговом режиме.

Рис. 4. Стеки протоколов TCP/IP и WebRTC

Протокол User Datagram Protocol (UDP) является альтернативой Transmission Control Protocol (TCP) на транспортном уровне и не предполагает установления связи, подтверждающей доставку сообщения, и сохранения последовательности доставленных сообщений, за счет чего он легче TCP. Кроме того, он существенно быстрее —  гораздо меньше времени уходит на упаковку и распаковку пакетов. UDP не обладает надежностью TCP, но он предпочтительнее в WebRTC из-за лучшей приспособленности к передаче в реальном времени и меньших задержек. UDP служит основой — в дополнение к нему нужны три протокола: ICE (Interactive Connectivity Establishment), STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relays around NAT). Они устанавливают и поддерживают соединение Peer-to-Peer и обеспечивают трансляцию адресов (Network Address Translation, NAT) поверх UDP. Протокол DTLS (Datagram Transport Layer Security) служит для обеспечения безопасности, что обязательно для WebRTC. Протоколы SCTP (Stream Control Transport Protocol) и SRTP (Secure Real-Time Transport Protocol) служат для управления потоками. Интерфейс RTCPeerConnection отвечает за полный цикл соединения: начальную настройку, контроль состояния и управление, поддержку обмена данными с приложениями.

***

В отличие от систем обмена сообщениями (Skype и другие), средства коммуникации WebRTC имеют большое будущее именно в корпоративной среде, помогая, например, решить технические проблемы интеграции BYOD и придав корпоративным порталам новые способности.

Литература

1. Пьетро Романо, Салваторе Лорето. Коммуникации реального времени: проблемы, достижения, стандарты // Открытые системы.СУБД.  —  2012.  —  № 9.  —  С. 50–53. URL: http://www.osp.ru/os/2012/09/13032514 (дата обращения 18.06.2014).

Леонид Черняк (osmag@osp.ru) — научный редактор, «Открытые системы. СУБД» (Москва).