关于CometD的长轮询机制是否使用持久连接，或者断开连接，然后在消息被推送到它后重新连接，我还没有找到一个明确的答案。
这对我来说很重要的原因是，我目前使用的是一个长轮询推送客户端，它在每条消息(或一批消息)从服务器发送后断开连接并重新连接，并且重新连接时间引入了随机延迟，我正在寻找摆脱。我假设它这样做是为了兼容性，因为它使每个"推送"看起来像一个非常长的请求/响应，这应该在任何浏览器上都能工作。
那么，CometD的长轮询是否使用持久的、长期存在的http连接呢?如果答案是肯定的，是有条件的吗?也就是说，是否有情况/浏览器，它回落到"请求/响应/重新连接"每个消息发送?CometD长轮询使用HTTP 1.1，因此使用持久连接。
当CometD从浏览器中使用时，浏览器管理连接池和HTTP协议版本，CometD不添加任何Connection头来关闭每条消息后的连接:所有这些都留给浏览器，我的经验是长轮询总是保持在相同的连接上。
当使用CometD Java客户端库时，同样适用:Jetty的HTTP客户端管理连接池，默认为HTTP 1.1并保持连接打开。与浏览器的主要区别在于，Jetty HTTP客户端允许每个域的连接数多于几个(通常为6个)，因此它适合于负载测试模拟。查看CometD的性能报告。
更新后的CometD文档可在http://docs.cometd.org找到。
说"长轮询根据定义不使用持久连接而是重新连接"是错误的。HTTP 1.1完全能够在同一连接上发送多个长轮询，CometD正是这样做的。
我不知道在使用HTTP 1.1时，像浏览器这样的客户端退回到打开/请求/响应/关闭行为的情况，除非应用程序明确要求在HTTP请求或响应中添加Connection: close标头(CometD不这样做)。
使用WebSocket, CometD只打开一个连接，并且所有的消息都在该连接上交换，直到应用程序决定通过断开CometD客户端来关闭连接。