[[395758]]

本文轉(zhuǎn)載自微信公眾號「全棧碼農(nóng)畫像」，作者小碼甲 。轉(zhuǎn)載本文請聯(lián)系全棧碼農(nóng)畫像公眾號。

現(xiàn)代應(yīng)用程序的很多功能依賴于實(shí)時(shí)數(shù)據(jù)通信：

• 聊天
• 實(shí)時(shí)股票更新
• 現(xiàn)場拍賣
• 體育/新聞實(shí)時(shí)更新
•  多人游戲
• 位置服務(wù)
• 進(jìn)度條

HTTP通信的核心一直沒變，依舊是請求/響應(yīng)模型，這給實(shí)時(shí)通信帶來了根本性挑戰(zhàn)。

多年來，開發(fā)者一直在嘗試以各種姿勢規(guī)避HTTP障礙。

我們快速總結(jié)流行的幾種技術(shù)，每種技術(shù)都有一個(gè)真實(shí)的軼事，以便于解釋。

定期輪詢

帶小孩徒步旅行?

孩子們間隔1,2分鐘就問：“我們到了嗎?”，你的回答干脆友善，但詢問/應(yīng)答會持續(xù)出現(xiàn)。

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

定期輪詢確實(shí)會導(dǎo)致客戶端-服務(wù)器之間反復(fù)不必要的往返。

長輪詢 Comet

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

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

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

客戶端向服務(wù)器發(fā)出信息請求，服務(wù)器hold請求，直到發(fā)生值得關(guān)注的事情(或請求即將超時(shí))。

于此同時(shí)，客戶端需要針對響應(yīng)和超時(shí)進(jìn)行編程，以立即發(fā)起另一個(gè)請求。這樣確?？蛻舳?服務(wù)器具有持續(xù)的Comet請求以接受實(shí)時(shí)響應(yīng)。

長輪詢和輪詢比起來，明顯減少了很多不必要的http請求次數(shù)，相比之下節(jié)約了資源。長輪詢的缺點(diǎn)在于，連接掛起也會導(dǎo)致資源的浪費(fèi)。

長輪詢?nèi)匀缓芰餍?，但它通常需要在服?wù)器和客戶端自定義編程才能成功實(shí)現(xiàn)。

服務(wù)端發(fā)送事件 (SSE)

你在電商上購物，勾選了推送復(fù)選框。

之后你每天都會收到三次營銷郵件。

SSE是HTML5 新增的功能，SSE最大的特點(diǎn)就是不需要客戶端發(fā)送請求，可以實(shí)現(xiàn)只要服務(wù)器端數(shù)據(jù)有更新，就可以馬上發(fā)送到客戶端。

SSE很大程度上是從服務(wù)器到客戶端的定向推送，客戶端使用EventSource對象(HTML5標(biāo)準(zhǔn))捕獲來自服務(wù)器的流式通知

WebSockets

你首次去國外旅行，一旦與對方確認(rèn)了語言，后續(xù)溝通就無障礙。

WebSockets依賴于http1.1的持久連接機(jī)制，WebSockets握手階段需要http，連接一旦建立，客戶端和服務(wù)器端就處于平等的地位，可以全雙工通信，不存在請求和響應(yīng)的區(qū)別。

以上技術(shù)可以解決HTTP障礙并促進(jìn)實(shí)時(shí)通信。問題在于，大多數(shù)這些技術(shù)都需要開發(fā)人員的大量工作。

如果有一些框架可以消除通信的復(fù)雜性，讓開發(fā)人員可以專注于構(gòu)建實(shí)時(shí)應(yīng)用程序，那豈不是很好嗎?

SignalR是.NET技術(shù)棧成熟的實(shí)時(shí)通信框架。

SignalR為服務(wù)器和客戶端之間的雙向遠(yuǎn)程過程調(diào)用(RPC)提供API，消除了實(shí)時(shí)通信的復(fù)雜性。

SignalR提供了統(tǒng)一的API畫布用于連接和客戶端管理，以及進(jìn)行擴(kuò)展以處理增加的流量。

SignalR使用服務(wù)器端集線器的概念來幫助已連接客戶端的實(shí)時(shí)通信和管理。服務(wù)器和客戶端可以無縫地相互調(diào)用方法，這種交互方法是強(qiáng)類型的。

雖然默認(rèn)使用基于文本的JSON格式，但SignalR還支持Messagepack協(xié)議-(二進(jìn)制數(shù)據(jù)序列化/反序列化)，以提高效率。

gRPC

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

gRPC是由Google開發(fā)的基于HTTP/2協(xié)議實(shí)現(xiàn)的高性能通用RPC框架。HTTP/2 的多路復(fù)用特性支撐了gRPC的流式傳輸能力。

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

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

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