ASP.NET Core的實時庫: SignalR -- 預備知識

時間 2019-11-08

標籤 asp.net asp core 實時 signalr 預備知識欄目 ASP 简体版

原文原文鏈接

大綱

本系列會分爲2-3篇文章.html

第一篇介紹SignalR的預備知識和原理
而後會介紹SignalR和如何在ASP.NET Core裏使用SignalR.

本文的目錄以下:前端

實時Web簡述

你們都見過和用過實時Web, 例如網頁版的即時通信工具, 網頁直播, 網頁遊戲, 還有股票儀表板等等.web

傳統的Web應用是這樣工做的:json

瀏覽器發送HTTP請求到ASP.NET Core Web服務器, 若是一切順利的話, Web服務器會處理請求並返回響應, 在Payload裏面會包含所請求的數據.瀏覽器

可是這種工做方式對實時Web是不靈的. 實時Web須要服務器能夠主動發送消息給客戶端(能夠是瀏覽器):緩存

Web服務器能夠主動通知客戶端數據的變化, 例如收到了新的對話消息.服務器

"底層"技術

而SignalR使用了三種"底層"技術來實現實時Web, 它們分別是Long Polling, Server Sent Events 和 Websocket.websocket

首先, 得知道什麼是Ajax. 這個就不介紹了.併發

Long Polling

Polling

介紹Long Polling以前, 首先介紹一下Polling.socket

Polling是實現實時Web的一種笨方法, 它就是經過按期的向服務器發送請求, 來查看服務器的數據是否有變化.

若是服務器數據沒有變化, 那麼就返回204 No Content; 若是有變化就把最新的數據發送給客戶端:

下面是Polling的一個實現, 很是簡單:

就看這個Controller的Get方法便可. 用到了MyService, 它在項目裏是單例的. 它的方法很是簡單:

MyService就是作了一個全局的Count, 它的GetLatestCount會返回最新的Count.

Controller裏面的代碼意思是: 若是Count > 6 就返回一個對象, 裏面包含count的值和傳進來的id; 若是 count > 10, 還要返回一個finished標誌.

看一下前端代碼:

也是很是的簡單, 點擊按鈕後定時發送請求, 若是有結果就顯示最新count值; 若是有finished標誌, 就顯示最新值和已結束.

注意這裏使用的是fetch API.

運行項目, count > 6的時候:

count > 10的時候結束:

這就是Polling, 很簡單, 可是比較浪費資源.

SignalR沒有采用Polling這種技術.

Long Polling

Long Polling和Polling有相似的地方, 客戶端都是發送請求到服務器. 可是不一樣之處是: 若是服務器沒有新數據要發給客戶端的話, 那麼服務器會繼續保持鏈接, 直到有新的數據產生, 服務器才把新的數據返回給客戶端.

若是請求發出後一段時間內沒有響應, 那麼請求就會超時. 這時, 客戶端會再次發出請求.

例子, Controller的代碼稍有改動:

改動的目的就是在符合要求的數據出現以前, 保持鏈接開放.

前端也有一些改動:

pollWithTimeout方法使用了race, 若是請求後超過9秒沒有響應, 那麼就返回超時錯誤.

poll裏面, 若是請求返回的結果是200, 那麼就更新UI. 可是若是沒有finished標誌, 就繼續發出請求.

運行:

能夠看到只有一個請求, 請求的時間很長, 標識鏈接開放了很長時間.

這裏須要注意的一點是, 服務器的超時時長和瀏覽器的超時時長可能不同.

前邊介紹的Polling和Long Polling都是HTTP請求, 這其實並非很適合.

下面介紹稍微一個好點的技術:

Server Sent Events (SSE)

使用SSE的話, Web服務器能夠在任什麼時候間把數據發送到瀏覽器, 能夠稱之爲推送. 而瀏覽器則會監聽進來的信息, 這些信息就像流數據同樣, 這個鏈接也會一直保持開放, 直到服務器主動關閉它.

瀏覽器會使用一個叫作EventSource的對象用來處理傳過來的信息.

例子, 這和以前的代碼有不少地方不一樣, 用到了Reponse:

注意SSE返回數據的只能是字符串, 並且以data:開頭, 後邊要跟着換行符號, 不然EventSource會失敗.

客戶端:

這個就很簡單了, 使用EventSource的onmessage事件. 前一個請求等到響應回來後, 會再發出一個請求.

運行:

這個EventSource要比Polling和Long Polling好不少.

它有如下優勢: 使用簡單(HTTP), 自動重連, 雖然不支持老瀏覽器可是很容易polyfill.

而缺點是: 不少瀏覽器都有最大併發鏈接數的限制, 只能發送文本信息, 單向通訊.

Web Socket

Web Socket是不一樣於HTTP的另外一個TCP協議. 它使得瀏覽器和服務器之間的交互式通訊變得可能. 使用WebSocket, 消息能夠從服務器發往客戶端, 也能夠從客戶端發往服務器, 而且沒有HTTP那樣的延遲. 信息流沒有完成的時候, TCP Socket一般是保持打開的狀態.

使用線代瀏覽器時, SignalR大部分狀況下都會使用Web Socket, 這也是最有效的傳輸方式.

全雙工通訊: 客戶端和服務器能夠同時往對方發送消息.

而且不受SSE的那個瀏覽器鏈接數限制(6個), 大部分瀏覽器對Web Socket鏈接數的限制是50個.

消息類型: 能夠是文本和二進制, Web Socket也支持流媒體(音頻和視頻).

其實正常的HTTP請求也使用了TCP Socket. Web Socket標準使用了握手機制把用於HTTP的Socket升級爲使用WS協議的 WebSocket socket.

生命週期

Web Socket的生命週期是這樣的:

全部的一切都發生在TCP Socket裏面, 首先一個常規的HTTP請求會要求服務器更新Socket並協商, 這個叫作HTTP握手. 而後消息就能夠在Socket裏來回傳送, 直到這個Socket被主動關閉. 在主動關閉的時候, 關閉的緣由也會被通訊.

HTTP 握手

每個Web Socket開始的時候都是一個簡單的HTTP Socket.

客戶端首先發送一個GET請求到服務器, 來請求升級Socket.

若是服務器贊成的話, 這個Socket從這時開始就變成了Web Socket.

這個請求的示例以下:

第一行代表這就是一個HTTP GET請求.

Upgrade 這個Header表示請求升級socket到Web Socket.

Sec-WebSocket-Key, 也很重要, 它用於防止緩存問題, 具體請查看官方文檔.

服務器理解並贊成請求之後, 它的響應以下:

返回101狀態碼, 表示切換協議.

若是返回的不是101, 那麼瀏覽器就會知道服務器沒有處理WebSocket的能力.

此外Header裏面還有Upgrade: websocket.

Sec-WebSocket-Accept是配合着Sec-WebSocket-Key來運做的, 具體請查閱官方文檔.

消息類型

Web Socket的消息類型能夠是文本, 二進制. 也包括控制類的消息: Ping/Pong, 和關閉.

每一個消息由一個或多個Frame組成:

全部的Frame都是二進制的. 因此文本的話, 就會首先轉化成二進制.

Frame 有若干個Header bits.

有的能夠表示這個Frame是不是消息的最後一個Frame;

有的能夠表示消息的類型.

有的能夠表示消息是否被掩蔽了. 客戶端到服務器的消息被掩蔽了, 爲了防止緩存投毒(使用惡意數據替換緩存).

有的能夠設置payload的長度, payload會佔據frame剩下的地方.

實際上用的時候, 你基本不會觀察到frame, 它是在後臺處理的, 你能看到的就是完整的消息.

可是在瀏覽器調試的時候, 你看到的是frame挨個傳遞進來而不是整個消息.

看下例子:

首先ASP.NET Core項目裏已經內置了WebSocket, 可是須要配置和使用這個中間件, 在Startup:

這裏咱們設置了每隔120秒就ping一下. 還設置用於接收和解析frame的緩存大小. 其實這兩個值都是默認的值.

修改後的Controller:

這裏須要注入HttpContextAccessor. 而後判斷請求是不是WebSocket請求, 若是是的話, 客戶端會收到回覆, 這時Socket就升級完成了. 升級完返回一個webSocket對象, 而後我把events經過它發送出去. 隨後我關閉了webSocket, 並指明瞭緣由NormalClosure.

而後看看SendEvents方法:

這裏的重點就是webSocket對象的SendAsync方法. 我須要把數據轉化成buffer進行傳送. 數據類型是Text. 具體參數請查看文檔.

看一下客戶端:

也很簡單, 這裏有一個WebSocket對象, 注意這裏的url開頭是ws而不是http, 還有一個wss, 就先當與http裏的https.

而後eventhandler和SSE的差很少. 返回的json數據須要先parse, 而後再使用.

本文先到這, 隨後再介紹下SignalR和用法便可.