[[395758]]

本文轉載自微信公眾號「全棧碼農畫像」，作者小碼甲 。轉載本文請聯系全棧碼農畫像公眾號。

現代應用程序的很多功能依賴于實時數據通信：

• 聊天
• 實時股票更新
• 現場拍賣
• 體育/新聞實時更新
•  多人游戲
• 位置服務
• 進度條

HTTP通信的核心一直沒變，依舊是請求/響應模型，這給實時通信帶來了根本性挑戰。

多年來，開發者一直在嘗試以各種姿勢規避HTTP障礙。

我們快速總結流行的幾種技術，每種技術都有一個真實的軼事，以便于解釋。

定期輪詢

帶小孩徒步旅行?

孩子們間隔1,2分鐘就問：“我們到了嗎?”，你的回答干脆友善，但詢問/應答會持續出現。

客戶端定期詢問服務器是否有新信息， 顯然這不是實時的，如果輪詢間隔足夠短，可能會有一點效果。

定期輪詢確實會導致客戶端-服務器之間反復不必要的往返。

長輪詢 Comet

與你的孩子開啟另一趟徒步旅程。

但這一次，當孩子詢問， “我們到了嗎?”，你只是保持安靜，一直到下一站(或者發脾氣)才做出回應。

長輪詢是輪詢的一種高級形式，可滿足實時通信的需要。

客戶端向服務器發出信息請求，服務器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協議-(二進制數據序列化/反序列化)，以提高效率。

gRPC

2015年推出的HTTP/2專注于安全、數據壓縮、更好的性能和更低的延遲。

gRPC是由Google開發的基于HTTP/2協議實現的高性能通用RPC框架。HTTP/2 的多路復用特性支撐了gRPC的流式傳輸能力。

開箱即用的gRPC提供了豐富的功能，例如集成身份驗證，雙向流和流控制。

gRPC自動為各種語言和平臺生成跨平臺客戶端和服務器綁定代碼。gRPC服務的定義和信息交換的格式是Protocol Buffers(一種功能強大的二進制序列化/反序列化工具集和語言)。

https://www.techunits.com/topics/architecture-design/exclusive-comparison-between-websockets-and-grpc/