在開發處理實時資料的 Web 應用程式時，重要的是要考慮如何有效地將資料交付給客戶端。 一種選擇是長輪詢。
優質作者列表 讓我們首先看看什麼是輪詢，以及它如何擴充套件到長輪詢。 輪詢是一種允許伺服器向客戶端傳送資訊的技術。 另一方面，長輪詢是傳統輪詢的一種變體，它使伺服器能夠在資料可用時將資料傳送到客戶端。 客戶端向伺服器傳送資訊請求，但伺服器可能不會立即響應。 相反，它會等到資料可用，然後向客戶端傳送完整的響應。 長輪詢是向客戶端傳送資訊的有效方法，因為它減少了傳輸相同數量資料所需的 HTTP 請求數。 但是，對於伺服器來說，在客戶端發出新請求之前管理未滿足的客戶端請求並處理可用的新資訊可能是乙個挑戰。
長輪詢的優點之一是它是 HTTP 協議的一部分，這使得它被廣泛接受，並且比短輪詢產生的頻寬更少。 總體而言，長時間輪詢是讓客戶實時了解新資訊的可靠方法。 下面是使用 HTTP 長輪詢的應用程式的基本流程：
客戶端傳送 HTTP 請求並等待伺服器的響應。
當更新可用時，伺服器會向客戶端提供完整的響應。
然後，客戶端會立即或在暫停後傳送新的長輪詢請求，以允許適當的延遲。
為每個長輪詢請求設定超時。 如果連線因超時而丟失，客戶端必須定期重新建立連線。
長輪詢是傳統輪詢的更有效版本，因為它減少了需要向伺服器發出的請求數。 在傳統輪詢中，每個請求都需要建立新的連線，解析HTTP頭，發出新的資料查詢，並生成和傳遞響應。 然後，連線將終止並清理資源。
長輪詢允許伺服器盡可能長時間地保持客戶端連線開啟狀態，僅在資料可用或達到超時閾值時才響應。 這樣就避免了在新資料可用之前為每個客戶端重複該過程的需要，這有助於節省資源。
在長時間輪詢中，大部分工作都是在伺服器端完成的。 在客戶端，只需要管理對伺服器的乙個請求。 當客戶端收到響應時，它可以發出新請求並根據需要重複該過程。 從客戶端的角度來看，基本輪詢和長輪詢之間的主要區別在於，執行基本輪詢的客戶端可能會故意在每個請求之間留出一小段時間視窗，以減少伺服器負載。 它還可能以不同於不支援長輪詢的伺服器的方式處理超時。
例如，對於長輪詢，可以將客戶端配置為在等待響應時允許更長的超時。 這樣做是為了避免與伺服器的通訊問題，這些問題可能由超時期限標識。
除了這些注意事項之外，基本輪詢已經涵蓋了客戶端需要執行的其他操作。 另一方面，伺服器必須管理多個未解析連線的狀態。 使用多個伺服器和負載平衡器時，可能需要建立乙個解決方案來保留會話狀態。 伺服器還必須正常處理連線超時，這在長輪詢中比在專用協議中更常見。
使用 HTTP 長輪詢在應用程式中構建實時互動性需要考慮多種因素，包括開發和擴充套件方面。 需要考慮的一些問題包括：
隨著使用量的增長，您將如何管理實時後端？
當移動裝置在網路之間切換或失去連線時，或者當 IP 位址發生更改時，長輪詢是否會自動重新建立連線？
您能否通過長時間輪詢來管理訊息佇列並彌補丟失的訊息？
長輪詢是否提供跨多個伺服器的負載平衡和故障轉移支援？
請記住，長輪詢只是底層請求-響應機制的臨時版本，這增加了其實現的複雜性。 因此，在應用程式中使用長輪詢時，這些是要考慮的重要因素。
在構建具有 HTTP 長輪詢伺服器推送的實時應用程式時，必須開發通訊管理系統。 這意味著您將負責更新、維護和擴充套件後端基礎結構。
長時間輪詢可能會給可靠的訊息排序帶來挑戰。 這是因為同一客戶端可以同時發出多個 HTTP 請求。 例如，如果客戶端開啟兩個瀏覽器選項卡並使用相同的伺服器資源，或者如果客戶端實現同時使用多個連線，則可能無法保證只寫入一次重複資料。
另乙個問題是伺服器可能會傳送響應，但網路或瀏覽器問題可能會阻止成功接收訊息。 如果未實現訊息接收確認過程，則對伺服器的後續呼叫可能會導致訊息丟失。
使用長輪詢的一大挑戰是，由於其複雜性，它可能難以擴充套件。 維護給定客戶端的會話狀態需要在負載平衡器後面的所有伺服器之間共享該會話狀態，或者將同一會話中的後續客戶端請求路由到處理原始請求的同一伺服器。 這可能會導致負載分布不均，並可能導致群集中各個伺服器過載。
HTTP 長輪詢是伺服器獨立向客戶端傳送資料的一種方式，允許伺服器在可用時實時推送資料到客戶端。 但是，當來自伺服器的訊息很少且不太頻繁時，它最有效。