SignalR 進階

SignalR 客戶端使用 WebSocket 的條件

客戶端瀏覽器需要支持 WebSocket：WebSocket 是一種 HTML5 的新技術，因此要使用 WebSocket，客戶端瀏覽器必須支持 WebSocket 協議。大多數現代瀏覽器都已經支持了 WebSocket，包括 Chrome、Firefox、Safari 等。

雙向通信：WebSocket 可以在客戶端和服務器之間建立雙向通信的連接。相比傳統的 HTTP 請求-響應模式，WebSocket 允許服務器主動推送數據給客戶端，實現實時的雙向通信。
實時性：WebSocket 提供了一種低延遲、高效率的實時通信機制。與輪詢或長輪詢等傳統的實時通信方式相比，WebSocket 可以更快速地傳輸數據，降低了通信的延遲，使得實時應用更加流暢和響應迅速。
較少的開銷：WebSocket 使用較少的網絡帶寬和服務器資源。由於 WebSocket 是基於長連接的，不需要每次通信都建立新的連接，而是通過一個持久的連接進行數據傳輸，減少了每次連接的開銷。
更好的兼容性：WebSocket 是標準化的協議，被廣泛支持。現代的瀏覽器都支持 WebSocket，而且常見的服務器技術也提供了對 WebSocket 的支持。這爲開發者提供了更好的兼容性和跨平臺的能力。

當你將 SignalR 服務部署到與 HTTP 服務相同的站點時，可以使用同一個域名和端口來訪問它們。這種方式可以讓客戶端從同一個站點直接與 SignalR 服務建立連接，無需跨域訪問，減少了跨域訪問帶來的額外配置和複雜性。

在 SignalR 中，可以使用事件處理程序來處理並響應 SignalR Hub 的各種事件。以下是一些常用的 SignalR 事件處理程序：

OnConnectedAsync：當客戶端成功連接到 SignalR Hub 時觸發。可以在此處執行初始化操作、記錄連接日誌等。

public override Task OnConnectedAsync()
{
    // 在客戶端連接成功時執行的邏輯代碼
    return base.OnConnectedAsync();
}

OnDisconnectedAsync：當客戶端與 SignalR Hub 斷開連接時觸發。可以在此處執行清理操作、更新狀態等。

public override Task OnDisconnectedAsync(Exception exception)
{
    // 在客戶端斷開連接時執行的邏輯代碼
    return base.OnDisconnectedAsync(exception);
}

自定義的客戶端-服務器方法：您可以定義自己的方法，使客戶端能夠調用這些方法，而服務器可以通過事件處理程序來響應這些方法的調用。

public async Task SendMessage(string user, string message)
{
    // 處理客戶端發送的消息
    await Clients.All.SendAsync("ReceiveMessage", user, message);
}

OnReconnectedAsync：當客戶端在斷開連接後重新連接到 SignalR Hub 時觸發。可以在此處執行恢復操作、更新狀態等。

public override Task OnReconnectedAsync()
{
    // 在客戶端重新連接時執行的邏輯代碼
    return base.OnReconnectedAsync();
}

您可以根據需要選擇和實現適當的事件處理程序來處理客戶端與 SignalR Hub 之間的連接、斷開連接和通信事件。這些事件處理程序可以通過重寫 Hub 類中定義的相應方法來實現。

如果覺得官方的jwt方案，比較麻煩，也可以自己實現。

自定義生成access_token方法與驗證access_token方法即可。

Azure 服務總線。服務總線是一種消息傳送基礎結構，允許組件以鬆散耦合的方式發送消息。
Redis。 Redis 是內存中鍵值存儲。 Redis 支持用於發送消息的發佈/訂閱 (“pub/sub”) 模式。
SQL Server。 SQL Server底板將消息寫入 SQL 表。底板使用 Service Broker 進行高效的消息傳送。但是，如果未啓用 Service Broker，它也有效。

在 SignalR 中，每條消息都通過消息總線發送。消息總線實現 IMessageBus 接口，該接口提供發佈/訂閱抽象。底板的工作原理是將默認的 IMessageBus 替換爲爲該底板設計的總線。例如，Redis 的消息總線是 RedisMessageBus，它使用 Redis 發佈/訂閱機制來發送和接收消息。
每個服務器實例通過總線連接到底板。發送消息時，消息將轉到底板，底板將消息發送到每個服務器。當服務器從底板獲取消息時，它會將消息放入其本地緩存中。然後，服務器將消息從其本地緩存傳遞到客戶端。
對於每個客戶端連接，使用遊標跟蹤客戶端讀取消息流的進度。 (遊標表示消息流中的位置。) 如果客戶端斷開連接，然後重新連接，它會要求總線提供客戶端遊標值之後到達的任何消息。當連接使用長時間輪詢時，也會發生同樣的情況。長時間輪詢請求完成後，客戶端將打開一個新連接，並請求在遊標之後到達的消息。
即使客戶端在重新連接時路由到其他服務器，遊標機制也有效。底板可識別所有服務器，客戶端連接到哪個服務器並不重要。