C# BS訊息推送 SignalR介紹（一）
1. 前言
本文是根據網上前人的總結得出的。
環境： SignalR2.x，VS2015，Win10
介紹
1）SignalR能用來持久客戶端與服務端的連線，讓我們便於開發一些實時的應用，例如聊天室線上預訂系統，股票交易等實時應用。
2）SignalR是開源的專案，是 ASP.NET 團隊正在開發的一個 Microsoft .NET Framework 庫和 jQuery 外掛。
3）SignalR 是一個整合的客戶端與伺服器庫，基於瀏覽器的客戶端和基於 ASP.NET 的伺服器元件可以藉助它來進行雙向多步對話。 換句話說，該對話可不受限制地進行單個無狀態請求/響應資料交換；它將繼續，直到明確關閉。 對話通過永久連線進行，允許客戶端向伺服器傳送多個訊息，並允許伺服器做出相應答覆
，值得注意的是，還允許伺服器向客戶端傳送非同步訊息。4）SignalR會使用Javascript的長輪詢（ long polling），實現客戶端和服務端通訊。在WebSockets出現以後，SignalR也支援WebSockets通訊。當然SignalR也使用了服務端的任務並行處理技術以提高伺服器的擴充套件性。
聊天室要解決最大的問題就是 訊息的推送。當N個線上使用者 同時加入一個聊天室時，1個使用者傳送訊息，服務端就要把這個訊息轉發給特定的人。
之前的技術都是通過Javascript來不停地傳送請求來輪詢服務端的新的訊息。這種定期傳送Ajax請求給伺服器的方式，在使用者很大的情況下給伺服器帶來很大的壓力。
WebSockets這個技術的出現，很好地解決了這個問題，恰恰支援可以主動推送訊息，SignalR 支援WebSockets。我們可以看到未來網路應用中會大量出現自己吃WebSockets的程式，而SignalR應該也會廣泛在ASP.NET 網站中出現。
5）專案官網：http://signalr.net/
2. 技術發展
1）以前的技術：
| 應用技術 | 說明 | 優缺點 |
| 輪詢（polling） | 這應該是最常見的一種實現資料互動的方式，開發人員控制客戶端以一定時間間隔中向伺服器傳送Ajax查詢請求大，但是也因此，當伺服器端內容並沒有顯著變化時，這種連線方式將帶來很多無效的請求，造成伺服器資源損耗。適合併發量小，實時性要求低的應用模型，更像是定時任務。 |
優點：實現最為簡單，配置簡單，出錯機率小 |
| 長輪詢（long polling） | 長輪詢是對輪詢的改進，客戶端通過請求連線到伺服器，並保持一段時間的連線狀態，直到訊息更新或超時才返回Response並中止連線，可以有效減少無效請求的次數。屬於Comet實現 | 優點：有效減少無效連線，實時性較高 |
| iframe流 | iframe流方式是在頁面中插入一個隱藏的iframe，利用其src屬性在伺服器和客戶端之間建立一條長連結，伺服器向iframe傳輸資料（通常是HTML，內有負責插入資訊的javascript），來實時更新頁面。屬於Comet實現 | 優點：實時性高，瀏覽器相容度好 |
| WebSocket | WebSocket是HTML5提供的一種在單個 TCP 連線上進行全雙工通訊的協議，目前chrome、Firefox、Opera、Safari等主流版本均支援，Internet Explorer從10開始支援。另外因為WebSocket 提供瀏覽器一個原生的 socket實現，所以直接解決了 Comet 架構很容易出錯的問題，而在整個架構的複雜度上也比傳統的實現簡單得多。 | 優點：伺服器與客戶端之間交換的資料包檔頭很小，節約頻寬。全雙工通訊，伺服器可以主動傳送資料給客戶端。 |
2）SignalR：
當環境條件合適時，SignalR將WebSocket作為底層傳輸方式的優先實現，當然，它也能很高效地回退到其他技術。同時，SignalR提供了非常良好的Api以供遠端呼叫(RPC) 瀏覽器中的js程式碼。
| 傳輸方式 | 選擇條件 |
| long polling | 1.IE8或更早版本 |
| WebSocket | 1.正在使用跨域連線，並且符合以下條件（以下不滿足任一條則使用長輪詢） |
| ServerSendEvent | 客戶端或伺服器端不支援Websocket |
| Forever Frame | EventSource不可用（基本上除了IE外都支援） |
3. SignalR普通設定&介紹
1） 前端設定列印log
$.connection.chatHub.logging = true
2）SignalR有兩種連線，分為Persistent Connection(永久連線) 與 Hubs
有經典的介紹他們的區別：（這裡不翻譯，以免引起歧義）
From what I see in the Connection and Hubs section it seems that Hubs provide a topic system overlaying the lower-level persistent connections.
The example used in the documentation uses a chat room metaphor, where users can join a specific room and then only get messages from other users in the same room. More generically your code subscribes to a topic and then get just messages published to that topic. With the persistent connections you'd get all messages.
You could easily build your own topic system on top of the persistent connections, but in this case the SignalR team did the work for you already.
You can get topics or groups in persistent connections as well. The big difference is dispatching different types of messages. For example you have different kinds of messages and you want to send different kinds of payloads. With persistent connections you have to embed the message type in the payload (see Raw sample) but hubs gives you the ability to do RPC over a connection (lets you call methods on on the client from the server and from the server to the client). Another big thing is model binding. Hubs allow you to pass strongly typed parameters to methods.
| 通訊模型 | 說明 |
| Persistent Connections | Persistent Connections表示一個傳送單個，編組，廣播資訊的簡單終結點。開發人員通過使用永續性連線Api，直接訪問SignalR公開的底層通訊協議。 |
| Hubs | Hubs是基於連線Api的更高級別的通訊管道，它允許客戶端和伺服器上彼此直接呼叫方法，SignalR能夠很神奇地處理跨機器的排程，使得客戶端和伺服器端能夠輕鬆呼叫在對方端上的方法。使用Hub還允許開發人員將強型別的引數傳遞給方法並且繫結模型 |
請繼續前往下一篇文章
C# BS訊息推送 SignalR Hubs環境搭建與開發（二）
可以關注本人的公眾號，多年經驗的原創文章共享給大家。
