共用方式為

SignalR 簡介

  • 發行項

作者： Patrick Fletcher

警告

本檔不適用於最新版的 SignalR。 請查看ASP.NET Core SignalR。

本文說明 SignalR 是什麼，以及其設計來建立的一些解決方案。

問題和批註

請留下您喜歡本教學課程的意見反應，以及我們可以在頁面底部的批註中改善的內容。 如果您有與教學課程不直接相關的問題，您可以將問題張貼到 ASP.NET SignalR 論壇 或 StackOverflow.com。

什麼是 SignalR？

ASP.NET SignalR 是 ASP.NET 開發人員的程式庫，可簡化將即時 Web 功能新增至應用程式的程式。 即時 Web 功能是能夠讓伺服器程式碼立即將內容推送至已連線的用戶端，因為它可供使用，而不是讓伺服器等候用戶端要求新資料。

SignalR 可用來將任何類型的「即時」Web 功能新增至您的 ASP.NET 應用程式。 雖然聊天通常用來做為範例，但您可以執行更多動作。 每當使用者重新整理網頁以查看新資料，或頁面實作 長時間輪詢 來擷取新資料時，它是使用 SignalR 的候選項目。 範例包括儀表板和監視應用程式、共同作業應用程式 (，例如同時編輯檔) 、作業進度更新和即時表單。

SignalR 也啟用需要伺服器高頻率更新的全新 Web 應用程式類型，例如即時遊戲。

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 傳輸

下列傳輸是以 Comet Web 應用程式模型為基礎，其中瀏覽器或其他用戶端會維護長時間保存的 HTTP 要求，伺服器可用來將資料推送至用戶端，而不需要用戶端特別要求。

  • 僅限 Internet Explorer) 的 Frame (。 Forever Frame 會建立隱藏的 IFrame，向伺服器上未完成的端點提出要求。 然後，伺服器會持續將腳本傳送至立即執行的用戶端，並提供從伺服器到用戶端的單向即時連線。 從用戶端到伺服器的連線會使用與伺服器與用戶端連線的個別連線，就像標準 HTTP 要求一樣，會針對需要傳送的每個資料片段建立新的連線。
  • Ajax 長輪詢。 長時間輪詢不會建立持續性連線，而是使用保持開啟的要求輪詢伺服器，直到伺服器回應為止，此時連線關閉，並立即要求新的連線。 這可能會在連線重設時造成一些延遲。

如需哪些組態支援哪些傳輸的詳細資訊，請參閱 支援的平臺。

傳輸選取程式

下列清單顯示 SignalR 用來決定要使用的傳輸的步驟。

  1. 如果瀏覽器是 Internet Explorer 8 或更早版本，則會使用 Long Polling。

  2. 如果 JSONP 設定 (， jsonp 則會在連線啟動時將 參數設定 true 為) ，則會使用長輪詢。

  3. 如果進行跨網域連線 (亦即，如果 SignalR 端點不在與主控頁面相同的網域) ，則會在符合下列準則時使用 WebSocket：

    • 用戶端支援 CORS (跨原始來源資源分享) 。 如需哪些用戶端支援 CORS 的詳細資訊，請參閱caniuse.com。

    • 用戶端支援 WebSocket

    • 伺服器支援 WebSocket

      如果不符合上述任一準則，將會使用長輪詢。 如需跨網域連線的詳細資訊，請參閱 如何建立跨網域連線。

  4. 如果未設定 JSONP 且連線不是跨網域，則如果用戶端和伺服器都支援，則會使用 WebSocket。

  5. 如果用戶端或伺服器不支援 WebSocket，則會使用伺服器傳送的事件。

  6. 如果伺服器傳送的事件無法使用，則會嘗試永久框架。

  7. 如果 Forever Frame 失敗，則會使用長輪詢。

監視傳輸

您可以藉由在中樞上啟用記錄，並在瀏覽器中開啟主控台視窗，來判斷您的應用程式正在使用的傳輸。

若要在瀏覽器中啟用中樞事件的記錄功能，請將下列命令新增至用戶端應用程式：

$.connection.hub.logging = true;

  • 在 Internet Explorer 中，按 F12 開啟開發人員工具，然後按一下 [主控台] 索引標籤。

    Microsoft Internet Explorer 中的主控台

  • 在 Chrome 中，按 Ctrl+Shift+J 開啟主控台。

    Google Chrome 中的主控台

開啟主控台並啟用記錄功能後，您將能夠查看 SignalR 正在使用的傳輸。

Internet Explorer 中的主控台，顯示 WebSocket 傳輸

指定傳輸

交涉傳輸需要一定的時間和用戶端/伺服器資源。 如果已知用戶端功能，則可以在啟動用戶端連線時指定傳輸。 下列程式碼片段示範如何使用 Ajax Long Polling 傳輸來啟動連線，如同已知用戶端不支援任何其他通訊協定時所使用：

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

如果您想要用戶端依序嘗試特定傳輸，可以指定後援順序。 下列程式碼片段示範嘗試 WebSocket，並失敗，直接前往 Long Polling。

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

用於指定傳輸的字串常數定義如下：

  • webSockets
  • foreverFrame
  • serverSentEvents
  • longPolling

連線和中樞

SignalR API 包含兩種在用戶端和伺服器之間通訊的模型：持續性連線和中樞。

Connection 代表用來傳送單一收件者、群組或廣播訊息的簡單端點。 PersistentConnection 類別以 .NET 程式碼表示的持續性連線 API () 可讓開發人員直接存取 SignalR 公開的低階通訊協定。 使用連線通訊模型會熟悉已使用以連線為基礎的 API 的開發人員，例如 Windows Communication Foundation。

中樞是建置在連線 API 之上的高階管線，可讓您的用戶端和伺服器直接呼叫方法。 SignalR 會以魔術的方式處理跨機器界限分派，允許用戶端像本機方法一樣輕鬆地在伺服器上呼叫方法，反之亦然。 使用中樞通訊模型會熟悉已使用遠端調用 API 的開發人員，例如 .NET 遠端處理。 使用中樞也可讓您將強型別參數傳遞至方法，以啟用模型系結。

架構圖

下圖顯示中樞、持續性連線和用於傳輸的基礎技術之間的關聯性。

SignalR 架構圖，顯示 API、傳輸和用戶端

中樞的運作方式

當伺服器端程式碼在用戶端上呼叫方法時，會透過使用中傳輸傳送封包，其中包含當物件以方法參數形式傳送時所要 (呼叫的方法名稱和參數，它會使用 JSON) 序列化。 然後，用戶端會將方法名稱與用戶端程式代碼中定義的方法相符。 如果有相符專案，則會使用還原序列化參數資料來執行用戶端方法。

您可以使用 Fiddler 之類的工具來監視方法呼叫。下圖顯示從 SignalR 伺服器傳送至 Fiddler [記錄] 窗格中網頁瀏覽器用戶端的方法呼叫。 方法呼叫是從名為 MoveShapeHub 的中樞傳送，而叫用的方法稱為 updateShape 。

顯示 SignalR 流量的 Fiddler 記錄檢視

在此範例中，中樞名稱是使用 H 參數來識別;方法名稱是使用 M 參數來識別，而傳送至方法的資料則會使用 A 參數來識別。 產生此訊息的應用程式會在 高頻率即時教學 課程中建立。

選擇通訊模型

大部分的應用程式都應該使用中樞 API。 連線 API 可用於下列情況：

  • 必須指定實際傳送之訊息的格式。
  • 開發人員偏好使用傳訊和分派模型，而不是遠端調用模型。
  • 使用傳訊模型的現有應用程式正在移植到使用 SignalR。