一圖看懂 4 種接收實時數據更新的設計
今天來聊聊 4 種接收實時更新的方法，各有利弊，在設計中酌情選取。
01 短輪詢（Short Polling）
這是最基本的方法。客戶端會重複向服務器發送 HTTP 請求。
我們來看一個使用場景：我們登錄一個網站，看到一個二維碼，然後我們可以用智能手機掃描二維碼。這個二維碼通常用於特定操作，如身份驗證。應用程序並不知道我們掃描二維碼的確切時間。因此，它會每隔 1-2 秒向服務器發送一次請求，以檢查 QR 碼的狀態。一旦我們用智能手機掃描了二維碼，服務器就會識別掃描，並響應應用程序的下一次檢查，發回最新狀態。這樣，我們就能在掃描二維碼後的 1-2 秒內得到響應。這種頻繁的檢查就是我們稱這種方法爲 "短輪詢" 的原因。
這種方法有兩個問題：
-
它會發送過多的 HTTP 請求。這會佔用帶寬，增加服務器負載。
-
在最糟糕的情況下，我們可能會等待長達 2 秒的響應，造成明顯的延遲。
02 長輪詢（Long Polling）
長輪詢通過爲 HTTP 請求設置更長的超時來解決短輪詢問題。在上文的例子中，我們將超時時間調整爲 30 秒。如果我們在這個時間範圍內掃描二維碼，服務器就會立即發送響應。這種方法大大減少了 HTTP 請求的數量。
儘管長時間輪詢減少了請求數量，但每個開放的請求仍會與服務器保持連接。如果有很多客戶端，就會對服務器資源造成壓力。
03 WebSocket
短輪詢和長輪詢對於二維碼掃描等較簡單的任務都很有效。但對於複雜、數據量大、實時性強的任務（如在線遊戲），則需要更高效的解決方案 – 這就是 WebSocket。
TCP 本身允許雙向數據流，使客戶端和服務器可以同時向對方發送數據。然而，建立在 TCP 基礎上的 HTTP/1.1 並沒有充分利用這一功能。在 HTTP/1.1 中，數據傳輸通常是按順序進行的：一方發送數據，然後另一方發送數據。這種設計雖然足以滿足網頁交互的需要，但對於在線遊戲等需要同步實時通信的應用來說，就顯得力不從心了。WebSocket 是另一種基於 TCP 的協議，它允許客戶端和服務器在單個連接上進行全雙工通信，從而彌補了這一不足。
04 服務器發送事件（SSE，Server-Sent Events）
SSE 用於一些特殊的使用情況。當客戶端建立 SSE 連接時，服務器會保持該連接開放以持續發送更新。這種設置非常適合服務器需要定期向客戶端推送數據，而客戶端只需接收數據，無需向服務器發送信息的情況。
一個典型的例子就是實時股票市場數據更新。有了 SSE，服務器就可以向客戶端推送實時數據，而無需在每次更新時發出請求。值得注意的是，與 WebSockets 不同，SSE 不支持雙向通信，因此不太適合需要來回通信的用例。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QN1bH_MXgp4JbeOvPomz1A