问题描述
我正在阅读很多关于HTML5的内容，特别是我喜欢网络套接字，因为它们促进了Web服务器和Web浏览器之间的双向通信。
但我们保留阅读关于铬，歌剧，火狐，Safari浏览器准备html5。哪个Web服务器准备好使用Web套接字功能？我的意思是，Web服务器能够启动今天的后续通信吗？ Google自己的Appengine怎么样？
如何编写一个在Java中利用此功能的示例Web应用程序？
Web服务器和浏览器之间的双向通信并不新鲜。如果将新的答案发布到您正在阅读的问题中，堆栈溢出会立即执行此操作。使用现有技术实现套接字式行为有几种不同的策略：
- AJAX短轮询：连接到服务器并询问是否存在是任何新消息。如果不是，请立即断开连接，并在短暂间隔后再次询问。当您不想让很多长时间运行的空闲连接对服务器开放时，这很有用，但这意味着您将只接收与您的轮询时间间隔一样快的新消息，并且会产生建立新的HTTP连接。
- AJAX长轮询：连接到服务器并保持连接处于打开状态，直到有新消息可用。这使您可以快速传递新消息和减少HTTP连接，但会导致服务器上更长时间的空闲进程。 隐藏iframe而不是XHR对象。当您想要进行跨站点长轮询时，有用于绕过同源策略。
- 插件：Flash的XMLSocket，Java小程序等可用于建立更接近真正的低级持久套接字到浏览器。
HTML5套接字并没有真正改变可用的底层策略。大多数情况下，他们只是将已经使用的策略形式化，并允许持续连接被明确识别，从而更加智能地处理。假设您想要在移动浏览器上执行基于Web的推送消息。通常的长轮询，移动设备需要保持清醒状态才能保持连接。使用WebSockets，当移动设备想要进入睡眠状态时，它可以切断与代理的连接，当代理接收到新数据时，它可以唤醒设备并将消息传回。
服务器端是开放的。要实现短轮询应用程序的服务器端，只需要某种按时间顺序的消息队列。当客户端连接时，他们可以将新消息从队列中移出，或者他们可以传递偏移量并读取任何比其偏移量更新的消息。
实现服务器端长轮询是你的选择开始缩小的地方。大多数HTTP服务器专为短期请求而设计：连接，请求资源，然后断开连接。如果300人在10分钟内访问您的网站，并且每个人需要2秒钟才能连接并下载HTTP资源，那么您的服务器在任何给定时间将平均打开1个HTTP连接。如果你正在运行你自己的专用服务器，你可能可以处理这个问题，但是，如果你正在运行你自己的专用服务器，在共享主机平台上，您可能会遇到资源限制，App Engine也不例外。 App Engine被设计为处理大量的低延迟请求，例如，短投票。您可以在App Engine上实施长时间轮询，但这并不合适;运行超过30秒的请求将被终止，并且长时间运行的进程会占用您的CPU配额。App Engine的解决方案就是即将推出的Channel API。渠道API使用Google现有强大的XMPP基础架构实现长轮询。
列出了如下使用模式： App Engine应用程序创建一个频道在远程服务器上，并返回一个通道ID，它们传递给Web浏览器。 网络浏览器将频道ID传递给同一个远程服务器，以通过iframe建立连接民意调查： 当一些有趣的事情发生时，App Engine应用程序可以将消息推送到用户的频道，长轮询请求将立即收到它： I am reading a lot about HTML5 and I like the web sockets in particular because they facilitate bi-directional communication between web server and web browser. But we keep reading about chrome, opera, firefox, safari getting ready for html5. Which web server is ready to use web sockets feature? I mean, are web servers capable of initiating subsequent communication as of today? How about Google's own Appengine? How can I write a sample web application that takes advantage of this feature in Java? Bi-directional communication between web servers and browsers is nothing new. Stack Overflow does it today if a new answer is posted to a question you're reading. There are a few different strategies for implementing socket-style behavior using existing technologies: HTML5 sockets don't really change the underlying strategies available. Mostly they just formalize the strategies already in use, and allow persistent connections to be explicitly identified and thus handled more intelligently. Let's say you want to do web-based push messaging to a mobile browser. With normal long-polling, the mobile device needs to stay awake to persist the connection. With WebSockets, when the mobile device wants to go to sleep, it can hand off the connection to a proxy, and when the proxy receives new data it can wake up the device and pass back the message. The server-side is wide open. To implement the server-side of a short polling application, you just need some kind of a chronological message queue. When clients connect they can shift new messages off the queue, or they can pass an offset and read any messages that are newer than their offset. Implementing server-side long polling is where your choices start to narrow. Most HTTP servers are designed for short-lived requests: connect, request a resource, and then disconnect. If 300 people visit your site in 10 minutes, and each takes 2 seconds to connect and download HTTP resources, your server will have an average of 1 HTTP connection open at any given time. With a long polling app, you're suddenly maintaining 300 times as many connections. If you're running your own dedicated server you may be able to handle this, but on shared hosting platforms you're likely to bump up against resource limits, and App Engine is no exception. App Engine is designed to handle a high volume of low latency requests, e.g. short polling. You can implement long polling on App Engine, but it's ill-advised; requests that run for longer than 30 seconds will get terminated, and the long running processes will eat up your CPU quota. App Engine's solution for this is the upcoming Channel API. The channel API implements long polling using Google's existing robust XMPP infrastructure. Brett Bavar and Moishe Lettvin's Google I/O talk lays out the usage pattern as follows: App Engine apps create a channel on a remote server, and are returned a channel ID which they pass off to the web browser. The web browser passes the channel ID to the same remote server to establish a connection via iframe long polling: When something interesting happens, the App Engine app can push a message to the user's channel, and the browser's long poll request will immediately receive it: 这篇关于http服务器如何处理html5 web套接字？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！
class MainPage（webapp.RequestHandler ）：
def get（self）：
id = channel.create_channel（key）
self.response.out.write（
{'channel_id'：id }）
< script src ='/ _ ah / channel / jsapi'>< / script>
< script>
var channelID ='{{channel_id}}';
var channel =
new goog.appengine.Channel（channelId）;
var socket = channel.open（）;
socket.onmessage =函数（evt）{
alert（evt.data）;
}
< / script>
class OtherPage（webapp.RequestHandler）：
def get （self）：
＃发生了什么
channel.send_message（key，'bar'）
class MainPage(webapp.RequestHandler):
def get(self):
id = channel.create_channel(key)
self.response.out.write(
{'channel_id': id})
<script src='/_ah/channel/jsapi'></script>
<script>
var channelID = '{{ channel_id }}';
var channel =
new goog.appengine.Channel(channelId);
var socket = channel.open();
socket.onmessage = function(evt) {
alert(evt.data);
}
</script>
class OtherPage(webapp.RequestHandler):
def get(self):
# something happened
channel.send_message(key, 'bar')