今天來聊聊 4 種接收實時更新的方法,各有利弊,在設計中酌情選取。
圖片
這是最基本的方法??蛻舳藭貜拖蚍掌靼l送 HTTP 請求。
我們來看一個使用場景:我們登錄一個網站,看到一個二維碼,然后我們可以用智能手機掃描二維碼。這個二維碼通常用于特定操作,如身份驗證。應用程序并不知道我們掃描二維碼的確切時間。因此,它會每隔 1-2 秒向服務器發送一次請求,以檢查 QR 碼的狀態。一旦我們用智能手機掃描了二維碼,服務器就會識別掃描,并響應應用程序的下一次檢查,發回最新狀態。這樣,我們就能在掃描二維碼后的 1-2 秒內得到響應。這種頻繁的檢查就是我們稱這種方法為 "短輪詢 "的原因。
這種方法有兩個問題:
長輪詢通過為 HTTP 請求設置更長的超時來解決短輪詢問題。在上文的例子中,我們將超時時間調整為 30 秒。如果我們在這個時間范圍內掃描二維碼,服務器就會立即發送響應。這種方法大大減少了 HTTP 請求的數量。
盡管長時間輪詢減少了請求數量,但每個開放的請求仍會與服務器保持連接。如果有很多客戶端,就會對服務器資源造成壓力。
短輪詢和長輪詢對于二維碼掃描等較簡單的任務都很有效。但對于復雜、數據量大、實時性強的任務(如在線游戲),則需要更高效的解決方案 – 這就是 WebSocket。
TCP 本身允許雙向數據流,使客戶端和服務器可以同時向對方發送數據。然而,建立在 TCP 基礎上的 HTTP/1.1 并沒有充分利用這一功能。在 HTTP/1.1 中,數據傳輸通常是按順序進行的:一方發送數據,然后另一方發送數據。這種設計雖然足以滿足網頁交互的需要,但對于在線游戲等需要同步實時通信的應用來說,就顯得力不從心了。WebSocket 是另一種基于 TCP 的協議,它允許客戶端和服務器在單個連接上進行全雙工通信,從而彌補了這一不足。
SSE 用于一些特殊的使用情況。當客戶端建立 SSE 連接時,服務器會保持該連接開放以持續發送更新。這種設置非常適合服務器需要定期向客戶端推送數據,而客戶端只需接收數據,無需向服務器發送信息的情況。
一個典型的例子就是實時股票市場數據更新。有了 SSE,服務器就可以向客戶端推送實時數據,而無需在每次更新時發出請求。值得注意的是,與 WebSockets 不同,SSE 不支持雙向通信,因此不太適合需要來回通信的用例。
本文鏈接:http://www.www897cc.com/showinfo-26-34932-0.html一圖看懂四種接收實時數據更新的設計
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 讓你開發更舒適的 Tailwind 技巧
下一篇: 聊聊常見的限流算法有哪些?