Введение в SignalR

  • Статья

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

Предупреждение

Эта документация не для последней версии SignalR. Взгляните на ASP.NET Core 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

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

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

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

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

К сторонним поставщикам относятся:

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. Если клиентский браузер не поддерживает стандарт HTML 5, будут использоваться более старые транспорты.

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

Кометные транспорты

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

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

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

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

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

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

  2. Если настроен JSONP (то есть jsonp параметру присваивается значение true при запуске подключения), используется long polling.

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

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

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

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

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

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

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

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

  7. Если сбой Forever Frame, используется длинный опрос.

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

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

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

$.connection.hub.logging = true;

  • В Обозреватель Интернета откройте средства разработчика, нажав клавишу F12, и откройте вкладку Консоль.

    Консоль в Microsoft Internet Обозреватель

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

    Консоль в Google Chrome

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

Консоль в Обозреватель Интернета с транспортом WebSocket

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

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

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

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

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

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

  • webSockets
  • foreverFrame
  • serverSentEvents
  • longPolling

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

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

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

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

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

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

Схема архитектуры SignalR, показывающая API, транспорты и клиенты

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

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

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

Представление журнала Fiddler с трафиком SignalR

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

Выбор модели взаимодействия

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

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