CometD長輪詢是否使用持久連接？

Question

對於CometD的長輪詢機制是使用持久連接還是在將消息推送到它之后先斷開連接再重新連接，我一直找不到明確的答案。

這對我很重要的原因是，我當前使用的是長輪詢推送客戶端，該客戶端在從服務器發送了每條消息（或成批消息）后會斷開連接並重新連接，並且重新連接時間引入了我希望獲得的隨機延遲擺脫。 我假設這樣做是出於兼容性的考慮，因為它使每個“推送”看起來都像是一個很長的請求/響應，可以在任何瀏覽器上使用。

那么，CometD的長時間輪詢是否使用持久的，持久的http連接？ 如果答案是肯定的，是否有條件？ 就是說，是否有案例/瀏覽器會回退到每個發送的消息“請求/響應/重新連接”？

Answer 1

CometD長輪詢使用的是HTTP 1.1，因此是持久連接。

從瀏覽器使用CometD時，瀏覽器管理連接池和HTTP協議版本，並且CometD不會在每條消息后添加任何Connection標頭來關閉連接：所有操作都留給瀏覽器，我的經驗是長輪詢始終保持在同一連接上。

使用CometD Java客戶端庫時，同樣適用：Jetty的HTTP客戶端管理連接池，默認為HTTP 1.1並保持連接打開。 與瀏覽器的主要區別在於，Jetty HTTP客戶端每個域允許多個（通常為6個）連接，因此適用於負載測試模擬。 查看CometD性能報告 。

可以在http://docs.cometd.org上找到更新的CometD文檔。

說“根據定義，長輪詢不使用持久連接而是重新連接”是錯誤的。 HTTP 1.1完全有能力在同一連接上發送多個長輪詢，而CometD正是這樣做的。

我不知道使用HTTP 1.1時客戶端之類的客戶端會回退到打開/請求/響應/關閉行為的情況，除非應用程序明確要求添加HTTP Connection: close或Connection: close標頭到HTTP請求或響應（CometD不會這樣做） ）。

使用WebSocket，CometD僅持久打開1個連接，並且所有消息都通過該連接交換，直到應用程序決定通過斷開CometD客戶端斷開連接。