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