Java Web 服务器应用程序有办法推送吗？
Web 服务器响应传入的 HTTP 请求...处理请求并返回 HTTP 响应。在此架构中，服务器是否有任何常见的方式可以将数据推送到客户端...例如，请求来自客户端1，服务器想要通知客户端2？显然，它可以通过使用套接字的非 Web 服务器来完成，但是必须支持页面请求并允许推送数据的 Web 服务器应用程序又如何呢？
Web-servers work in response to incoming HTTP requests... process the request and return an HTTP response. Are there any common ways that a server can PUSH data to clients in this architecture... e.g a request comes in from client1 and the server wants to notify client2? It can obviously be done by a non-web server, using sockets, but what about a web-server app which has to support page requests AND allow PUSHing data..?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Servlet 3.0 引入了异步支持，允许编写 Comet 风格的应用程序（即使用长期 HTTP 连接和长轮询 或流 的应用程序）。
如果您等不及 Servlet 3.0 异步支持，并且不想使用容器（如 GlassFish、Jetty）的专有 Comet 或 WebSocket 支持，那么请查看 氛围。
另请参见
Servlet 3.0 introduces Async support allowing to write Comet style applications (i.e. applications using Long-lived HTTP connections and either long polling or streaming).
If you can't wait for Servlet 3.0 Async support and don't want to use proprietary Comet or WebSocket support from containers (like GlassFish, Jetty), then have a look at Atmosphere.
See also
您可以使用 Web 应用程序容器，例如支持 Web Sockets 如果您不介意等待网络世界赶上这个新兴标准。然后您将拥有真正的双向通信，而不是 HTTP + 轮询或特殊插件等。
You can use web app containers like Jetty which support Web Sockets if you don't mind waiting for the web world to catch up to this up-and-coming standard. Then you'll have real bi-directional communications instead of HTTP + Polling or special plug-ins or the like.
不，如果没有一些客户端技术（Flash、Silverlight、Applet 等），
您可以让页面使用 AJAX 轮询服务器。
No, not without some client side tech (Flash, Silverlight, Applets, etc.)
You could have the page poll the server with AJAX though.
另一种可能性是滥用 HTTP Keep Alive 来实现此目的。请参阅 http://en.wikipedia.org/wiki/HTTP_persistent_connection 了解一些背景信息。在您的场景中，您将让
client2启动与服务器的连接，然后该服务器将保持打开状态以侦听通知。这不是一个很好的解决方案，首先您需要保留大量长期存在的 TCP 连接，如果连接丢失，服务器将无法重新连接。它必须等待客户回来。
Another possibility would be to abuse HTTP Keep Alive to achieve this. See http://en.wikipedia.org/wiki/HTTP_persistent_connection for some background. In your scenario you would have
client2initiate a connection to the server that then would stay open listening for notifications.This is not a great solution, first off you need to keep lots of long lived TCP connections around, and if a connection is lost there is no way for the server to reconnect. It must wait for the client to come back.