服务器客户端通信：长轮询，彗星和服务器
我正在开发一个连接到服务器的Web应用程序，并且我需要服务器在给定时间向客户端推送一些信息。
因此，我开始阅读关于服务器发送的事件（SSE），因为该网站是在HTML5上开发的，SSE似乎符合我的要求。 但是，当我读到SSE真正做的是什么时，惊奇的是将请求从客户端发送到服务器，而不是相反的方式（昨天我认为我理解长时间轮询就是一种推模拟）。 因此，我开始阅读关于网络套接字（但它接近标准仍然是一个草案），并看看彗星。 但我认为我无法适应我脑海中的所有问题。
有人会强调这些适合我的问题的技术（也可能是其他一些推动技术），哪种情况更适合每种技术？
非常感谢，我认为我完全失去了这个领域。
这篇文章是一个更好的解释，讨论关于长轮询，彗星，SSE和WebSockets的差异/优点/等。
大多数情况下，客户端通常必须向服务器发出第一个请求以建立连接。 建立连接后，服务器可以将数据推送到客户端。 因此，即使使用WebSocket，客户端也会向服务器发出初始请求，以在两者之间建立可靠的连接。
Server-Sent Events使用正常的HTTP GET请求来建立与服务器的连接。 它也是客户端的只读连接。 它具有易于实现的好处，因为我们不必定义新的协议。 问题在于大多数Web服务器在大约15秒后关闭了HTTP连接，即使是持久连接也是如此。 即使对于长期的请求，Web服务器通常会有一个超时，然后关闭连接。 这就是长轮询的想法。这是一个简单的想法，我们向服务器发出正常的ajax请求，并且服务器尽可能长时间地将其打开。 如果服务器出于任何原因关闭了请求，您将立即再次发出相同的请求。 您可以使用诸如Node.js之类的服务器和来自浏览器的常规Ajax请求轻松实现长轮询机制（即。Comet）。 服务器发送的事件尝试用EventSource抽象出浏览器端的这个实现。 因此，您不必为长轮询/彗星实现浏览器/客户端代码，浏览器会为您处理此问题。 它提供了一个好像是一个持久连接的抽象概念。 您的Web服务器只需要注意GET请求，它将头文件中的Content-Type指定为“text / event-stream”，并尽可能保持HTTP连接处于打开状态。
我建议你不要过于复杂化服务器发送的事件。 如果您了解正常的HTTP GET请求，那么您可能已经对其背后的想法有90％的理解。
SSE / Comet和传统的长轮询有一点区别，值得强调。 根据我的经验，长轮询背后的想法是，只有在更新之前，您的请求才会返回。 此时HTTP连接关闭，并在此后立即发出另一个请求。 使用SSE，尽管您可以在发送更新的消息后立即关闭HTTP连接，但您的目标是将数据从服务器刷新到客户端，而无需实际关闭/结束HTTP请求。 这可以避免实际发出GET请求的开销。 这可以通过常规的ajax请求来实现，但SSE再次提供了一个很好的/有效的EventSource实现。
编辑：澄清SSE和长轮询之间的区别。
链接地址: http://www.djcxy.com/p/57335.html上一篇: Server client communication: Long Polling, Comet, & Server
下一篇: How does facebook, gmail send the real time notification?