現代應用程式的很多功能依賴於實時通訊技術：
- 聊天
- 實時股票更新
- 現場拍賣
- 體育/新聞實時更新
- 多人遊戲
- 位置服務
- 進度條
HTTP通訊的核心一直沒變，依舊是請求/響應模型，這給實時通訊帶來了根本性挑戰。
多年來，開發者一直在嘗試以各種姿勢規避HTTP障礙。
我們快速總結流行的幾種技術，每種技術都有一個真實的軼事，以便於解釋。
定期輪詢
帶小孩徒步旅行？
孩子們間隔1,2分鐘就問：“我們到了嗎？”，你的回答乾脆友善，但詢問/應答會持續出現。
客戶端定期詢問伺服器是否有新資訊， 顯然這不是實時的，如果輪詢間隔足夠短，可能會有一點效果。
定期輪詢確實會導致客戶端-伺服器之間反覆不必要的往返。
長輪詢
與你的孩子開啟另一趟徒步旅程。
但這一次，當孩子詢問， “我們到了嗎？”，你只是保持沉默，一直到下一站（或者發脾氣）才做出回應。
長輪詢是輪詢的一種高階形式，可滿足實時通訊的需要。
客戶端向伺服器發出資訊請求，伺服器hold請求，直到發生值得關注的事情（或請求即將超時）。
於此同時，客戶端需要針對響應和超時進行程式設計，以立即發起另一個請求。這樣確保客戶端/伺服器具有持續的Comet請求以接受實時響應。
長輪詢和輪詢比起來，明顯減少了很多不必要的http請求次數，相比之下節約了資源。長輪詢的缺點在於，連線掛起也會導致資源的浪費。
長輪詢仍然很流行，但它通常需要在伺服器和客戶端自定義程式設計才能成功實現。
服務端傳送事件 (SSE)
你在電商上購物，勾選了推送核取方塊。
之後你每天都會收到三次營銷郵件。
SSE是HTML5 新增的功能，SSE最大的特點就是不需要客戶端傳送請求，可以實現只要伺服器端資料有更新，就可以馬上傳送到客戶端。
SSE很大程度上是從伺服器到客戶端的定向推送，客戶端使用EventSource物件（HTML5標準）捕獲來自伺服器的流式通知。
WebSockets
你首次去國外旅行，一旦與對方確認了語言，後續溝通就無障礙。
WebSockets依賴於http1.1的持久連線機制，WebSockets握手階段需要http，連線一旦建立，客戶端和伺服器端就處於平等的地位，可以全雙工通訊，不存在請求和響應的區別。
以上技術可以解決HTTP障礙並促進實時通訊。問題在於，大多數這些技術都需要開發人員的大量工作。
如果有一些框架可以消除通訊的複雜性，讓開發人員可以專注於構建實時應用程式，那豈不是很好嗎？
SignalR是.NET技術棧成熟的實時通訊框架。
SignalR為伺服器和客戶端之間的雙向遠端過程呼叫（RPC）提供API，消除了實時通訊的複雜性。
SignalR提供了統一的API畫布用於連線和客戶端管理，以及進行擴充套件以處理增加的流量。
SignalR使用伺服器端集線器的概念來幫助已連線客戶端的實時通訊和管理。伺服器和客戶端可以無縫地相互呼叫方法，這種互動方法是強型別的。
雖然預設使用基於文字的JSON格式，但SignalR還支援Messagepack協議-(二進位制資料序列化/反序列化)，以提高效率。
》 signalr是微軟推出的標準框架， 目前我已知有node，golang的實現。
gRPC
2015年推出的基於HTTP/2，專注於安全、資料壓縮、更好的效能和更低的延遲。
gRPC是由Google開發的基於HTTP/2協議實現的高效能通用RPC框架。HTTP/2 的多路複用特性支撐了gRPC的流式傳輸能力。
開箱即用的gRPC提供了豐富的功能，例如整合身份驗證，雙向流和流控制。
gRPC自動為各種語言和平臺生成跨平臺客戶端和伺服器繫結程式碼。gRPC服務的定義和資訊交換的格式是Protocol Buffers（一種功能強大的二進位制序列化/反序列化工具集和語言）。