Коммуникации реального времени: проблемы, достижения, стандарты

Работа над обеспечением возможности коммуникаций реального времени (Real-Time Communications, RTC) в WWW осуществляется в двух основных организациях по стандартизации Сети: IETF и консорциуме World Wide Web Concortium.

Задача стандартизации в данной области состоит в создании универсального интерфейса программирования, который позволит веб-приложению, работающему на любом устройстве, с использованием защищенного доступа к веб-камерам и микрофонам в режиме реального времени пересылать любые данные между браузерами по одноранговому принципу. Такой API должен позволить разработчикам реализовывать функции поиска контактов, установки сеанса связи с ними и будет полагаться на существующие спецификации, определенные IETF как наиболее пригодные для решения сетевых задач: управляющие протоколы, протоколы установления соединения и управления им, транспортные протоколы без установления физического соединения, кодеки и т. д. Между процессами стандартизации, проходящими в IETF и в W3C, нет четкой границы — этим двум организациям неизбежно приходится взаимодействовать на пересечении областей, одна из которых связана с функциями коммуникационного приложения, исполняемого на отдельном узле, другая — с обменом информацией между сторонами.

Переход на межбраузерную связь реального времени представляется серьезным прорывом в индустрии, и сегодня эта тема активно обсуждается в ИТ-сообществе.

Идея межбраузерной связи

Межбраузерный обмен в реальном времени предлагается вместо традиционных коммуникационных сервисов. Например, в одном исследовании оценивалась сложность традиционных телекоммуникационных систем и веб-архитектур, и специалисты пришли к выводу, что две эти области следует сблизить, чтобы коммуникации в реальном времени стали доступны как можно большему числу пользователей. Эти исследования легли в основу черновика одной спецификации, описывающей REST-интерфейс для протокола SIP (Session Initiation Protocol). Исследователи и разработчики инициировали немало других аналогичных проектов, однако часто без опоры на стандарты (например, за счет использования проприетарных плагинов вроде Adobe Flash и Microsoft ActiveX) и без составления документации. Примечательное исключение — недавняя работа исследователей из Ericsson Labs, в которой была сделана попытка реализации встроенных средств поддержки протокола Real-Time Transport Protocol и медиаустройств в браузерах за счет специального API JavaScript, измененного варианта движка WebKit и фреймворка Gstreamer.

Все эти инициативы подтолкнули разработчиков стандартов Интернета заняться решением данной задачи, что в конечном счете привело к созданию двух взаимосвязанных рабочих групп: RTCWeb в IETF и WebRTC (Web Real-Time Communication) в W3C. Первая занимается протоколами и взаимодействиями, относящимися к ведению IETF, в том числе интероперабельностью со старыми системами (например, с существующими телекоммуникационными), а группа WebRTC разрабатывает API, позволяющий браузерам и скриптовым языкам взаимодействовать с медиаустройствами (микрофонами, веб-камерами и динамиками), средствами обработки (кодеками) и функциями передачи. Данные инициативы, скорее всего, приведут к расширению спецификации HTML5, в которой уже есть стандартный способ потоковой передачи мультимедиаконтента с серверов на браузеры.

Обеим рабочим группам придется учесть проблемы безопасности, которые могут возникнуть в связи с появлением новых функций. Предполагается, что на этапе разработки уже появится несколько реализаций-прототипов.

Открытая веб-платформа

Под HTML5 обычно понимается все, что обобщает достижения в области так называемой открытой платформы WWW. Однако сам по себе HTML несет лишь часть технологий, используемых для разработки веб-приложений, которые, как традиционно считается, составляют открытую платформу для Web. В число этих технологий также входят Cascading Style Sheets (CSS), Document Object Model, JavaScript и ряд скриптовых интерфейсов программирования.

HTML служит для структурированного представления пользовательского интерфейса и данных приложения. Разработчики могут стилизовать приложение с помощью CSS и управлять им посредством кода JavaScript. Все три технологии передаются по инфраструктуре Web (через прокси, веб-серверы и браузеры) по протоколам HTTP или Web-Socket.

API для скриптов позволяют программистам использовать возможности браузера и управлять им с помощью JavaScript. Обычно, как только в браузерах появляются новые особенности, в W3C разрабатывают новые API, предоставляющие доступ к этим функциям. В результате браузеры приближаются к средам исполнения нативных приложений.

Архитектура

Архитектурная модель RTC (Рис. 1) позволяет пересылать медиаданные напрямую между браузерами без посредничества серверов. Маршрут сигнальных данных, однако, проходит через серверы, которые могут менять, ретранслировать сигналы или управлять ими по мере необходимости. Идея в том, чтобы клиентские веб-приложения (обычно написанные на смеси HTML и JavaScript) могли взаимодействовать с браузерами через API WebRTC как в проактивном режиме (например, для опроса возможностей браузера), так и в реактивном (для получения сгенерированных браузером уведомлений). Такой API предоставит широкий круг функций, включая: управление соединением (по одноранговой схеме); средства кодирования/декодирования; механизмы управления сеансом; средства управления медиаданными; функции межсетевого экрана и механизм обхода систем трансляции сетевых адресов (Network Address Translation, NAT). Данный API реализуется на JavaScript, который доказал свою эффективность как мощный скриптовый язык для клиентской части веб-приложений.

Рис. 1. Архитектура RTCWeb. Типичная для VoIP трапециевидная схема коммуникаций: маршрут сигнальных данных проходит через сервер, а медиаданные передаются напрямую между самими браузерами

Разработка такого API представляет собой интересную задачу, но составляет лишь часть общей картины, состоящей в том, чтобы наладить прямую связь между двумя или более браузерами без посредников, что подразумевает прохождение непрерывных потоков данных реального времени через сеть. Таким образом, речь идет фактически о революции в веб-коммуникациях: впервые планируется обеспечить возможность однорангового обмена данными между веб-приложениями, работающими в браузерах.

Допустим, происходит видеоразговор по браузеру в прямом эфире. В этом случае потоки медиаданных между браузерами проходят по маршруту, согласованному и организованному в рамках сложной череды взаимодействий с участием следующих сторон:

• вызывающий браузер и вызывающее приложение на JavaScript (взаимодействующие через API);
• вызывающее JavaScript-приложение и провайдер приложения (как правило, веб-сервер);
• провайдер приложения и вызываемое JavaScript-приложение;
• вызываемое JavaScript-приложение и вызываемый браузер (общающиеся через тот же API).

Рассмотрим в деталях особенности RTCWeb, относящиеся к перечисленным взаимодействиям.

Сигнализация

Общая задача разработки WebRTC состоит в том, чтобы целиком стандартизовать управление медиаданными и при этом перенести максимальный объем функций управления сигнализацией на уровень приложения. Причина в том, что разные приложения могут предпочесть разные протоколы сигнализации — например, SIP, XMPP или что-то собственное. При таком подходе браузеры будут обязаны обменяться следующей информацией: описание мультимедиасеанса, указывающее транспортный протокол и сведения для обхода NAT (по протоколу Interactive Connection Establishment, ICE), тип и формат медиаданных, а также все прочие параметры, необходимые для формирования маршрута передачи.

Вначале была предложена идея обмениваться описаниями сеанса с использованием протокола Session Description Protocol, но из-за ряда неустранимых проблем от этого отказались. В итоге в IETF остановили выбор на JavaScript Session Establishment Protocol (JSEP), предоставляющем интерфейс, с помощью которого приложения могут работать с локальным и удаленным описаниями сеанса (согласование которого происходит с помощью любого механизма сигнализации), а также стандартный метод взаимодействия с конечным автоматом ICE. С применением JSEP ответственность за реализацию этого конечного автомата целиком возлагается на приложение. Помимо простой пересылки сообщений, транслируемых от браузера удаленной стороне, приложение должно вызывать нужные функции API в нужное время, а также конвертировать описания сеанса и ICE-информацию в сообщения используемого сигнального протокола.

API

Использовать новые возможности в JavaScript-приложениях можно с помощью API W3C WebRTC 1.0, который требует, чтобы ядро браузера предоставляло функциональность, необходимую для организации каналов передачи аудио-, видео- и других данных. Но разработчики стандартов еще не пришли к решению по поводу того, какие аудиокодеки (G.711, Opus, Vorbis и т. д.) и видеокодеки (H.264, VP8 и т. д.) нужно реализовать в браузерах. Предполагается, что медиапотоки и любые передачи данных всегда будут шифроваться. API состоит из трех основных элементов: PeerConnection, MediaStreams и DataChannel.

PeerConnection

PeerConnection позволяет устанавливать прямое соединение между двумя браузерами и обращаться к удаленной равноправной стороне, обычно представляющей собой экземпляр того же JavaScript-приложения. Связь координируется по сигнальному каналу, организованному средствами скрипта на странице приложения (например, с использованием протоколов XMLHttpRequest или WebSocket) и проходящему через веб-сервер. Установив соединение, вызывающий браузер может передавать объекты MediaStream напрямую удаленному браузеру.

Рис.2. Стек протокола RTCWeb, позволяющего защищенно передавать мультиплексированные потоки по Сети в реальном времени

Как показано на рис. 2, в механизме однорангового соединения используется протокол ICE наряду с сервером Session Traversal Utilities for NAT (STUN) и протоколом Traversal Relays around NAT (TURN), чтобы передаваемые по UDP медиапотоки могли обходить средства NAT и межсетевые экраны. ICE позволяет браузерам выяснить достаточно информации о топологии сети, в которой они используются, чтобы организовать оптимальный коммуникационный маршрут. ICE также обеспечивает нужный уровень безопасности, не позволяя ненадежным веб-страницам и приложениям отправлять данные на хосты, не ожидающие их получения.

На удаленном хосте каждое сигнальное сообщение по прибытии передается принимающему элементу PeerConnection. Сигнальные сообщения, отправляемые средствами API, для большинства приложений выглядят как бессмысленный набор данных, но коммуникационное веб-приложение обязательно защищено, поэтому эффективнее передавать их другой стороне через веб-сервер.

MediaStream

MediaStream — абстрактная репрезентация реального потока видео- или аудиоданных, с помощью которой над ним можно выполнять различные действия: отображение содержания, запись или отправка удаленному адресату. MediaStream может представлять собой поток, который поступает от удаленного узла или отправляется на него. Например, элемент LocalMediaStream — это медиапоток, отправляемый с локального регистрирующего устройства (веб-камеры или микрофона).

Для создания и использования LocalMediaStream веб-приложение должно запросить у пользователя доступ с помощью функции getUserMedia(). Приложение указывает тип медиаданных (аудио или видео), к которым ему нужен доступ. Селектор устройств в интерфейсе браузера предоставляет доступ или отказывает в нем. По окончании работы приложение само может отозвать свой собственный доступ путем вызова функции stop() для LocalMediaStream.

Сигнализация на уровне медиаданных выполняется вне канала связи между сторонами. На рис. 2 показан стек протоколов, необходимых для передачи медиаданных. По протоколу Secure Realtime Transport Protocol передаются сами медиаданные, а по RTP Control Protocol — информация, используемая для сбора статистики передачи потоков. Datagram Transport Layer Security используется для обмена ключами SRTP (Secure Realtime Transport Protocol), а также для управления ассоциациями. В IETF обсуждают возможность использования SDP Security Descriptions for Media Streams в качестве альтернативного протокола обмена ключами и управления ассоциациями.

В мультимедиасеансе каждый вид медиаданных обычно передается в отдельном RTP-сеансе со своими пакетами RTCP (RTP Control Protocol). Однако, чтобы преодолеть проблему с созданием новой «трубы» для каждого потока, в IETF работают над возможностью уменьшения числа портов транспортного уровня, используемых RTP-приложениями реального времени, за счет объединения (мультиплексирования) мультимедиатрафика в единый RTP-сеанс.

DataChannel

DataChannel предоставляет транспортный сервис общего назначения, позволяющий веб-браузерам двунаправленно обмениваться данными по одноранговой схеме. Для управления данными, не относящимися к мультимедиа, в IETF решили использовать Stream Control Transmission Protocol (SCTP), инкапсулированный в DTLS (Datagram Transport Layer Security). Инкапсуляция «SCTP поверх DTLS поверх ICE поверх UDP» позволяет обходить NAT и обеспечивает конфиденциальность и защиту целостности передачи. Более того, такое решение позволяет транспорту данных без проблем взаимодействовать с параллельными транспортами медиаданных и делить с ними один номер порта транспортного уровня. В IETF выбрали SCTP, поскольку он сам по себе позволяет передавать много потоков с надежным, ненадежным и частично надежным режимами доставки. Благодаря этому, приложения могут открывать несколько независимых потоков (до 65 536 в обоих направлениях) внутри SCTP-ассоциации, пересылаемых на равноправную конечную точку SCTP. Каждый поток сам по себе представляет собой однонаправленный логический канал последовательной доставки.

Приложение может отправлять последовательность сообщений упорядоченно или нет. Порядок доставки сообщений сохраняется только для всех упорядоченных сообщений, отправленных в одном потоке, однако API DataChannel является двунаправленным, а это значит, что в каждом канале есть и входящий, и исходящий SCTP-поток.

Приложение организует канал передачи данных (то есть создает SCTP-ассоциацию), когда на объекте PeerConnection впервые вызывается функция CreateDataChannel1(). Каждый последующий вызов этой функции просто создает новый канал данных в существующей SCTP-ассоциации.

Простой пример

Алиса и Боб пользуются одним и тем же сервисом связи. Для соединения они должны быть одновременно подключены к веб-серверу, на котором он работает. Когда Боб (или Алиса) открывает в браузере веб-сайт сервиса, загружается HTML-страница с JavaScript-кодом, который будет поддерживать защищенное соединение по HTTP или WebSocket (рис. 3). Когда Алиса нажимает на веб-странице клавишу вызова Боба, JavaScript создает экземпляр объекта PeerConnection. После этого на вызывающей стороне код JavaScript должен создать поток медиаданных, это делается с помощью элемента MediaStream. Алиса, как и Боб, должна дать сервису разрешение на доступ к ее камере и микрофону.

Согласно нынешней версии API W3C, после того как приложение создало потоки, браузер Алисы с помощью кода JavaScript создает сигнальное сообщение. В IETF еще не определились с точным форматом этого сообщения — в нем должна содержаться информация о канале медиаданных и ICE-кандидатах, а также сигнатура, привязывающая сеанс связи к открытому ключу Алисы. Ее браузер затем отправляет созданное сообщение сигнальному серверу (например, с помощью XMLHttoRequest или WebSocket). Сигнальный сервер обрабатывает полученное сообщение, определяет, что это вызов к Бобу, и передает сигнал его браузеру. JavaScript в браузере Боба обрабатывает входящее сообщение и уведомляет хозяина. Если он решит ответить на вызов, код JavaScript в его браузере создает PeerConnection для приема данных от Алисы. Затем выполняется процесс, подобный уже выполненному в браузере Алисы: браузер Боба удостоверяется в подлинности сервиса связи и создает медиапотоки; после этого формируется сигнальное сообщение, содержащее информацию о медиаданных и ICE-кандидаты, а Алисе через сигнальный сервис передается защитная сигнатура.

Рис. 3. Процедура настройки вызова с точки зрения Алисы. С помощью API WebRTC можно создать прямое соединение для передачи медиаданных между браузерами Алисы и Боба

Управление заторами

Обсуждение механизма предотвращения заторов, специально предназначенного для интерактивной передачи медиа- и других данных, пока находится на ранней стадии стандартизации — в IETF даже еще не начали над ним работу. Идея в том, чтобы тесно объединить контроль заторов потоков, в идеале — добиться использования всего одного экземпляра такого механизма для всех видов передач WebRTC (то есть аудио, видео и данных). В то же время, должна быть возможна приоритизация разных элементов транспортного «комплекта» WebRTC.

Безопасность

RTCWeb и архитектура прямой связи, без сомнения, создадут новые сложности в мире телекоммуникаций, так как они позволяют веб-браузерам общаться напрямую практически без вмешательства сервера. Придется, в частности, рассмотреть целый ряд проблем, связанных с доверием и безопасностью. Если разрешить прямую межбраузерную связь, то появляется совершенно новый набор потенциальных угроз безопасности. Нынешняя базовая политика безопасности Web основана на принципе изоляции (или «песочницы»), который дает пользователям возможность защищать свои компьютеры от вредоносных скриптов и подделки межсайтовых запросов. Согласно данной модели, политики безопасности в основном применяются к коду JavaScript, работающему в браузере, который фактически является доверенной платформой исполнения посещаемых сайтов. Когда эта платформа выходит за рамки одного браузера, открываются новые потенциальные уязвимости.

Во-первых, необходимо реализовать механизмы безопасности, аналогичные имеющимся в других сетевых протоколах, обеспечивающих прямую связь между двумя любыми конечными точками (таких как SIP), — если не планируется предусматривать присутствие ретрансляторов, действующих в качестве прозрачных для сторон посредников.

Во-вторых, если позволить браузерам напрямую связываться друг с другом, то должны быть механизмы, предоставляющие пользователям возможность подтвердить свое согласие, прежде чем начать сам сеанс связи. Проверка согласия не должна полагаться на какой-либо доверенный сервер, поэтому ее придется выполнять самому браузеру, собирающемуся начать связь.

Последнее, но не менее важное — прямая связь через WWW, очевидно, потребует от браузера тесного взаимодействия с устройством, на котором он работает. Например, прежде чем сделать мультимедиавызов, необходимо получить доступ к локальным аудио- и видеоустройствам. Необходимо предусмотреть политики такого доступа, которые тоже потребуют получения согласия пользователя в какой-то форме, в связи с чем возможен еще ряд новых проблем.

***

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

В ближайшем будущем рабочие группы по стандартизации связи реального времени в Web займутся контролем заторов, выбором аудио- и видеокодеков и оптимизацией использования каналов передачи данных.

Салваторе Лорето (salvatore.loreto@ieee.org) — старший научный сотрудник финского исследовательского подразделения компании Ericsson. Симон Пьетро Романо — преподаватель факультета компьютерного проектирования Неаполитанского университета, сооснователь компании Meetecho.