МЕТОДЫ ОБМЕНА ДАННЫМИ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ В ВЕБ-ПРИЛОЖЕНИЯХ С ПРИМЕНЕНИЕМ КОММУНИКАЦИЙ РЕАЛЬНОГО ВРЕМЕНИ

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

На сегодняшний день существует ряд веб-приложений, к которым выдвигается требование постоянного обеспечения актуальности информации. К таким приложениям можно отнести веб-приложения мониторинга состояния какой-либо системы или процесса, приложения для совместной работы, системы мгновенного обмена сообщениями, многопользовательские браузерные онлайн игры и другие. Иногда подобного рода приложения называют веб-приложениями с применением коммуникаций реального времени, или веб-приложениями реального времени [1, c. 222].

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

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

В связи с описанным ограничением протокола HTTP для организации интенсивного обмена информацией применяются несколько способов, использующих технологии AJAX и Comet, которые позволяют его обойти. Рассмотрим основные из этих методов в хронологическом порядке их появления.

Самым простым из таких способов является опрос (англ. polling). Способ основан на постоянном обращении клиента к серверу за новой информацией (рисунок 1). Клиентский код, выполняемый в браузере пользователя, с заданной временной периодичностью отправляет запрос, опрашивая сервер о наличии событий. Сервер формирует ответ для каждого запроса и отправляет его обратно клиенту. В случае отсутствия новых данных, сервер также сообщает об этом. Запрос к серверу выполняется с использованием подхода AJAX, что подразумевает обмен данными в «фоновом» режиме без полной перезагрузки веб-страницы.

Рисунок 1. Опрос (polling)

К очевидным недостаткам такого подхода следует отнести следующие:

• очень много лишних запросов, посылаемых клиентом, когда на сервере еще нет новых данных;
• серверу приходится хранить информацию о произошедших событиях до тех пор, пока клиент не запросит их или пока они не устареют;
• события всегда приходят с опозданием, ввиду заданного интервала и времени, требуемого на открытие соединения.

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

Более совершенными транспортными технологиями являются технологии под общим термином Comet. Comet – это коллекция техник, которые при постоянном (или длительном) HTTP-соединении позволяют веб-серверу отправлять данные браузеру без дополнительного запроса с его стороны. Общая черта таких моделей состоит в том, что все они основаны на технологиях, непосредственно поддерживаемых браузером.

К таким техникам относится другой способ обмена сообщениями, называемый длительный опросом (англ. long polling). После загрузки веб-страницы, клиентский код выполняет запрос, но сервер не отвечает и не закрывает соединение, пока не появятся новые данные или пока клиент не отключится самостоятельно. Как только данные появились – отправляется ответ и соединение закрывается. После чего клиент сразу же отправляет следующий запрос, снова запуская процесс ожидания (рисунок 2).

Рисунок 2. Длинный опрос (long-polling)

Достоинства этого метода по сравнению с классическим опросом (polling):

• минимальное количество запросов;
• высокая временная точность событий;
• отсутствие необходимости длительного хранения событий сервером.

Общим недостатком для всех методов, работающих по средствам протокола HTTP, является избыточный размер сообщений, обусловленный передачей служебных HTTP-заголовков вместе с полезной информацией. Каждое подключение к серверу требует передачи полного набора НТТР-заголовков, и при необходимости обеспечения малого интервала времени между запросами это становится настоящей проблемой.

Для получения информации со стороны сервера также возможно использовать и дополнительные модули для браузеров, такие как Adobe Flash и Java. Они допускают простые TCP-соединения с сервером, которые могут использоваться для принудительной отправки клиентам оперативной информации. К проблемам применения сторонних модулей относится то, что нет никакой гарантии их установки в клиентском браузере, а также частые конфликты этих модулей с брандмауэрами, особенно в корпоративных сетях. Кроме того, технологии Comet не были приведены к стандарту и поэтому имеют проблему несовместимости кода в различных браузерах [2, с. 127].

Проблему стандартизации решают несколько современных технологий, являющихся часть спецификации HTML5.

Одна из таких технологий – Server-Sent Events (SSE) [4]. Эта технология позволяет клиентскому JavaScript коду в браузере создавать специальный объект EventSource, который сам обеспечивает соединение с сервером, делает пересоединение в случае обрыва и генерирует события при поступлении данных или возникновении ошибок.

После создания объекта EventSource с указанием адреса подключения браузер отправит запрос на установление соединения серверу. Чтобы соединение успешно открылось, сервер должен ответить с HTTP-заголовком "Content-Type: text/event-stream" и не закрывать соединение. После этого сервер может отправлять в открытое соединение сообщения, когда появляется новая информация (рисунок 3).

Рисунок 3. Server-Sent Events

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

Технология Server-Sent Events значительно уменьшает количество передаваемых по сети лишних данных, HTTP-заголовки передаются только при установлении соединения. Сообщения от сервера не сопровождаются HTTP-заголовками, что в значительной степени минимизирует накладные расходы на передачу. Однако передача данных таким способом возможна только в одностороннем порядке: от сервера к клиенту.

Альтернативным решением в виде части спецификации HTML5 является технология WebSocket. WebSocket – это протокол, предоставляющий двунаправленную полнодуплексную связь, работа которой обеспечивается поверх протокола TCP [6, с. 1]. Стандартизация программного интерфейса (WebSocket API) для доступа к протоколу из веб-браузера осуществляется организацией W3C [5], а сам протокол WebSocket определяется стандартом RFC 6455 [3]. Переключение с HTTP на WebSocket протокол происходит с помощью обмена специальными заголовками между клиентом и сервером. Если сервер в ответных заголовках подтверждает этот переход, то дальше общение идёт на специальном протоколе WebSocket, который уже не имеет с HTTP ничего общего.

После того как установлено соединение по протоколу WebSocket, сервер и клиент могут посылать друг другу сообщения, когда новая информация доступна на одной из сторон (рисунок 4). Таким образом, обеспечивается своевременная передача необходимой информации и поддержание ее в актуальном состоянии.

Рисунок 4. WebSocket

Протокол WebSocket подробно описан в RFC 6455 [3]. Здесь лишь отметим, что формат пакета (фрейма) данных имеет компактную структуру, обеспечивая минимум накладных расходов на передачу и повышая тем самым производительность. Кроме того, фреймы делятся на два больших типа: фреймы с данными и управляющие фреймы, предназначенные для проверки связи (ping) и закрытия соединения. Помимо передачи текстовой информации, фреймы с данными могут содержать и бинарные данные.

Для обеспечения безопасного соединения, WebSocket также может работать через TLS (Transport Layer Security). В таком случае, при создании экземпляра WebSocket с помощью HTML5 WebSocket API, указывается URL-схема “wss://” вместо “ws://” для незащищенного соединения. Этот метод является наиболее предпочтительным, обеспечивающим не только шифрование соединения, но и предотвращение разбора такого подключения прокси-серверами, некоторые версии которых могут изменять заголовки «обновления» протокола, приводя их в негодность.

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

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

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

• Использование современных подходов стандартизованных HTML5 (Server-Sent Events и WebSocket) позволяет существенно повысить производительность интерактивных веб-приложений с интенсивным обменом данными между клиентом и сервером. По возможности стоит придерживаться именно этих технологий коммуникации и прибегать к использованию более примитивных средств транспортировки данных, таких как Comet или опрос, лишь в случае отсутствия их поддержки используемыми браузерами.
• Server-Sent Events отправляются по традиционному протоколу HTTP. Это означает, что они не требуют специальной реализации протокола или сервера. Кроме того, SSE-cобытия имеют ряд особенностей, которые не имеют WebSocket по умолчанию, такие как автоматическое переподключение и идентификаторы событий. Использование SSE в веб-приложениях, в которых осуществляется однонаправленная передача данных от сервера клиенту, может ускорить время разработки.
• Для повышения надежности и отказоустойчивости в случае использования WebSocket можно применять балансировщик TCP-загруженности.
• Рекомендуется использовать безопасные WebSocket-подключения (wss). Прокси-серверы не станут заниматься закодированными подключениями, что обеспечит поддержу протокола старыми версиями серверов, а также добавится преимущество защищенности данных от подслушивания.
• При использовании SSE и WebSocket удобно использовать веб-сервер, реализующий цикл событий (англ. event loop) для поддержания асинхронности.

Список литературы:

1. Маккоу А. Веб-приложения на JavaScript. – СПб.: Питер, 2012. ­– 288 с.: ил.
2. Чедвик Д., Снайдер Т., Панда Х. ASP.NET MVC 4: Разработка реальных веб-приложений с помощью ASP.NET MVC.: Пер. с англ. – М.: ООО “И.Д. Вильямс”, 2013. – 432 с.: ил. 
3. Fette I., Melnikov A. The WebSocket Protocol. // The Internet Engineering Task Force (IETF), December 2011. [Электронный ресурс] – Режим доступа: https://tools.ietf.org/html/rfc6455 (Дата обращения: 18.06.2016).
4. Hickson I. Server-Sent Events. // World Wide Web Consortium (W3C), 3 February 2015. [Электронный ресурс] – Режим доступа: https://www.w3.org/TR/eventsource/ (Дата обращения: 18.06.2016).
5. Hickson I. The WebSocket API. // World Wide Web Consortium (W3C), 20 September 2012. [Электронный ресурс] – Режим доступа: https://www.w3.org/TR/websockets/ (Дата обращения: 18.06.2016).
6. Lombardi A. WebSocket. – O’Reilly Media, 2015 – pages: 144.