CometD长轮询是否使用持久连接？

Question

关于CometD的长轮询机制是否使用持久连接，或者在消息被推送到它之后断开连接然后重新连接，我还没有找到一个明确的答案。

这对我来说很重要的原因是，我目前使用的是一个长轮询推送客户端，它在从服务器发送每条消息(或一批消息)后断开并重新连接，重新连接时间引入了随机延迟，我希望摆脱这些延迟。我假设它这样做是为了兼容性，因为它使每个“推送”看起来都像是一个非常长的请求/响应，这应该可以在任何浏览器上工作。

那么，CometD的长轮询是否使用持久的、长期的http连接呢？如果答案是肯定的，那是有条件的吗？也就是说，是否在某些情况/浏览器中，每发送一条消息就会返回到“请求/响应/重新连接”？

Answer 1

CometD长轮询使用HTTP1.1，因此使用持久连接。

当从浏览器使用CometD时，浏览器管理连接池和HTTP协议版本，并且CometD不会在每条消息之后添加任何Connection头来关闭连接:所有这些都留给浏览器，我的经验是长轮询总是停留在同一连接上。

当使用HTTP客户端库时，同样适用: CometD的HTTP管理连接池，缺省为HTTP1.1并保持连接打开。浏览器的主要不同之处在于，Jetty HTTP客户端允许每个域有多个连接(通常为6个)，因此它适用于负载测试模拟。查看CometD performance report。

可以在http://docs.cometd.org上找到更新后的CometD文档。

“根据定义，长轮询不使用持久连接，而是重新连接”，这是错误的。HTTP1.1完全能够在同一连接上发送多个长轮询，而CometD正是这样做的。

我不知道浏览器等客户端在使用HTTP1.1时会后退到打开/请求/响应/关闭行为，除非应用程序显式地请求将Connection: close头添加到HTTP请求或响应(CometD不会这样做)。

使用WebSocket，CometD只打开一个持久连接，并且所有消息都通过该连接进行交换，直到应用程序决定通过断开CometD客户端来关闭该连接。