Введение в 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 Explorer, Google Chrome и Mozilla Firefox, и имеет только частичную реализацию в других браузерах, таких как Opera и Safari.
  • Серверные отправленные события, также известные как EventSource (если браузер поддерживает серверные отправленные события, то есть все браузеры, кроме Internet Explorer).)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  7. Если сбой навсегда кадра, используется длинное опрашивание.

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

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

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

$.connection.hub.logging = true;

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

    Консоль в Microsoft Internet Explorer

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

    Консоль в Google Chrome

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

Консоль в Internet Explorer с транспортом WebSocket

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

Согласование транспорта занимает определенное время и ресурсы клиента или сервера. Если известны возможности клиента, то при запуске клиентского подключения можно указать транспорт. В следующем фрагменте кода показано, как начать подключение с помощью транспорта 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 обрабатывает отправку через границы компьютера, как будто с помощью магии, позволяя клиентам вызывать методы на сервере так же легко, как локальные методы, и наоборот. Использование модели коммуникации Центров будет знакомо разработчикам, которые использовали API удаленного вызова, такие как .NET удаленного взаимодействия. Использование концентратора также позволяет передавать строго типизированные параметры методам, включив привязку модели.

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

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

Схема архитектуры SignalR с API, транспортами и клиентами

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

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

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

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

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

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

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

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