[[395758]]

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

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

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

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

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

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

定期輪詢

帶小孩徒步旅行?

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

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

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

長(zhǎng)輪詢 Comet

與你的孩子開(kāi)啟另一趟徒步旅程。

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

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

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

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

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

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

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

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

之后你每天都會(huì)收到三次營(yíng)銷(xiāo)郵件。

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

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

WebSockets

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

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

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

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

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

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

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

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

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

gRPC

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

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

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

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

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