今天來聊聊 4 種接收實時更新的方法，各有利弊，在設(shè)計中酌情選取。

圖片

01 短輪詢（Short Polling）

這是最基本的方法?？蛻舳藭貜?fù)向服務(wù)器發(fā)送 HTTP 請求。

我們來看一個使用場景：我們登錄一個網(wǎng)站，看到一個二維碼，然后我們可以用智能手機掃描二維碼。這個二維碼通常用于特定操作，如身份驗證。應(yīng)用程序并不知道我們掃描二維碼的確切時間。因此，它會每隔 1-2 秒向服務(wù)器發(fā)送一次請求，以檢查 QR 碼的狀態(tài)。一旦我們用智能手機掃描了二維碼，服務(wù)器就會識別掃描，并響應(yīng)應(yīng)用程序的下一次檢查，發(fā)回最新狀態(tài)。這樣，我們就能在掃描二維碼后的 1-2 秒內(nèi)得到響應(yīng)。這種頻繁的檢查就是我們稱這種方法為 "短輪詢 "的原因。

這種方法有兩個問題：

1. 它會發(fā)送過多的 HTTP 請求。這會占用帶寬，增加服務(wù)器負(fù)載。
2. 在最糟糕的情況下，我們可能會等待長達(dá) 2 秒的響應(yīng)，造成明顯的延遲。

02 長輪詢（Long Polling）

長輪詢通過為 HTTP 請求設(shè)置更長的超時來解決短輪詢問題。在上文的例子中，我們將超時時間調(diào)整為 30 秒。如果我們在這個時間范圍內(nèi)掃描二維碼，服務(wù)器就會立即發(fā)送響應(yīng)。這種方法大大減少了 HTTP 請求的數(shù)量。

盡管長時間輪詢減少了請求數(shù)量，但每個開放的請求仍會與服務(wù)器保持連接。如果有很多客戶端，就會對服務(wù)器資源造成壓力。

03 WebSocket

短輪詢和長輪詢對于二維碼掃描等較簡單的任務(wù)都很有效。但對于復(fù)雜、數(shù)據(jù)量大、實時性強的任務(wù)（如在線游戲），則需要更高效的解決方案 – 這就是 WebSocket。

TCP 本身允許雙向數(shù)據(jù)流，使客戶端和服務(wù)器可以同時向?qū)Ψ桨l(fā)送數(shù)據(jù)。然而，建立在 TCP 基礎(chǔ)上的 HTTP/1.1 并沒有充分利用這一功能。在 HTTP/1.1 中，數(shù)據(jù)傳輸通常是按順序進(jìn)行的：一方發(fā)送數(shù)據(jù)，然后另一方發(fā)送數(shù)據(jù)。這種設(shè)計雖然足以滿足網(wǎng)頁交互的需要，但對于在線游戲等需要同步實時通信的應(yīng)用來說，就顯得力不從心了。WebSocket 是另一種基于 TCP 的協(xié)議，它允許客戶端和服務(wù)器在單個連接上進(jìn)行全雙工通信，從而彌補了這一不足。

04 服務(wù)器發(fā)送事件（SSE，Server-Sent Events）

SSE 用于一些特殊的使用情況。當(dāng)客戶端建立 SSE 連接時，服務(wù)器會保持該連接開放以持續(xù)發(fā)送更新。這種設(shè)置非常適合服務(wù)器需要定期向客戶端推送數(shù)據(jù)，而客戶端只需接收數(shù)據(jù)，無需向服務(wù)器發(fā)送信息的情況。

一個典型的例子就是實時股票市場數(shù)據(jù)更新。有了 SSE，服務(wù)器就可以向客戶端推送實時數(shù)據(jù)，而無需在每次更新時發(fā)出請求。值得注意的是，與 WebSockets 不同，SSE 不支持雙向通信，因此不太適合需要來回通信的用例。