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