大綱
本系列會分為2-3篇文章.
- 第一篇介紹SignalR的預備知識和原理
- 然后會介紹SignalR和如何在ASP.NET Core里使用SignalR.
本文的目錄如下:
實時Web簡述
大家都見過和用過實時Web, 例如網頁版的即時通訊工具, 網頁直播, 網頁游戲, 還有股票儀表板等等.
傳統的Web應用是這樣工作的:
瀏覽器發送HTTP請求到ASP.NET Core Web服務器, 如果一切順利的話, Web服務器會處理請求並返回響應, 在Payload里面會包含所請求的數據.
但是這種工作方式對實時Web是不靈的. 實時Web需要服務器可以主動發送消息給客戶端(可以是瀏覽器):
Web服務器可以主動通知客戶端數據的變化, 例如收到了新的對話消息.
"底層"技術
而SignalR使用了三種"底層"技術來實現實時Web, 它們分別是Long Polling, Server Sent Events 和 Websocket.
首先, 得知道什么是Ajax. 這個就不介紹了.
Long Polling
Polling
介紹Long Polling之前, 首先介紹一下Polling.
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和用法即可.