Javascript 長輪詢（Long polling）

長輪詢是與服務(wù)器保持持久連接的最簡單的方式，它不使用任何特定的協(xié)議，例如 WebSocket 或者 Server Sent Event。

它很容易實現(xiàn)，在很多場景下也很好用。

常規(guī)輪詢

從服務(wù)器獲取新信息的最簡單的方式是定期輪詢。也就是說，定期向服務(wù)器發(fā)出請求：“你好，我在這兒，你有關(guān)于我的任何信息嗎？”例如，每 10 秒一次。

作為響應(yīng)，服務(wù)器首先通知自己，客戶端處于在線狀態(tài)，然后 —— 發(fā)送目前為止的消息包。

這可行，但是也有些缺點：

1. 消息傳遞的延遲最多為 10 秒（兩個請求之間）。
2. 即使沒有消息，服務(wù)器也會每隔 10 秒被請求轟炸一次，即使用戶切換到其他地方或者處于休眠狀態(tài)，也是如此。就性能而言，這是一個很大的負擔(dān)。

因此，如果我們討論的是一個非常小的服務(wù)，那么這種方式可能可行，但總的來說，它需要改進。

長輪詢

所謂“長輪詢”是輪詢服務(wù)器的一種更好的方式。

它也很容易實現(xiàn)，并且可以無延遲地傳遞消息。

其流程為：

1. 請求發(fā)送到服務(wù)器。
2. 服務(wù)器在有消息之前不會關(guān)閉連接。
3. 當(dāng)消息出現(xiàn)時 —— 服務(wù)器將對其請求作出響應(yīng)。
4. 瀏覽器立即發(fā)出一個新的請求。

對于此方法，瀏覽器發(fā)出一個請求并與服務(wù)器之間建立起一個掛起的（pending）連接的情況是標(biāo)準(zhǔn)的。僅在有消息被傳遞時，才會重新建立連接。

如果連接丟失，可能是因為網(wǎng)絡(luò)錯誤，瀏覽器會立即發(fā)送一個新請求。

實現(xiàn)長輪詢的客戶端 ?subscribe? 函數(shù)的示例代碼：

async function subscribe() {
  let response = await fetch("/subscribe");

  if (response.status == 502) {
    // 狀態(tài) 502 是連接超時錯誤，
    // 連接掛起時間過長時可能會發(fā)生，
    // 遠程服務(wù)器或代理會關(guān)閉它
    // 讓我們重新連接
    await subscribe();
  } else if (response.status != 200) {
    // 一個 error —— 讓我們顯示它
    showMessage(response.statusText);
    // 一秒后重新連接
    await new Promise(resolve => setTimeout(resolve, 1000));
    await subscribe();
  } else {
    // 獲取并顯示消息
    let message = await response.text();
    showMessage(message);
    // 再次調(diào)用 subscribe() 以獲取下一條消息
    await subscribe();
  }
}

subscribe();

正如你所看到的，subscribe 函數(shù)發(fā)起了一個 fetch，然后等待響應(yīng)，處理它，并再次調(diào)用自身。

服務(wù)器應(yīng)該可以處理許多掛起的連接

服務(wù)器架構(gòu)必須能夠處理許多掛起的連接。

某些服務(wù)器架構(gòu)是每個連接對應(yīng)一個進程，導(dǎo)致進程數(shù)和連接數(shù)一樣多，而每個進程都會消耗相當(dāng)多的內(nèi)存。因此，過多的連接會消耗掉全部內(nèi)存。

使用像 PHP 和 Ruby 語言編寫的后端程序會經(jīng)常遇到這個問題。

使用 Node.js 編寫的服務(wù)端程序通常不會出現(xiàn)此類問題。

也就是說，這不是編程語言的問題。大多數(shù)現(xiàn)代編程語言，包括 PHP 和 Ruby，都允許實現(xiàn)更適當(dāng)?shù)暮蠖顺绦?。只是請確保你的服務(wù)器架構(gòu)在同時有很多連接的情況下能夠正常工作。

示例：聊天

這是一個聊天演示，你可以下載它并在本地運行（如果你熟悉 Node.js 并且可以安裝模塊）：

下載鏈接

瀏覽器代碼在 browser.js 中。

使用場景

在消息很少的情況下，長輪詢很有效。

如果消息比較頻繁，那么上面描繪的請求-接收（requesting-receiving）消息的圖表就會變成鋸狀狀（saw-like）。

每個消息都是一個單獨的請求，并帶有 header，身份驗證開銷（authentication overhead）等。

因此，在這種情況下，首選另一種方法，例如：Websocket 或 Server Sent Events。