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