我无法找到关于CometD的长轮询机制是否使用持久连接的明确答案，或者在将消息推送到其后断开连接然后重新连接。
这对我来说很重要的原因是我目前正在使用一个长轮询推送客户端，它会在从服务器发送每条消息（或一批消息）之后断开连接并重新连接，重新连接时间会引入随机延迟希望摆脱。我假设它是为了兼容性而这样做，因为它使每个“推送”看起来像一个非常长的请求/响应，它应该适用于任何浏览器。
那么，CometD的长轮询使用持久的，长期的http连接吗？如果答案是肯定的，那是否有条件？也就是说，是否有案例/浏览器会在发送的每条消息中回退到“请求/响应/重新连接”？
答案 0 :(得分：0)
CometD长轮询正在使用HTTP 1.1，因此使用持久连接。
当从浏览器使用CometD时，浏览器管理连接池和HTTP协议版本，并且CometD不会添加任何Connection标头以在每条消息之后关闭连接：它全部留给浏览器，我的经验是，长期民意调查始终保持同一联系。
当使用CometD Java客户端库时，同样适用：Jetty的HTTP客户端管理连接池，默认为HTTP 1.1并保持连接打开。 与浏览器的主要区别在于Jetty HTTP客户端允许每个域有多个（通常是6个）连接，因此它适用于负载测试模拟。 查看CometD performance report。
可以在http://docs.cometd.org找到更新的CometD文档。
说“按定义进行长轮询不使用持久连接但重新连接”是错误的。 HTTP 1.1完全能够通过同一连接发送多个长轮询，而CometD正是这样做的。
我不知道在使用HTTP 1.1时，类似浏览器的客户端会回退到打开/请求/响应/关闭行为，除非应用程序明确请求为HTTP请求或响应添加Connection: close标头（ CometD不这样做。）
使用WebSocket，CometD仅打开1个连接，持久，并通过该连接交换所有消息，直到应用程序决定通过断开CometD客户端来关闭连接。