在Jetty上持续推进彗星长轮询？

Question

我正在尝试创建一个Jetty servlet，允许客户端（Web浏览器，Java客户端......）从Web服务器获取广播通知。

通知应以JSON格式发送。

我的第一个想法是让客户端发送一个长轮询请求，服务器在使用Jetty的Continuation API获得通知时进行响应，然后重复。

这种方法的问题是我错过了2个请求之间发生的所有通知。

我找到的唯一解决方案是缓冲服务器上的事件并使用时间戳机制重新传输错过的通知，这有效，但看起来很重要...

关于如何更优雅地解决这个问题的任何想法？

谢谢！

Answer 1

HTTP Streaming绝对是比HTTP长轮询更好的解决方案。 WebSockets是一个更好的解决方案。

WebSockets提供了第一个标准化的双向全双工解决方案，可以在任何客户端（它不必是Web浏览器）和服务器之间进行Web上的实时通信。恕我直言WebSockets是一种可行的方式，因为它们是一种将继续开发，支持和需求的技术，并且只会在使用和普及方面增长。他们也超酷:)

似乎有a few WebSocket clients for Java和Jetty also supports WebSockets。

Answer 2

很抱歉碰到这个，但我相信很多人都会遇到这个帖子，接受的答案，恕我直言，至少已经过时了，更不用说误导了。

按优先顺序排列如下：

1）WebSockets是当今的解决方案。我个人有过在面向企业的应用程序中引入WebSockets的经验。所有主流浏览器（Chrome，Firefox，IE - 以字母顺序:)）原生支持WebSockets。所有主要的服务器/ servlet（IIS，Tomcat，Jetty）都是相同的，Java中有很多框架实现了JSR 356 API。代理存在问题，尤其是在云部署中。然而，人们对WebSockets的要求有了很高的认识，所以NginX在1。1年前就已经支持它了。无论如何，安全的'wss'协议解决了99.9％的代理问题（不是100％只是为了安全起见，从未体验过我自己）。

2）长轮询可能是第二个最佳解决方案，“可能”部分是由于“短轮询”替代方案。在谈到长轮询时，我指的是从客户端到服务器的重复请求，一旦有任何可用数据就会响应。因此，一次民意调查可以在几毫秒内完成，另一轮民意调查可以完成 - 直到最长等待时间。确保将轮询时间限制为小于2分钟的时间，因为通常情况下您需要在客户端管理超时错误。我建议将轮询时间限制在几十秒之内。可以肯定的是，一旦轮询完成（及时或在此之前），它会立即重复（更好地建立一些简单的协议并给你的服务器一个机会向客户说 - '暂停'）。 IMHO证明列表延续的长轮询的缺点是，它只允许少数（4,8个仍然没有那么多）允许连接中的一个，浏览器允许每个页面建立到服务器。这样可以占用您网站客户流量资源的~12％~25％。

3）短暂的民意调查并没有被很多人所喜爱，但有时我更喜欢它。当然，这一点的主要缺点是在建立新连接时浏览器和服务器的高负载。然而，我相信如果正确使用连接池，那么开销比第一眼就看起来要小得多。

4）HTTP流式传输，无论是通过IFrame或XHR流式传输的页面流，是恕我直言，高度BAD解决方案，因为它就像是所有其他的Cons的积累以及更多：

• 你将保持打开的连接（浏览器和服务器的资源）;
• 你仍然会从总的可用客户流量限制中消耗掉;
• 最邪恶的：你需要设计/实现（或重用设计/实现）实际的内容交付，以便能够区分新内容和旧内容（无论是推送脚本，哦我的！还是跟踪长度累积的内容）。请不要这样做。

更新（20/02/2019）

如果WebSockets不是一个选项 - Server Sent Events是恕我直言的第二个最佳选择 - 有效的浏览器在较低级别为您实现了HTTP流媒体。

Answer 3

我在通过Atmosphere框架使用Http Streaming之前已经完成了这项工作，并且工作正常。

访问Comet, Streaming

如果你看到气氛教程，他们给出了多个例子

Answer 4

您可能想要查看它们是如何在CometD中实现的：http://cometd.org。或者您甚至可以考虑使用该工具，而无需重新发明轮子。