23 февраля 2016г.
В настоящее время все чаще появляются веб-приложения, использующие технологии обновления данных в реальном времени. Приложениями, которые можно отнести к этой категории, чаще всего являются различные чаты и социальные сервисы. Наиболее распространенным примером являются такие сервисы как Twitter или Facebook. Многие из вас замечали, что страница обновляется автоматически, в реальном времени и без перезагрузки, когда приходят обновления сообщений или новостей. Эти приложения можно назвать веб- приложениями, работающими в реальном времени. Таким образом вы постоянно видите последнюю актуальную информацию.
С точки зрения программирования такой подход является достаточно интересным, так как нарушается привычная модель работы веб приложения – запрос-ответ, благодаря чему пользователи видят обновленные данные сразу же, как только они появляются на сервере.
Существует несколько способов реализации обновления данных в веб-приложении. Одним из первых методов, появившихся на просторах интернета, является «long polling». Он имеет довольно простую схему: клиент отправляет асинхронный запрос на сервер для получения новых данных и ожидает ответа, после чего отправляет новый запрос. Далее идет реализации части «long» - сервер не закрывает соединение до тех пор, пока не появятся новые данные или не произойдет необходимое событие. Каждый пакет данных, таким образом, означает новое соединение, которое будет открыто пока сервер не решит прислать информацию.
Следует также упомянуть Server-Sent Events - технологию отправки уведомлений от сервера на клиент в виде DOM-событий. Данная технология является стандартом, определяющим то, как серверы должны вести передачу данных веб браузеру с момента первого подключения. Сейчас стандарт широко используется для отправки уведомлений об обновлениях или для посылки постоянных потоков данных браузеру клиента. Протокол спроектирован для улучшения кросс-браузерного взаимодействия посредством JavaScript; с его помощью веб браузер задает ссылку для получения интересующего его потока событий. Технология Server-Sent Events в настоящее время стандартизируется как часть HTML5 организацией W3C.
Наиболее эффективной на данный момент методикой является WebSockets - протокол полнодуплексной связи поверх TCP-соединения, основным предназначением которого является передача сообщений между клиентом и сервером в режиме реального времени. Для установления соединения WebSocket клиент и сервер используют протокол, схожий с HTTP. Браузер формирует особый HTTP-запрос, на который сервер отвечает определенным образом. В настоящее время в W3C осуществляется стандартизация API Web Sockets. Черновой вариант стандарта этого протокола утверждѐн IETF. Основным преимуществом данной технологии является отсутствие необходимости постоянно пересоединяться с сервером.
Новейшие технологии, такие как Server-Sent Events и WebSockets поддерживаются не во всех браузерах.
«Long polling», являющийся по сути обыкновенным Ajax запросом для клиента, работает практически везде, но оказывает существенную нагрузку на сервер и имеет задержки при получении данных. Наилучшим выходом из данной ситуации было бы объединение приведенных методов в различных случаях, но это достаточно тяжело реализовать и поддерживать. Именно эту задачу и решает библиотека SignalR.
SignalR – это не что иное, как абстракция над приведенным набором техник. При выборе того или иного метода, преимущество отдается наиболее современным, так как они обеспечивают минимальную нагрузку на сервер и сеть. Когда пользователь заходит на сервис, работающий на SignalR, библиотека автоматически проверяет браузер пользователя на возможность использования того или иного метода отправки уведомлений. В случае, когда клиент не поддерживает ни одну из технологий, библиотека выберет самый надежный способ –
«long polling», который работает практически везде.
Одной из дополнительных возможностей SignalR является поддержка групп. Их можно использовать для объединения клиентских подключений на стороне сервера. Это полезно, когда необходимо сделать так, чтобы лишь определенные пользователи могли получать обновления.
Для небольших сервисов, у которых них нет нескольких тысяч пользователей онлайн и не подверженным высоким нагрузкам, приемлемым решением было бы всегда использовать «long polling». Но для больших проектов решение с «long polling», где каждый клиент с определѐнной периодичностью будет отправлять запрос на сервер, это создаст слишком высокую нагрузку. Конечно, мы можем оптимизировать запросы, клиентский и серверный код и создать цепочку серверов по всей стране, которые будут готовы обрабатывать все запросы клиентов. Но такое решение достаточно дорогое и дальнейший рост нагрузки на сервер приведет к необходимости использовать все большие мощности, что в конечном итоге приведет к убыткам.
SignalR может легко масштабироваться с помощью SQL Server, Redis или сервисной шины. Масштабирование означает добавление серверов по мере возрастания нагрузки. При этом нет необходимости изменять серверный код и есть возможность автоматизировать этот процесс, что является немаловажным фактором при разработке веб сервиса. Передача данных осуществляется при помощи текста в формате JSON в несжатом виде. В случае необходимости, для уменьшения объема передаваемого трафика между клиентом и сервером, можно передавать данные в сжатом виде.
При помощи SignalR можно без особых усилий абстрагироваться от технологий обмена данными и уделить время более важным вещам. Таким образом SignalR обеспечивает очень простой, высокоуровневый интерфейс прикладного программирования для реализации взаимодействия сервер-клиент в веб приложениях.
Список литературы
1. Server-sent events [Электронный ресурс] // Википедия. Режим доступа: https://ru.wikipedia.org/wiki/Server- sent_events
2. SignalR в помощь, или как оживить веб [Электронный ресурс] // Хабрахабр. Режим доступа: http://habrahabr.ru/company/dnevnik_ru/blog/167307/
3. WebSocket [Электронный ресурс] // Википедия. Режим доступа: https://ru.wikipedia.org/wiki/WebSocket
