我正在开发一个连接到服务器的Web应用程序，我需要服务器在给定时间内将一些信息提供给客户端。
因此，我开始阅读有关服务器发送事件（SSE）的信息，因为该网站是在HTML5上开发的，而SSE似乎非常符合我的要求。但是，当我读到SSE真正在做的事情是将客户端的请求发送到服务器而不是相反的方式时，我感到非常惊讶（昨天我认为我理解长轮询是一种推送仿真）。因此，我开始阅读有关Web套接字的内容（但它标注了该标准仍然是草案）并且还看了一下Comet。但我认为我不能完全理解我的想法。
有人会突出显示适合我的问题的这些技术（可能还有其他一些技术），哪种情况更适合每种技术？
非常感谢，我想我在这个领域完全迷失了。
答案 0 :(得分：6)
这个post是一个更好的解释，讨论有关长轮询，彗星，SSE和WebSockets的差异/优势/等。
在大多数情况下，客户端通常必须向服务器发出第一个请求才能建立连接。建立连接后，服务器就可以将数据推送到客户端。因此，即使使用WebSockets，客户端也会向服务器发出初始请求，以便在两者之间建立可靠的连接。
Server-Sent Events使用普通的HTTP GET请求与服务器建立连接。它也是客户端的只读连接。它具有易于实现的优点，因为我们不必定义新协议。问题是HTTP连接（即使是持久连接）在大约15秒后被大多数Web服务器关闭。即使对于长期存在的请求，Web服务器通常也会超时，然后关闭连接。这就是长轮询的概念所在。我们向服务器发出正常的ajax请求并且服务器尽可能长时间地打开它是一个简单的想法。如果服务器出于某种原因关闭了请求，则会立即再次发出相同的请求。您可以使用Node.js等服务器和来自浏览器的普通Ajax请求轻松实现长轮询机制（即Comet）。 Server-Sent Events尝试使用EventSource抽象出浏览器端实现。因此，浏览器不是必须为长轮询/彗星实现浏览器/客户端代码，而是为您处理此问题。它提供了一个看起来像持久连接的很好的抽象。您的Web服务器只需要查看GET请求，这些请求在标题中指定Content-Type为“text / event-stream”，并尽可能保持HTTP连接处于打开状态。
我建议你不要过分复杂服务器发送的事件。如果您了解正常的HTTP GET请求，那么您可能已经有90％了解其背后的想法。
SSE / Comet和传统长轮询之间存在一个可能值得强调的区别。根据我的经验，长轮询背后的想法是，在您有更新之前，您的请求不会返回。此时HTTP连接关闭，之后立即发出另一个请求。使用SSE，虽然您可以在发送更新的消息后立即关闭HTTP连接，但您的目标是将数据从服务器刷新到客户端，而不实际关闭/结束HTTP请求。这避免了实际发出GET请求的开销。这可以通过常规的ajax请求来实现，但是SSE再次为EventSource提供了一个很好/高效的实现。
编辑：阐明SSE和长轮询之间的区别。