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客户端断开连接。