系列目錄：ASP.NET MVC SignalR

關鍵詞：HTTP、輪詢、WebSocket、Server-Sent Events、長輪詢、forever frame。

?

---

?

1. HTTP

HTTP(HyperText Transfer Protocol，超文本傳輸協議)是Web應用程序客戶端和服務器之間進行“交談”的語言。

HTTP操作基于請求-響應模式，這種模式通常從客戶端發起請求開始。同時，請求-響應模式通常也被稱作拉(pull)模式：當客戶端需要訪問服務器上的資源時，它有目的地發起一個到服務器的連接，使用HTTP協議定義的“語言”請求所需的信息；服務器對請求進行處理并返回客戶端所請求的資源，然后立即關閉該連接。當客戶端每次需要獲取一個新資源，都將重復這樣的過程。

由此可見，整個HTTP操作是一個同步的過程：向服務器發送請求后，客戶端將被迫等待；在服務器進行響應之前，它什么都不做。即便是使用Ajax技術，這種操作模式使用和遵守的仍是HTTP協議和客戶端驅動的請求-響應模式。客戶端始終是主動的一方，由它決定何時連接服務器。但在實時通信中，服務器應是主動的一方，可以在任何時刻向客戶端發送信息，不需要客戶端顯式地進行請求。因此在有些情形下，HTTP并不是非常有效。

?

2. 輪詢

當我們需要服務器自身就能成為主動向客戶端發送信息的一方時，首先想到的方案應該是“輪詢”。“輪詢”通常指通過客戶端進行周期性的連接，定期檢查服務器上是否有一些相關的更新，仍然是通過HTTP的拉(pull)模式。

優點：

• • 實現簡單
  • 適用于任何情形以及所有的服務器和瀏覽器

缺點：

• • 頻繁的連接與斷開連接
  • 連接數量將與客戶端數量成比例增加

總之，盡管輪詢實現起來比較消耗資源，但如果應用于不需要頻繁更新的情形，它是一個不錯的選擇。

?

3. 推送

既然使用HTTP拉(pull)模式的應用程序效率并不是很高，自然就需要推(push)模式(服務器推送)了。

1）WebSocket

WebSocket標準包含了一套開發API，該API正由W3C(World Wide Web Consortium，萬維網聯盟)進行定義；此外，其通信協議正由IETF(Internet Engineering Task Force，Internet工程工作小組)負責制定。

基本上，WebSocket允許建立持久連接，這樣的連接在客戶端需要時發起，并一直保持開放。因此，客戶端和服務器之間創建的是一條雙向通道。通過這樣的雙向通道，通信的任何一方隨時都可以向另一方發送信息。

缺點：

• • 瀏覽器未實現WebSocket的所有功能
  • 服務器也需要支持WebSocket

但毫無疑問，WebSocket技術可用來實現未來的實時推送服務。

2）Server-Sent Events

Server-Sent Events也被稱作API Event Source，是W3聯盟正制定的第二個標準，但目前該標準還處于候選推薦狀態。它是一個相對簡單的Javascript API，不需要修改底層協議，實現和使用起來比WebSocket標準要簡單。

與WebSocket相比，Server-Sent Events將創建一個從服務器到客戶端的單向通道，但是由客戶端打開此通道。換言之，客戶端訂閱來自服務器的一個可用事件源，當數據通過該通道發送時，客戶端接受通知。

所有通信都執行在HTTP之上。和一些更傳統的連接方式相比，僅有的差別是響應中使用了Content-Type text/event-stream，這表明該連接將保持開放，因為它將用來從服務器發送連續的事件流或消息。

優點：

• • 幾乎目前所有的瀏覽器都支持該標準（除了IE和一些特定的移動瀏覽器）

缺點：

• • 必須對使用的Content-Type進行解析
  • 建立的是服務器到客戶端的單向通道，如果客戶端需要向服務器發送數據，它必須建立一個不同的連接才能完成，這將涉及比WebSocket更多的資源開銷

?

4. 基于HTTP的推送

1）長輪詢

這種推送技術和上文所述的輪詢非常類似，但為了提高通信的效率和即時性，它也進行了某些改進。

在這種情況下，客戶端同樣對更新進行輪詢，但與輪詢不同的是：如果沒有待接受的數據，連接將不會自動關閉，并且以后將再次發起。在長輪詢中，連接將一直保持開放狀態，直到服務器有事件要通知。

關閉由客戶端發起的連接僅有兩個方面的原因：

a. 服務器通過連接向客戶端發送數據

b. 由于連接空閑產生了超時錯誤

這兩種情況下，一條新的連接將立即建立，此時將再次等待更新。

此連接專門用于從服務器接收數據，如果客戶端需要向上發送數據，它將以并行的方式打開一個專門用于從服務器接收數據的HTTP接連。

優點：

• • 更新客戶端時的延遲比較低
  • 打開和關閉的連接數量減少，資源占用率比輪詢低
  • 不需要使用特殊的瀏覽器，HTTP提供的功能足矣

缺點：

• • 資源消耗比其它只打開一個連接的技術要高一些
  • 通知之間可能存在一些延遲

2）forever frame

forever frame巧妙利用了HTML的<IFRAME>標簽來建立永久開放的連接。在某種程度上，這和Server-Sent Events非常類似。

forever frame需要客戶端頁面有一個<IFRAME>標簽，標簽源中的URL用來指定正在監聽的服務器。服務器將保持此連接永久開放，并調用客戶端上定義的腳本函數，通過此連接發送更新。在某種程度上，我們可能會說該技術主要取決于接收時在客戶端執行的流腳本(streaming script)。

優點：

• • 資源利用率非常高
  • 實時效果非常好

缺點：

• • 使用復雜
  • 內存占用高
  • 當客戶端向服務器發送數據時還需要使用其它連接

?

5. 我們需要的不僅是推送

在異步、多用戶以及實時應用的環境中，推送只是不可或缺的一部分。為了開發出這些總能令人賞心悅目的系統，還需要更多的功能和特性：

• • 管理連接的用戶：服務器必須知道哪些用戶連接到服務，哪些用戶已經斷開連接，此外還需要對客戶端數量不確定的所有因素進行控制。
  • 管理訂閱：服務器必須能夠對訂閱進行管理，或對接收特定類型消息的用戶進行分組。
  • 接收和處理操作：服務器不僅能實時地將信息發送給客戶端，也能動態接收和處理信息。
  • 對信息的提交進行監控：單獨提供與消息排隊、信息提交管理有關的一些機制，從而確保所有客戶端都能被更新。
  • 能夠為多個客戶端提供靈活易用的API

轉載于:https://www.cnblogs.com/xiaoshi3003/p/4825777.html

總結

以上是生活随笔為你收集整理的ASP.NET MVC SignalR（1）：背景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。