實時通信技術大亂斗
本文轉載自微信公眾號「全棧碼農畫像」,作者小碼甲 。轉載本文請聯(lián)系全棧碼農畫像公眾號。
現代應用程序的很多功能依賴于實時數據通信:
- 聊天
- 實時股票更新
- 現場拍賣
- 體育/新聞實時更新
- 多人游戲
- 位置服務
- 進度條
HTTP通信的核心一直沒變,依舊是請求/響應模型,這給實時通信帶來了根本性挑戰(zhàn)。
多年來,開發(fā)者一直在嘗試以各種姿勢規(guī)避HTTP障礙。
我們快速總結流行的幾種技術,每種技術都有一個真實的軼事,以便于解釋。
定期輪詢
帶小孩徒步旅行?
孩子們間隔1,2分鐘就問:“我們到了嗎?”,你的回答干脆友善,但詢問/應答會持續(xù)出現。
客戶端定期詢問服務器是否有新信息, 顯然這不是實時的,如果輪詢間隔足夠短,可能會有一點效果。
定期輪詢確實會導致客戶端-服務器之間反復不必要的往返。
長輪詢 Comet
與你的孩子開啟另一趟徒步旅程。
但這一次,當孩子詢問, “我們到了嗎?”,你只是保持安靜,一直到下一站(或者發(fā)脾氣)才做出回應。
長輪詢是輪詢的一種高級形式,可滿足實時通信的需要。
客戶端向服務器發(fā)出信息請求,服務器hold請求,直到發(fā)生值得關注的事情(或請求即將超時)。
于此同時,客戶端需要針對響應和超時進行編程,以立即發(fā)起另一個請求。這樣確保客戶端/服務器具有持續(xù)的Comet請求以接受實時響應。
長輪詢和輪詢比起來,明顯減少了很多不必要的http請求次數,相比之下節(jié)約了資源。長輪詢的缺點在于,連接掛起也會導致資源的浪費。
長輪詢仍然很流行,但它通常需要在服務器和客戶端自定義編程才能成功實現。
服務端發(fā)送事件 (SSE)
你在電商上購物,勾選了推送復選框。
之后你每天都會收到三次營銷郵件。
SSE是HTML5 新增的功能,SSE最大的特點就是不需要客戶端發(fā)送請求,可以實現只要服務器端數據有更新,就可以馬上發(fā)送到客戶端。
SSE很大程度上是從服務器到客戶端的定向推送,客戶端使用EventSource對象(HTML5標準)捕獲來自服務器的流式通知
WebSockets
你首次去國外旅行,一旦與對方確認了語言,后續(xù)溝通就無障礙。
WebSockets依賴于http1.1的持久連接機制,WebSockets握手階段需要http,連接一旦建立,客戶端和服務器端就處于平等的地位,可以全雙工通信,不存在請求和響應的區(qū)別。
以上技術可以解決HTTP障礙并促進實時通信。問題在于,大多數這些技術都需要開發(fā)人員的大量工作。
如果有一些框架可以消除通信的復雜性,讓開發(fā)人員可以專注于構建實時應用程序,那豈不是很好嗎?
SignalR是.NET技術棧成熟的實時通信框架。
SignalR為服務器和客戶端之間的雙向遠程過程調用(RPC)提供API,消除了實時通信的復雜性。
SignalR提供了統(tǒng)一的API畫布用于連接和客戶端管理,以及進行擴展以處理增加的流量。
SignalR使用服務器端集線器的概念來幫助已連接客戶端的實時通信和管理。服務器和客戶端可以無縫地相互調用方法,這種交互方法是強類型的。
雖然默認使用基于文本的JSON格式,但SignalR還支持Messagepack協(xié)議-(二進制數據序列化/反序列化),以提高效率。
gRPC
2015年推出的HTTP/2專注于安全、數據壓縮、更好的性能和更低的延遲。
gRPC是由Google開發(fā)的基于HTTP/2協(xié)議實現的高性能通用RPC框架。HTTP/2 的多路復用特性支撐了gRPC的流式傳輸能力。
開箱即用的gRPC提供了豐富的功能,例如集成身份驗證,雙向流和流控制。
gRPC自動為各種語言和平臺生成跨平臺客戶端和服務器綁定代碼。gRPC服務的定義和信息交換的格式是Protocol Buffers(一種功能強大的二進制序列化/反序列化工具集和語言)。
https://www.techunits.com/topics/architecture-design/exclusive-comparison-between-websockets-and-grpc/