Общие сведения о SignalR

Патрик Флетчер

В этой статье описывается, что такое SignalR, и некоторые из решений, которые он был разработан для создания.

Вопросы и комментарии

Оставьте отзыв о том, как вам понравилось это руководство и что, по вашему мнению, мы можем улучшить в комментариях в нижней части страницы. Если у вас есть вопросы, которые не связаны напрямую с руководством, вы можете опубликовать их на форуме ASP.NET SignalR или StackOverflow.com.

Что такое SignalR?

ASP.NET SignalR — это библиотека для разработчиков ASP.NET, которая упрощает процесс добавления веб-функций в приложения в режиме реального времени. Веб-функции в режиме реального времени — это возможность мгновенного отправки содержимого кода сервера подключенным клиентам по мере его доступности, а не ожидание, пока клиент будет запрашивать новые данные.

SignalR можно использовать для добавления в приложение ASP.NET любого типа веб-функций в режиме реального времени. Хотя чат часто используется в качестве примера, вы можете сделать гораздо больше. Каждый раз, когда пользователь обновляет веб-страницу, чтобы увидеть новые данные, или страница реализует длинный опрос для получения новых данных, он является кандидатом на использование SignalR. Примерами являются панели мониторинга и приложения мониторинга, приложения для совместной работы (например, одновременное редактирование документов), обновления хода выполнения заданий и формы в режиме реального времени.

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

SignalR предоставляет простой API для создания вызовов удаленных процедур между серверами (RPC), которые вызывают функции JavaScript в клиентских браузерах (и других клиентских платформах) из кода .NET на стороне сервера. SignalR также включает API для управления подключениями (например, события подключения и отключения) и группирования подключений.

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

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

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

Встроенные поставщики включают:

• Служебная шина
• SQL Server
• Редис

Сторонние поставщики включают:

• NCache.

SignalR — это открытый исходный код, доступный через GitHub.

SignalR и WebSocket

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

Транспорты и резервные механизмы

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

• Наиболее эффективное использование памяти сервера.
• Наименьшая задержка.
• Наиболее базовые функции, такие как полно дуплексное взаимодействие между клиентом и сервером.
• Наиболее строгие требования, WebSocket требует сервера:
  • Запустите windows Server 2012 или Windows 8.
  • .NET Framework 4.5.

Если эти требования не выполнены, SignalR пытается использовать другие транспорты для подключения.

Транспортные механизмы HTML 5

Эти транспорты зависят от поддержки HTML 5. Если клиентский браузер не поддерживает стандарт HTML5, будут использоваться старые транспорты.

• WebSocket (если сервер и браузер указывают, что они могут поддерживать Websocket). WebSocket — это единственный транспорт, который устанавливает истинное постоянное двустороннее подключение между клиентом и сервером. Однако WebSocket также имеет самые строгие требования; он полностью поддерживается только в последних версиях Microsoft Internet Explorer, Google Chrome и Mozilla Firefox, и только имеет частичную реализацию в других браузерах, таких как Опера и Safari.
• События, отправляемые сервером, также известные как EventSource (если браузер поддерживает их, что, по сути, так и есть за исключением Internet Explorer.)

Транспорты кометы

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

• Forever Frame (только для Internet Explorer). Forever Frame создает скрытый IFrame, который делает запрос к конечной точке на сервере, который не завершен. Затем сервер постоянно отправляет скрипт клиенту, который немедленно выполняется, предоставляя односторонняя связь между сервером и клиентом. Подключение от клиента к серверу использует отдельное подключение от сервера к клиентскому подключению, и, как стандартный HTTP-запрос, создается новое соединение для каждого фрагмента данных, которые должны быть отправлены.
• Аякс длинный опрос. Длинный опрос не создает постоянное подключение, а вместо этого опрашивает сервер с запросом, который остается открытым до тех пор, пока сервер не ответит, в какой момент соединение закрывается, а новое подключение запрашивается немедленно. Это может привести к некоторой задержке во время сброса подключения.

Дополнительные сведения о том, какие транспорты поддерживаются в соответствии с конфигурациями, см. в разделе "Поддерживаемые платформы".

Процесс выбора транспорта

В следующем списке показаны шаги, которые SignalR использует для выбора используемого транспорта.

1. Если браузер — Internet Explorer 8 или более ранней версии, используется лонгполлинг.

2. Если JSONP настроен (т. е. параметр задан при запуске подключения), используется длинный опрос.

3. Если выполняется подключение между доменами (то есть если конечная точка SignalR не находится в том же домене, что и страница размещения), webSocket будет использоваться, если выполнены следующие критерии:

   • Клиент поддерживает CORS (общий доступ к ресурсам между источниками). Дополнительные сведения о том, какие клиенты поддерживают CORS, см. в caniuse.com.

   • Клиент поддерживает WebSocket

   • Сервер поддерживает WebSocket

     Если какой-либо из этих критериев не соблюден, будет использоваться Long Polling. Дополнительные сведения о междоменных подключениях см. в статье "Установка междоменного подключения".

4. Если JSONP не настроен и подключение не является междоменной, WebSocket будет использоваться, если клиент и сервер поддерживают его.

5. Если ни клиент, ни сервер не поддерживают WebSocket, используются события, отправляемые сервером, если они доступны.

6. Если события отправки сервера недоступны, выполняется попытка использования Forever Frame.

7. Если в случае сбоя Forever Frame используется Длинный Опрос.

Мониторинг транспорта

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

Чтобы включить ведение журнала для событий центра в браузере, добавьте в клиентское приложение следующую команду:

$.connection.hub.logging = true;

• В Internet Explorer откройте средства разработчика, нажав клавишу F12 и перейдите на вкладку консоли.

  

• В Chrome откройте консоль, нажав клавиши CTRL+SHIFT+J.

  

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

Указание транспорта

Ведение переговоров по транспорту занимает определенное время и ресурсы клиента или сервера. Если известны возможности клиента, то при запуске подключения клиента можно указать транспорт. В следующем фрагменте кода показано, как начать подключение с помощью транспорта Long Polling Ajax, как было бы использовано, если клиент не поддерживал какой-либо другой протокол:

connection.start({ transport: 'longPolling' });

Вы можете задать порядок резервирования, если хотите, чтобы клиент пробовал определенные транспорты в определённой последовательности. В следующем фрагменте кода демонстрируется попытка использования WebSocket, а при его отказе — переход непосредственно к Long Polling.

connection.start({ transport: ['webSockets','longPolling'] });

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

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

Подключения и центры

API SignalR содержит две модели для обмена данными между клиентами и серверами: постоянные подключения и центры.

Соединение представляет собой простую конечную точку для отправки сообщений одиночному получателю, группированных или широковещательных сообщений. API сохраняемого подключения (представленный в коде .NET классом PersistentConnection) предоставляет разработчику прямой доступ к низкоуровневому протоколу связи, который предоставляет SignalR. Использование модели связи "Подключения" будет знакомо разработчикам, использующим API на основе подключений, например Windows Communication Foundation.

Концентратор — это более высокоуровневый конвейер, основанный на API соединения, который позволяет клиенту и серверу вызывать методы друг друга напрямую. SignalR обрабатывает отправку через границы компьютера, как будто по магии, позволяя клиентам вызывать методы на сервере так же легко, как локальные методы, и наоборот. Использование модели коммуникации Hubs будет знакомо разработчикам, которые использовали API для удаленного вызова, такие как .NET Remoting. Использование концентратора также позволяет передавать строго типизированные параметры методам, обеспечивая привязку модели.

Диаграмма архитектуры

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

Принцип работы Центров

Когда серверный код вызывает метод на клиенте, пакет отправляется через активный транспорт, содержащий имя и параметры вызываемого метода (когда объект отправляется в качестве параметра метода, он сериализуется с помощью JSON). Затем клиент сопоставляет имя метода методам, которые определены в клиентском коде. При наличии совпадения клиентский метод будет выполняться с помощью десериализированных данных параметров.

Вызов метода можно отслеживать с помощью таких средств, как Fiddler. На следующем рисунке показан вызов метода, отправленный с сервера SignalR на клиент веб-браузера в области журналов Fiddler. Вызов метода отправляется от концентратора MoveShapeHub, и выполняется метод updateShape.

В этом примере имя концентратора идентифицируется с H параметром; имя метода определяется параметром M , а данные, отправляемые методу, идентифицируются с параметром A . Приложение, сгенерировавшее это сообщение, создано в рамках руководства High-Frequency Realtime.

Выбор модели коммуникации

Большинство приложений должны использовать API Центров. API подключений можно использовать в следующих случаях:

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